Experiments

Authorization_Code

2 min read

Authorization Code Flow

Client → Resource → Authorization Server

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 authoriation 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.