OAuth 2.0, PKCE, JWT, JWK and JWKS: understand their roles

OAuth 2.0, PKCE, JWT, JWK and JWKS often appear in the same architecture, but they are not interchangeable. Some describe authorization flows, others a token format or a way to represent and publish cryptographic keys.

OAuth 2.0 organizes authorization

OAuth 2.0 is a framework for delegated authorization. It lets an application obtain limited access without requiring the user to give that application the password of another service.

OAuth does not require every access token to be a JWT. The token format is a separate design choice.

PKCE protects the authorization-code exchange

PKCE adds a temporary proof to an authorization-code flow. The client creates a random verifier and sends a derived challenge before authentication. When exchanging the returned authorization code, it must present the original verifier.

The PKCE generator helps visualize the verifier/challenge pair and the S256 transformation.

PKCE does not encrypt a JWT and does not replace TLS. It protects a specific stage of the authorization flow.

JWT is a token format

JWT defines a compact structure made of dot-separated segments. Signed JWTs can carry claims and a signature that a recipient verifies.

The JWT inspector, JWT decoder and JWT encoder make the structure easier to inspect.

Decoding a JWT is not the same as verifying its signature. Data encoded in a normal JWT payload should not be treated as confidential merely because it is encoded.

JWK and JWKS represent keys

JWK is a JSON representation of a cryptographic key. A JWKS is a set of JWK objects, commonly published so clients can obtain public keys needed to verify signatures.

The JWK/JWKS inspector helps inspect key type, identifiers and parameters.

A JWT header may contain a kid value. A verifier can use that identifier to select the matching key from a JWKS before checking the signature.

How the pieces fit together

A simplified sequence may look like this:

1. a client starts an OAuth authorization flow and creates PKCE values;
2. the authorization server authenticates the user and returns an authorization code;
3. the client exchanges that code while presenting the PKCE verifier;
4. the server returns tokens, which may include JWTs;
5. a recipient inspects a JWT header and selects an appropriate public key from a JWKS;
6. the recipient verifies the signature and then applies the expected issuer, audience, expiry and other validation rules.

Avoid common confusions

• OAuth is not a token format.
• PKCE is not encryption.
• JWT payloads are not automatically confidential.
• Decoding is not signature verification.
• JWKS is a key set, not a list of user sessions.

The key is to distinguish protocol, container and keys. OAuth defines authorization flows; PKCE strengthens some of those flows; JWT can carry signed claims; JWK and JWKS represent the keys used for cryptographic verification.