Domain-only URIs (e.g., https://example.com) are not accepted. You must include a path such as /callback or /auth/callback. Each redirect URI is matched exactly — no wildcard or pattern matching is performed.
Authorization Request - Redirect user to authorization endpoint (the state parameter is required)
Consent Screen - User sees which application is requesting access and what permissions (scopes) are being requested
User Authentication - User logs in with their DHMAD account
Authorization - User authorizes the application
Authorization Code - User is redirected back with code and state
Token Exchange - Exchange code for access token
User Info - Use access token to get user information
The state parameter is required. Requests without a state parameter will be rejected with an invalid_request error. Generate a unique, random value for each authorization request and validate it on the callback to prevent CSRF attacks.
DHMAD only supports the S256 code challenge method for PKCE. The plain method is not accepted and will be rejected with an invalid_request error. Always use SHA-256 to hash your code verifier.
Use PKCE (S256)
Always use PKCE with the S256 code challenge method (plain is not supported)
HTTPS Only
Always use HTTPS for redirect URIs in production
State is Required
The state parameter is mandatory. Requests without it are rejected. Generate a unique random value per request and validate it on callback to prevent CSRF attacks.
Secure Storage
Store tokens securely, never in localStorage for sensitive apps
When a user is redirected to the authorization endpoint, they are shown a consent screen that displays:
Your application name (as registered in the Developer Dashboard)
Requested permissions (scopes) with clear descriptions of what data will be shared
The user must explicitly authorize the request before an authorization code is issued. If the user clicks “Cancel”, they are redirected back to your redirect_uri with error=access_denied.