Sign In With CATAPA
This guide explains how to add "Sign in with CATAPA" to your application using the OAuth2 Authorization Code flow with user consent.
Prerequisites
Before you begin, you need to create an OAuth Client. See https://gdplabs.gitbook.io/catapa-api/get-started/authentication-and-authorization#create-an-oauth-client. Make sure the Authorized Grant Type contains authorization_code.
Get the following from the OAuth Client:
client_id
Your application's unique identifier
client_secret
Your application's secret key (keep this confidential)
redirect_uri
The callback URL in your app where CATAPA will redirect after authorization
Flow Diagram
Step-by-Step Integration
Create the "Sign in with CATAPA" Link
In your application's frontend, create a link or button that redirects the user to CATAPA's authorization page:
Parameters:
response_type
Yes
Must be code
client_id
Yes
Your application's client ID
redirect_uri
Yes
Your callback URL. Must exactly match a registered redirect URI
scope
Yes
Space-separated list of scopes. Currently, set it to empty (no value)
state
Recommended
A random string to prevent CSRF attacks. You must verify this value in the callback
Example HTML:
User Logs In and Grants Consent
After clicking the link, the user is taken to CATAPA where they:
Log in — If the user is not already logged into CATAPA, they will be prompted to log in
Review permissions — CATAPA shows a consent page with your application's name and the permissions being requested
Authorize or Deny — The user decides whether to grant access
You do not need to implement anything for this step. CATAPA handles it entirely.
Handle the Redirect Callback
After the user authorizes (or denies) the request, CATAPA redirects the user's browser to your redirect_uri.
Successful authorization:
code
The authorization code. Use this in the next step to get an access token
state
Must match the state you sent in Step 1. Reject the request if it doesn't match
tenant
The CATAPA tenant identifier of the authenticated user. Store this — you will need it for API calls
Denied authorization:
Exchange the Code for an Access Token
Your backend must exchange the authorization code for an access token. This call must be made server-side to keep your client_secret confidential.
Request:
Important: The token endpoint is
/oauth/token(not/oauth2/token).
Parameters:
grant_type
Yes
Must be authorization_code
code
Yes
The authorization code from Step 3
redirect_uri
Yes
Must exactly match the redirect_uri used in Step 1
Authentication: HTTP Basic Auth with client_id as the username and client_secret as the password.
Response:
access_token
JWT token to use in API requests
refresh_token
Token to obtain a new access token when the current one expires
token_type
Always Bearer
expires_in
Token lifetime in seconds (e.g., 86400 = 24 hours)
Quick Reference
Endpoints
/oauth2/authorize
GET
Start the authorization flow (via browser redirect)
/oauth/token
POST
Exchange code for tokens, or refresh tokens
/v1/users/me
GET
Get the authenticated user's information
Required Headers for API Calls
Authorization
Bearer {ACCESS_TOKEN}
The access token from the token exchange
Tenant
{TENANT}
The tenant value received in the authorization callback
Error Handling
Authorization Errors (Step 3)
If something goes wrong during authorization, CATAPA redirects to your redirect_uri with error parameters:
invalid_request
Missing or invalid required parameter
unauthorized_client
Your app is not authorized for this grant type
access_denied
The user denied the consent request
invalid_scope
Requested scope is invalid or unknown
server_error
Unexpected server error
Token Errors (Step 4)
The token endpoint returns HTTP error codes with a JSON body:
Rate Limiting
The authorization and token endpoints are rate-limited. Excessive failed requests will result in HTTP 429 Too Many Requests.
Security Best Practices
Always validate
state— Compare the returnedstatewith the one you sent to prevent CSRF attacksExchange the code server-side — Never expose your
client_secretin frontend/client-side codeStore tokens securely — Keep
access_tokenandrefresh_tokenin a secure server-side storeStore the
tenantvalue — You will need it as a header for all subsequent API callsHandle token expiration — Use the refresh token to seamlessly renew access without re-prompting the user
Use HTTPS — All communication with CATAPA must be over HTTPS in production
Complete Example (Python)
FAQ
Do I need to implement the consent/login page?
No. CATAPA handles user authentication and consent entirely. Your app only needs to redirect the user and handle the callback.
Can I skip the consent step?
No. If your client is configured to require consent, the user must explicitly authorize your application. This cannot be bypassed.
Last updated