Authorization Grant code with PKCE

(Proof Key for Code Exchange-OpenAM )

Public client interactions use PKCE flow, in this flow instead of using client secrets that have the potential to be compromised, a code challenge and code verifier is used.

This flow suits Javascript applications or single page apps, where the secret cannot be stored securely. Using client secrets opens for CSRF attacks. PKCE flow provides an extra layer of security. The code challenge used in this flow is hashed and stored in the AuthZ server for future comparison with code_verifier.

This flow uses code_verifier (form parameter), code_challenge (query parameter) and the code challenge method (SHA256) used to retrieve the code. The code verifier is a dynamically generated one time credential. The decoded verifier can be used to verify the code challenge that was received for the access_token request initially.

The code verifier is a SHA 256 base 64 encoded string. For every interaction with the authorization server, the code_verifier is sent. The OAuth server compares the decoded code verifier with the stored code challenge. This flow is suited for untrusted, single page and mobile apps.

PCKE flow OpenAM

Sample OpenAM requests

Authorization Request

curl — request POST — data “response_type=device_code” — data “client_id=abcClient” — data “code_challenge=hYstuuKKiiiLLkiuytfdgfdskgRRRE” — data “code_challenge_method=S256” — data “scope=write” “https://am.example.com:8443/sso/oauth2/realms/root/device/code"

Generate Code verifier & Code Challenge

1. Client application generated code_verifier and code_challenge.
2. Creating a code_challenge using SHA-256 is a required step for the client to use with the request. Javascript example — Ref AM- (OAuth2 guide 6.5)

function base64URLEncode(words) { return CryptoJS.enc.Base64.stringify(words).replace(/+/g, ‘-’).replace(/\//g, ‘_’).replace(/=/g, ‘’);} var codeverifier = base64URLEncode(CryptoJS.lib.WordArray.random(50)); var codechallenge = base64URLEncode(CryptoJS.SHA256(verifier));

1. The methods in bold generates the verifier and the challenge, which can be used in the initial request and token request.Authorization Code.

Authenticate the user

curl — request POST — header “Content-Type: application/json” — header “X-OpenAM-Username: demo” — header “X-OpenAM-Password: **” — header “Accept-API-Version: resource=2.0, protocol=1.0” ‘https://am.example.com:443/openam/json/realms/root/authenticate'*{“tokenId”:”AQIC5wM…TU3OQ”,”successUrl”:”/openam/console”,”realm”:”/” }

Sample AM request with scopes: read,response Types: code, token and Grant Types:

https://am.example.com:443/openam/oauth2/realms/root/authorize?client_id=demoClient&response_type=code&scope=read&redirect_uri=https://www.sample.com:443/callback&state=xyt234&decision=allow&code_challenge=<code challenge generated>&code_challenge_method=S256

1. In the above sample, the scope= read has been allowed by the resource owner. The demoClient is making an initial authorization call with the code challenge and expecting an authZ code. In this transaction, the challenge is hashed and stored on the server. The state parameter is added to protect against CSRF attacks.
2. Once the authZ code is received by the client, it has to make the next request to get an access token. The client creates a post request with the following parameters

grant_type=authorization_code, code=your_authorization_code, client_id=your_client_id, redirect_uri=your_redirect_uri, code_verifier=your_code_verifier originally generated.

curl — request POST — data “grant_type=authorization_code” — data “code=<authorization code>” — data “client_id=demoClient” — data “redirect_uri=https://www.sample.com:443/callback" — data “code_verifier=<code_verifier orginaially generated>” “https://am.example.com:8443/openam/oauth2/realms**/root/access_token**"

The client id, redirect URL, the authorization code should all be valid and match the original request. The token endpoint sends the below response.

{“access_token”: <valid access token?, “scope”: “read”, “token_type”: “Bearer” “expires_in”: 3599 }

This article covers the OpenAM steps to request access tokens in the PKCE flow for non-secure applications. Ref OpenAM- (OAuth2 guide 6.5)

Join FAUN: **Website 💻|Podcast 🎙️|Twitter 🐦|Facebook 👥|Instagram 📷|[Facebook Group](https://www.facebook.com/groups/364904580892967/) 🗣️|Linkedin Group 💬| [Slack](https://faun.dev/chat) 📱|Cloud Native News 📰|More.**

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇