Client Configuration

💡 User-delegated authorization: Obtain user consent for requested scopes and receive an access token that acts on their behalf with limited permissions.
💡 Why PKCE matters: Without PKCE, malicious apps on the same device can intercept your authorization code during redirect. PKCE binds the code to your app using a cryptographic challenge, making interception useless. Even if your client_secret leaks, PKCE protects the token exchange. PKCE is mandatory to be compliant with OAuth 2.1 spec.

Verifier
Code:

💡 Perfect for input-constrained devices: Smart TVs, IoT devices, CLI tools - anything where typing credentials is painful. User authenticates on their phone/computer while the device polls for completion.

👉 Complete authorization on another device:
Verification URL:
Open
Enter this code:
Polling every s... Expires in s

💡 Silent token renewal: Refresh tokens let you get new access tokens without user interaction - critical for long-running sessions. ⚠️ They're high-value targets: store securely, rotate them (one-time use pattern), and never send in URLs. Some providers only issue them with offline_access scope. If refresh fails, re-authenticate the user - don't retry infinitely.

💡 Service-to-service authentication: No users involved - your backend service is both client and resource owner. Tokens represent the app's identity, not a user's. ⚠️ Never use in frontend code (exposes secret). No refresh tokens issued - just request new ones when expired.

💡 Asymmetric authentication: Replaces shared secrets with public-key cryptography. Your private key and client secret never transmit through network. This is a more conservative alternative to client_credentials flow.

API Request
Requires Access Token.
Active Session
Access Token
Refresh Token
Access Token Claims (Decoded JWT)
ID Token Claims
Response Log

Ready...