Behind the Scenes of OAuth 2.1

Every web developer should know OAuth 2.0 PKCE flow.

Photo by Van Tay Media on Unsplash

Every web developer should know OAuth 2.0 PKCE flow. At a high level, the flow involves the following:

1. Register a Client App
2. Create a user and associate the user with the Client App
3. Create a secret code verifier and code challenge [PKCE]
4. Build the authorization URL and redirect the user to the authorization server.
5. The user is redirected back to the client after successful login. Verify the state.
6. Exchange the authorization code and code verifier for an access token

Use the following playground to gain first-hand experience.

OAuth 2.0 PKCE Flow

OAuth 2.0 and OpenID Connect helps Web application to:

• Identify the User via ID token
• Access the API via the Access token

Behind the scenes is about How to make these tokens?

• Symmetric and Asymmetric Encryption
• Cryptographic Hash Function
• JSON Web Tokens (JWT, pronounce jot)
• JWT Signature Verification
• JSON Web Key Set
• PKCE

This understanding will help developers gain knowledge and appreciate the work that has strengthened the flow.

Symmetric Encryption

• Symmetric encryption uses a secret key (password) to encrypt the content.
• To decrypt symmetrically encrypted data, you need the same secret key.
• The commonly used implementation is Advanced Encryption Standard (AES).
• AES secret key can be of size 128, 192, or 256 bits.

Encrypted text will differ on every run—courtesy of Initialization Vector.

Asymmetric Encryption: Public Key Cryptography

• Public key cryptography involves a pair of keys known as a Public Key and a Private Key
• A private key is a secret. The corresponding public key can be published.
• The commonly used implementation is Rivest-Shamir-Adelman (RSA) algorithm.
• The RSA public key pair sizes nowadays are 2048 bits (256 bytes).

By default, RSA encrypted text will differ on every run.

Symmetric Encryption and (not versus) Asymmetric Encryption

• Symmetric encryption is comparatively faster than Asymmetric encryption.
• But, “Sharing Secret” is an inherent problem with the symmetric approach. If you have to share the key with one person, you can give a call, text, or communicate by some means. It is not practical if you have to share with thousands of folks. Moreover, sharing secrets with more than one is not a secret anymore.
• The asymmetric approach solves the problem of sharing the secret.

Check the SSL/TLS handshake process to understand the dynamics.

Source: https://www.ssl.com/article/ssl-tls-handshake-overview/

Checksum

• A checksum hash function generates hash code to make it possible to check the integrity of a given data.
• Every byte that we desire to check integrity should be used to calculate the checksum.
• The hash function must be deterministic, meaning that the same message always results in the same hash.
• Decoding the generated hash code to get the original content is not possible. The intent is only to prove its authenticity.

Cryptographic Hash Function

“An MD5 checksum can be generated by anyone who has access to a file. An attacker who breaks into a site, or executes a man-in-the-middle attack, can easily change the MD5 checksum so it matches the compromised file.” — Stack Overflow

Digital signature overcomes the stated weaknesses.

Signing

1. Create a hash code of the content to ensure data integrity.
2. Encrypt the hash code using the private key (asymmetric encryption). The encrypted hash code is called the digital signature.

Verifying

1. Use the public key (asymmetric encryption) to decrypt the digital signature. The output would be the hash code.
2. Verify the hash code to ensure data integrity.

JSON Web Token

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.

RS256 is one of the popular algorithms.

• The signature algorithm is RSASSA-PKCS1-v1_5 (RS).
• The hashing algorithm is SHA256 (256).

Image Source: https://community.auth0.com/t/rs256-vs-hs256-jwt-signing-algorithms/58609

Use JWT playground to understand the JWT payload, Signature, and its verification process.

JWT.IO

If you have reached this stage, pat yourself on the back. To explore further, create a developer account in Okta (free account).

Okta Developer

Okta creates one authorization server by default. Navigation path is Security >> API >> Authorization Servers >> default.

As per OAuth 2 standards, every authorization server should publish metadata URI.

JWKS is our next topic.

https://dev-xxxxxxx-okta.com/oauth2/default/.well-known/oauth-authorization-server
"issuer": "https://dev-xxxxxxxx.okta.com/oauth2/default",
"authorization_endpoint": "https://dev-xxxxxxxx.okta.com/oauth2/default/v1/authorize",
"token_endpoint": "https://dev-xxxxxxxx.okta.com/oauth2/default/v1/token",
"registration_endpoint": "https://dev-xxxxxxxx.okta.com/oauth2/v1/clients",
"jwks_uri": "https://dev-xxxxxxxx.okta.com/oauth2/default/v1/keys",

JSON Web Key Set

Signature verification of JWT needs a public key. Additional values are also required based on the chosen algorithm. To standardize the sharing of this information JSON Web Key was introduced (RFC 7517).

Sample JWKS

Let us connect all the dots:

• ID token and Access Token is a JWT.
• JWT is to be trusted only when the signature can be verified. JWKS plays a crucial role by providing the public key related to your JWT.
• In addition, JWT claims should also be verified. Expirations should be honored, before accepting the payload.

Finally, let’s ponder on PKCE using Okta (optional sections, feel free to skip).

OAuth 2.0 public clients utilizing the Authorization Code Grant are
susceptible to the authorization code interception attack. This
specification describes the attack as well as a technique to mitigate
against the threat through the use of Proof Key for Code Exchange
(PKCE, pronounced “pixy”) — RFC 7636

Please read the blog for more details on “OAuth 2.0 Authorization Code with PKCE Flow”. Instead, I will share details about what it takes to generate PKCE and how to test run the Auth Flow in our local setup.

Implement the OAuth 2.0 Authorization Code with PKCE Flow

Create the following in Okta Developer Account:

1. Create a Client App.
2. Create People/Group in Okta Universal Directory.
3. Associate people with Client App.

Sign users into your SPA using the redirect model

Copy and paste the access token into https://jwt.io/.

Now, every aspect will be clear:

• Signature is verified.
• How jwt.io got to know the public key? Check the network tab. There will be two network requests — one for metadata URI and the second one for JWKS.

More content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter, LinkedIn, YouTube, and Discord. Interested in Growth Hacking? Check out Circuit.