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-clientarrow-up-right. Make sure the Authorized Grant Type contains authorization_code.

Get the following from the OAuth Client:

Item
Description

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

1

In your application's frontend, create a link or button that redirects the user to CATAPA's authorization page:

Parameters:

Parameter
Required
Description

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:

2

After clicking the link, the user is taken to CATAPA where they:

  1. Log in — If the user is not already logged into CATAPA, they will be prompted to log in

  2. Review permissions — CATAPA shows a consent page with your application's name and the permissions being requested

  3. Authorize or Deny — The user decides whether to grant access

You do not need to implement anything for this step. CATAPA handles it entirely.

3

Handle the Redirect Callback

After the user authorizes (or denies) the request, CATAPA redirects the user's browser to your redirect_uri.

Successful authorization:

Parameter
Description

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:

4

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:

Parameter
Required
Description

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:

Field
Description

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)

5

Get User Information

Use the access token and tenant to retrieve the authenticated user's information:

The Tenant header is required for all CATAPA API calls.

6

Refresh the Access Token (Optional)

When the access token expires, use the refresh token to get a new one without requiring the user to log in again:

Response: Same format as Step 4, with a new access_token and refresh_token.

Quick Reference

Endpoints

Endpoint
Method
Description

/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

Header
Value
Description

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:

Error Code
Description

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

  1. Always validate state — Compare the returned state with the one you sent to prevent CSRF attacks

  2. Exchange the code server-side — Never expose your client_secret in frontend/client-side code

  3. Store tokens securely — Keep access_token and refresh_token in a secure server-side store

  4. Store the tenant value — You will need it as a header for all subsequent API calls

  5. Handle token expiration — Use the refresh token to seamlessly renew access without re-prompting the user

  6. Use HTTPS — All communication with CATAPA must be over HTTPS in production

Complete Example (Python)

FAQ

chevron-rightHow long does the authorization code last?hashtag

Authorization codes are short-lived (typically 5 minutes). Exchange it for tokens immediately after receiving it.

chevron-rightCan I use the access token for multiple tenants?hashtag

No. The access token is scoped to the tenant returned in the callback. You must include the correct Tenant header in every API call.

Last updated