take a auth-shot ÔÇô OAuth 2.0 PKCE Grant

Take a auth-shot ÔÇô PKCE Grant

CheersÔÇŽ In our last auth-shot we had a closer look at the client credentials grant type, and we also got to know the difference between confidential clients and public clients. Today we’re going to take a look at the PKCE Grant.

“Confidential clients, compared to public clients, can keep a secret (client-secret) securely, i.e., store and process it.”

Today we will look at how public clients can securely obtain an access token.

Public clients not only have the restriction that they cannot keep the client secret safe, but they also have to take into account the authentication of the user at the same time. Strictly speaking, it is about granting a user access to a specific resource via a specific client.

The recommended grant for this is the PKCE Grant, PKCE stands for Proof Key for Code Exchange. As a replacement for the client-secret, 3 additional values are used in this grant:

  • the code-verifier: A random string, consisting of letters, numbers, and a few special characters.
  • the code challenge: the hashed code verifier.
  • the code-challenge-method: The hash method with which the code challenge was generated.
Method Logic 
plain code_challenge = code_verifier
S256 code_challenge = BASE64URL-
ENCODE(SHA256(ASCII(code_verifier))) 

With the authorization request, the client sends his client-id and additionally the hashed code_challenge. The authorization server receives this information and directs the end user to a login page. Once the end user has successfully logged in, the authorization server sends a code to the client. ÔÇ»

The client can now exchange this code for a token in combination with the previously generated code_verifier. The client in doing so activates on the token endpoint with the code and the code_verifier. The authorization server checks whether the code-verifier (hashed) matches the previously passed code-challenge. If both matches, the authorization server can issue the access token and return it to the client.

We have enclosed the Client Credentials Grant with all roles, i.e. the application (client), the authorization server (cidaas), the resource server, as well as the user and the login page (hosted pages), in a flowchart.

OAuth 2.0 PKCE Grant flow diagram | cidaas

With our third part about the PKCE Grant, our take a auth-shot blog series comes to an end. We appreciate your feedback.

Our first blog of the take an auth-shot blog series – “One Grant for All Cases?” – can be found here.

The second part of our take a auth-shot blog series – “Client Credentials Grant” – can be found here.

Leave a Comment

Your email address will not be published. Required fields are marked *