# Registering your application

Before integrating with Truora Pass you need to register your application and obtain credentials. Registration is self-serve through the **Truora Pass Dashboard** at `https://dashboard.pass.truora.com`.

## Create your application

1. Sign in to your Truora account **first** — at `https://account.truora.com`. The Pass dashboard has no sign-in screen of its own — it reuses your existing Truora session from the account host.
2. Open the dashboard at `https://dashboard.pass.truora.com`. You land on the list of your OAuth2 applications (empty the first time).
3. Click **+ New Application**.
4. Fill in the application form — see the [field reference](#application-form-fields) below.
5. Click create. The dashboard then shows your credentials **exactly once**, under the heading *"Important: Save your client secret"*: *"This is the only time you'll see the client secret. Make sure to copy and store it securely."* The screen shows your **Client ID** and **Client Secret** with show/hide and copy controls — copy both and store the secret in a secrets manager before leaving the page.

**Note**: The dashboard inherits your session from the account host (`account.truora.com`). If you open the dashboard without an active session there, loading your applications fails with an Unauthorized error and you are sent back to the account sign-in — sign in there, then return to the dashboard.

## Application form fields

| Field | Required | Description and constraints |
|-------|----------|-----------------------------|
| **Application Name** | Yes | Human-readable name of your application, shown to users on the consent screen. |
| **Description** | No | Internal description — not shown to your users. |
| **Redirect URIs** | Yes | Between 1 and 10 absolute `https` URLs — plain `http` is accepted only for loopback hosts (`localhost`, `127.0.0.1`, `::1`) during development. Entered as a chip list — "The URIs where users will be redirected after authorization". The `redirect_uri` in every authorize request and token exchange must exactly match one of them. |
| **Scopes** | Yes | The scopes your application is allowed to request — at least one; `openid` is always included. Every scope in an authorize request must be registered here. See the [Scopes reference](/truora-pass/scopes_reference/). |
| **Allowed Email Domains** | No | "Restrict sign-ups and logins to specific email domains. Leave empty to allow all." |
| **Enable JavaScript Client** | No | Enables the embedded [SDK flow](/truora-pass/embedded_sdk/) (`allows_web_message`). Turning it on reveals the **Authorized JavaScript origins** field. |
| **Authorized JavaScript origins** | Only with the JavaScript client | The web origins allowed to embed Truora Pass (`allowed_web_message_origins`). Origin only — scheme + host, no path. Required for the [embedded SDK flow](/truora-pass/embedded_sdk/): the origin of the `redirect_uri` used in an embedded request must be in this list. |
| **Minimum Assurance Level** | No | Minimum authentication strength users must meet (`minimum_acr`): None, `urn:truora:acr:1` (single factor), `urn:truora:acr:2` (strong single factor — passkey), or `urn:truora:acr:3` (multi-factor + biometric). |
| **Maximum Authentication Age** | No | Maximum age of the user's Truora Pass session before re-authentication is required, in seconds (`max_auth_age`). Up to 2592000 (30 days); empty or 0 means no policy. |
| **Token Delivery Mode** | Only with the CIBA grant | For the backchannel flows, how your backend receives the result (`backchannel_token_delivery_mode`): `poll` (default — you pull from the token endpoint) or `push` (Truora Pass posts the result to your callback). The [Consent Gate](/truora-pass/approval_requests/) needs `push` — a poll-mode client has no way to ever read an approval's outcome. |
| **Backchannel Client Notification Endpoint** | Only with `push` delivery | The HTTPS URL Truora Pass posts the decision to (`backchannel_client_notification_endpoint`). Absolute `https`; plain `http` only for loopback hosts during development. |

## Your credentials

| Credential | Format | Handling |
|------------|--------|----------|
| `client_id` | Prefixed `WLT_APP_...` | Public identifier of your application; appears in authorize URLs. |
| `client_secret` | Random string, generated at creation | **Shown exactly once** at creation — only a hash is stored afterwards. Save it in a secrets manager immediately. |

**Note**: The `client_secret` must only ever be used from your server (in the body of `POST /v1/oauth2/token` and `POST /v1/oauth2/bc-authorize` requests). Never ship it in browser or mobile code.

## If you lose your client secret

The `client_secret` is shown only once, and only a hash of it is stored — it cannot be displayed again, and there is **no regenerate action**, in the dashboard or otherwise. Where the dashboard's application-details screen mentions regenerating a lost secret, the way to do that today is the process below. If the secret is lost or exposed:

1. Delete the application in the dashboard and create a new one (self-serve — you get a new `client_id` and `client_secret`), or
2. Contact Truora.

## Grant types

Every application uses the `authorization_code` grant by default, and a [refresh token](/truora-pass/refresh_tokens/) is issued with every code exchange — no extra registration is needed to redeem it. To use the [decoupled flow](/truora-pass/ciba_flow/), additionally select the **CIBA (backchannel approval)** grant (`urn:openid:params:grant-type:ciba`) in the dashboard form — grant selection is self-serve.

## What to prepare per integration flow

### Redirect ([Authorization Code flow](/truora-pass/authorization_code_flow/))

Fully self-serve in the dashboard:

- The **Redirect URIs** your application will receive callbacks on (HTTPS URLs on your domain).
- The **Scopes** you plan to request.
- No extra grant types needed — `authorization_code` is the default.

### Embedded SDK ([web_message](/truora-pass/embedded_sdk/))

Everything from the redirect flow, plus — also self-serve in the dashboard:

- **Enable JavaScript Client** turned on (`allows_web_message`).
- **Authorized JavaScript origins** listing every origin (scheme + host, no path) of the pages that will embed Truora Pass — the `redirect_uri` you pass to the SDK must have its origin in this list.

### Decoupled ([CIBA flow](/truora-pass/ciba_flow/))

Also self-serve in the dashboard:

- The **CIBA (backchannel approval)** grant type selected on the form. A CIBA-only application may omit redirect URIs entirely — there is no browser callback in this flow.
- Optionally, [push delivery](/truora-pass/ciba_flow/#alternative-to-polling-push-delivery) instead of polling: register a **Backchannel Client Notification Endpoint** (an HTTPS URL you control) and set the **Token Delivery Mode** to `push` (the default is `poll`).

### Consent Gate approvals ([Approval requests](/truora-pass/approval_requests/))

Everything from the decoupled flow, plus:

- **Token Delivery Mode** set to **push** and a **Backchannel Client Notification Endpoint** (HTTPS) where Truora Pass posts the reviewer's decision — the Consent Gate is not redeemable at the token endpoint, and without a registered push endpoint your application has no way to ever read an approval's outcome.
- The `approval:read` scope, so the delivered access token can read the decision and submitted form data.

## Editing your application

You can edit an application later from the dashboard at `/applications/:id/edit` — the same fields as at creation, plus an **Active** toggle — and delete it from the dashboard as well.

## Next step

With your `client_id` and `client_secret` in hand, follow the [Authorization Code flow](/truora-pass/authorization_code_flow/) guide for the canonical end-to-end integration, or see [Getting started](/truora-pass/getting_started/) to pick the flow that fits your product.