Authentication

Invora uses the OpenID Connect (OIDC) standard for authentication.

Invora serves as the identity provider (IdP). Discovery document: https://auth.invora.app/.well-known/openid-configuration.

Onboarding Flow

1. Registration

1. Register an account with Invora through the usual sign-up process at https://dashboard.invora.app/.
2. Register a custom application in the Invora dashboard to obtain:
   1. Client ID
   2. Client Secret
   3. Allowed scopes
   4. Tenant ID

2. Authentication Flows

Invora supports the following OIDC authentication flows. Token endpoint: https://auth.invora.app/oauth/v2/token.

Send POST requests with Content-Type: application/x-www-form-urlencoded.

1. Client Credentials Grant

Send a request with the following parameters:

• grant_type: Set to client_credentials.
• client_id: Your application's Client ID.
• client_secret: Your application's Client Secret.
• scope: The scopes listed in the dashboard.

Note

client_credentials grants broad administrative access to the tenant. Keep client_secret secure.

2. Resource Owner Password Credentials (Password) Grant

Warning

You can ONLY authenticate users within your own tenant.

Send a request with the following parameters:

• grant_type: Set to password.
• client_id: Your application's Client ID.
• client_secret: Your application's Client Secret.
• scope: The scopes listed in the dashboard.
• username: The user's username (email).
• password: The user's password.

Include a __tenant header corresponding to your tenant ID.

3. Refresh Token Grant

Send a request with the following parameters:

• grant_type: Set to refresh_token.
• client_id: Your application's Client ID.
• client_secret: Your application's Client Secret.
• scope: The scopes listed in the dashboard.
• refresh_token: The refresh token obtained from a previous authentication.

This rotates both the access token and refresh token.

3. Using the Access Token

After successfully authenticating using one of the above flows, you will receive:

1. access_token
2. id_token (JWT)
3. refresh_token

You can use the access_token to authenticate your API requests to Invora services by including it in the Authorization header as a Bearer token:

Authorization: Bearer access_token_value

Note

The access_token is a reference token (not a JWT). Use the introspection endpoint to get token metadata. Alternatively (recommended), use the id_token (JWT) to get user information and claims.

Introspection endpoint: https://auth.invora.app/oauth/v2/introspect.

Send a POST request with:

• token: The access_token you received.

Authenticate using client_id and client_secret (Basic Auth).

Example request:

POST /oauth/v2/introspect HTTP/1.1
Host: auth.invora.app
Authorization: Basic base64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded

token_type_hint=access_token
&token=access_token_value

Sample Token Response

Successful token responses typically include:

{
    "access_token": "ref_...",
    "id_token": "eyJhbGci...",
    "refresh_token": "rfr_...",
    "token_type": "Bearer",
    "expires_in": 3600
}

Best Practices

• Store secrets securely and never log tokens.
• Prefer short-lived access tokens; rely on refresh_token to extend sessions.
• Use HTTPS endpoints only.