Client gets back an “Authorization Code” (Auth Code)
Web Application uses [Auth Code, Client ID, Client Secret]→ hit /token endpoint
Gets back access and refresh token
Benefits
Only one time use Authorization Code is exposed, Auth Code is useful for seconds only.
The application never sees the user’s credentials
The user never sees the access and refresh tokens
Limitations
Since Client Secret needs to be protected, Therefore we can use Auth Code flow in the scenarios where both the conditions are met:
the user is involved
application has a backend component
Not ideal for
Microservices or service accounts
SPA
Mobile
PKCE (Proof Key for Code Exchange)
pronounced: pixy
It is RFC 7636
No client secret
Client application generates a Code verifier is kept on local system
Code verifier is a random URL safe string of at least 43 characters
Client application generates a Code challenge is created
Code challenge is a Base64 encoded SHA256 hash of that code verifier
When authorization request is sent the application will send the code challenge and keep the code verifier secret
Assuming authorization request is successful, the authorization server responds with an authorization code
When the application exchanges the auth code with the token, it sends code verifier in the request
The authorization server hashes and encodes the code verifier to compare against the original code challenge sent before
Use cases
Any frontend application that cannot keep secrets: Mobile App and SPAs (in OAuth terminology we call them public clients)
Limitation
You can’t get a refresh token
You can’t store secrets locally
Security
Use SSL/TLS
Always Validate your token
Use CORS
Authorization Code Interception Attack
In mobile we can register custom URI scheme (eg. org.wso2.app://) to multiple apps. Mobile OS takes care of resolving which app to invoke when custom URI needs to be opened.
If legitimate app goes to authorization server and logins and get redirection URI returned, if the same custom URI is registered for a malicious app, it is a possibility that the OS resolves and opens the malicious app instead!
Hence the standard Authorization Code flow might be compromised and hence PKCE flow is introduced to make sure that when exchanging the AuthZ code with token (which is second time interacting with authorization server), the same legitimate client is making the request instead of malicious client.