Proof Key of Code Exchange (PKCE)

Proof Key of Code Exchange (PKCE) Flow — Oracle Access Manager

PKCE flow Access token generation

Sample OAuth2.0 Authorization Code Request

Sample Access token request 8

Access Token verification

The 3 legged flow could be compromised if the client-id, secret and the authZ code parameters are got through Man in middle or an intrusion attack. Once the parameters are hacked, then retrieving the access token becomes easy and this flaws the security of the 3-legged flow.

To prevent such attacks, PKCE flow is used. This kind of setup is more for single page Javascript application. In PKCE flow, clients use one time dynamic creds call code_verifier instead of a static client_secret. The code_verifier and the code_challange values are used to verify the authenticity of the interaction.

With PKCE flow, the standard artifacts like the Identity domain, Client profile and the resources/resources servers are configured. When configuring the client, PKCE is enabled . Client level PKCE flow has strict and non strict options. In the strict flow, If the PKCE parameters code_verifier and code_challenge are not provided in the token_access request, the authorization flow fails.

In the non strict flow,If the PKCE parameters code_verifier and code_challenge are not provided in the token_access request, the authorization flow continues as 3-legged flow.

PKCE flow Access token generation

1. Enable domain level PKCE — UsePKCE in customAttrs
2. Enable client level PKCE.
3. OAM OAuth rest API resources should be configured in the default domain of OAM. (This would have been done as default)
4. Generate random code_verifier cryptographically — string between 43 -123 chars. Code_verifier should be unique for each authZ request. Code verifier is used to obtain access_token later.
5. Code_challenge is the base64 string from the 256 SHA hash of code_verifier.
6. In the authorization request for authorization code (after resource owner provides consent), the authz request includes the code_challenge. This code_challenge is stored in the authz server for verification / comparison against the code_verifier with every access token request. Each access token request has the code_verifier send as a parameter in the request.
7. The authZ server, retrieves the code_verifier and compares it with the hashed value of the stored code_challenge. Only if the code verifier and challenge matches, the access token is send back in the response.
8. Following are sample request, access token request and the token validation endpoint request.

Sample OAuth Authorization Code Request (OAM)

http://<Webservhost>:<WebSerPort>/oauth2/rest/authz?response_type=code&client_id=DemoClient&domain=DemoDomain&scope=DemoResourceServer.scope1&state=abc&redirect_uri=http://localhost:8080/sampleapp/account.jsp&code_challenge=<hashed code challenge>&code_challenge_method=S256

Sample Access token request (OAM)

curl — request POST ‘http://<ServerHost>:<ServerPort>/oauth2/rest/token’— header ‘X-OAUTH-IDENTITY-DOMAIN-NAME: DemoDomain’ — header ‘Content-Type: application/x-www-form-urlencoded’ — header ‘Cookie:JSESSIONID=<sessionIDvalue>’ — data-urlencode ‘grant_type=AUTHORIZATION_CODE’ — data-urlencode ‘code=<authorization code> — data-urlencode ‘redirect_uri=http://localhost:8080/sampleapp/account.jsp' — data-urlencode ‘code_verifier=<codeverifier>’ — data-urlencode ‘client_id=DemoClientId’

Access Token verification (OAM)

curl — request GET ‘http://<ServerHost>:<ServerPort>/oauth2/rest/token/info?access_token=<AccessToken> — header ‘X-OAUTH-IDENTITY-DOMAIN-NAME: DemoDomain’ — header ‘Cookie: JSESSIONID=<sessionidvalue>

This article explains the PCKE flow as used in OAM. The role played by the code_verifier and code_challenge is described. The code_challenge is stored in the authZ servers and is later uses to verify the cod_verifier value. PKCE flow is uses in less secure application and provides extra security around the OAuth token flow. Covered are sample access request for token and token verification as used in OAM.