AuthCode+PKCE

The AuthCode flow consist of two physical operations:

• a front-channel step via the browser where all "interactive” things happen, e.g. login page, consent etc. This step results in an authorization code that represents the outcome of the front-channel operation.
• a back-channel step where the authorization code from step 1 gets exchanged with the requested tokens. Confidential clients need to authenticate at this point.

This flow has the following security properties:

• No data (besides the authorization code which is basically a random string) gets leaked over the browser channel.
• Authorization codes can only be used once.
• The authorization code can only be turned into tokens when (for confidential clients - more on that later) the client secret is known.

There is one problem called code substitution attack. And for mitigation technique we will use RFC 7636 - PKCE.

Proof Key for Code Exchange by OAuth Public Clients (PKCE)

This essentially introduces a per-request secret for code flow (please read up on the details here). All the client has to implement for this, is creating a random string and hashing it using SHA256.

This also solves the substitution problem, because the client can prove that it is the same client on front and back-channel, and has the following additional advantages:

• The client implementation is very simple compared to hybrid flow.
• It also solves the problem of the absence of a static secret for public clients.
• No additional front-channel response artifacts are needed.