Overview
The Hosted UI flow is the recommended approach for most applications. Users authenticate through our secure, pre-built login page to authorize your application to act on their behalf. This approach eliminates the need to handle user credentials in your application, providing the best balance of security, compliance, and developer experience.User-Centered Design: The hosted UI ensures users maintain direct control over their authentication while granting your application permission to perform actions they authorize.
Complete in 4 steps: This is the simplest OAuth implementation, with authentication and authorization handled automatically by the hosted UI.
When to Use Hosted UI
Ideal For
- Web applications
- Third-party integrations
- SaaS platforms
- Quick implementations
- Standard OAuth patterns
Not Ideal For
- Mobile apps requiring native UI
- Heavily branded experiences
- Headless/API-only systems
- Custom authentication flows
Prerequisites
Before starting, ensure you have:- ✅ API keys (
x-client-keyandx-secret-key) - ✅ Whitelisted redirect URI in your environment configuration
- ✅ HTTPS endpoint for production (HTTP allowed in sandbox)
- ✅ Understanding of PKCE implementation
Flow Diagram
Implementation Guide
Step 1: Initiate OAuth Flow
Generate PKCE parameters and request the hosted UI URL.| Parameter | Required | Description |
|---|---|---|
response_type | Yes | Must be code |
client_id | Yes | Your application’s client identifier |
redirect_uri | Yes | Must match a whitelisted URI exactly |
state | Yes | Random string for CSRF protection |
code_challenge | Yes | BASE64URL(SHA256(code_verifier)) |
code_challenge_method | Yes | Must be S256 |
scope | No | Space-separated list of permissions |
Step 2: User Authentication (Automatic)
After redirecting to the hosted UI URL:- User sees the hosted login page - Our secure, pre-built interface
- User enters credentials - Email/username and password
- User completes 2FA if enabled - OTP or biometric verification
- Hosted UI handles authentication - No API call needed from your app
This step happens entirely on the hosted UI. Your application doesn’t need to make any API calls or handle credentials.
Step 3: Authorization (Automatic)
After successful login:- User sees permission consent screen (if first time)
- User approves access - Grants your app permission
- Hosted UI generates authorization code - Automatic API call
- User redirected back to your app - With code and state parameters
This step is also handled automatically by the hosted UI. Your app simply receives the redirect with the authorization code.
Step 4: Exchange Code for Tokens
Handle the callback in your application and exchange the authorization code for access and refresh tokens.| Field | Required | Description |
|---|---|---|
grant_type | Yes | Must be authorization_code |
code | Yes | Authorization code from Step 3 |
redirect_uri | Yes | Must exactly match Step 1 |
code_verifier | Yes | Original PKCE verifier (43-128 chars) |
Token Expiry Times:
- Access token: 6 hours (21,600 seconds)
- Refresh token: 7 days (604,800 seconds)
Using Access Tokens
Once you have an access token, use it to make API requests on behalf of the user. Include the token in theAuthorization header for all authenticated requests:
Token Refresh
When the access token expires (after 6 hours), use the refresh token to obtain a new one:Error Handling
invalid_request - Missing or invalid parameters
invalid_request - Missing or invalid parameters
Cause: Required parameters are missing or malformed.Solution:
- Verify all required parameters are present
- Check parameter formatting (e.g., base64url encoding for PKCE)
- Ensure
response_typeis exactlycode
invalid_grant - Invalid or expired authorization code
invalid_grant - Invalid or expired authorization code
invalid_client - Invalid client credentials
invalid_client - Invalid client credentials
Cause: Client key or secret is incorrect or not authorized.Solution:
- Verify your
x-client-keyandx-secret-key - Ensure keys are for the correct environment (sandbox/production)
- Check that OAuth is enabled for your client
access_denied - User denied authorization
access_denied - User denied authorization
State parameter mismatch
State parameter mismatch
Cause: State parameter doesn’t match what was sent in Step 1.Solution:
- This indicates a possible CSRF attack
- Do not proceed with token exchange
- Log the incident and restart the flow
Testing Checklist
Before going to production, verify:- PKCE code_verifier is 43-128 characters from [A-Za-z0-9-._~]
- State parameter is random and validated on callback
- Redirect URI exactly matches whitelisted configuration
- Secret key is never exposed in client-side code
- Tokens are stored securely (not in localStorage for sensitive apps)
- Token expiry is checked before API calls
- Refresh token flow is implemented
- Error handling covers all OAuth error codes
- HTTPS is used in production (HTTP only for sandbox)
- Session timeout (10 minutes) is handled gracefully
