Integrate

How it fits together

Your backend talks to Identise with an API key; your users talk only to your backend.

flow

 Browser / mobile app ──▶ Your backend ──(X-Api-Key)──▶ Identise API  /v1/oauth/*
        ▲                     │
        └── your own session  └─ verifies Identise access tokens (RS256, with your app's public keys)
            (e.g. HttpOnly cookies)

Your API key never leaves your backend. Browsers and mobile apps talk to your backend, which talks to Identise.

The words used in these docs

Workspace	Your organisation in Identise. Holds applications, API keys, members and audit logs.
Application	One product that signs users in. Its App ID (the dashboard's Client ID) is a UUID. Standard is a normal app; Platform can create Tenant apps through the API.
API key	`idt_live_…`, shown once when generated, up to 5 active per app. It authenticates your backend's calls to Identise; keep it on your servers.
App users	People who sign up through your app. They're isolated per app: the same email can be a separate account in two apps, and an app's users can't sign in to the Identise dashboard.
Access token	A JWT valid for 15 minutes (your app's token lifespan), with `aud` = your App ID, signed RS256 with your app's own key, which only Identise holds. See Verifying access tokens.
Refresh token	An opaque string valid for 30 days (your app's setting), replaced on every refresh: always keep the newest one. See Keeping users signed in.
Connection token	A single-use, 5-minute token Identise puts on your callback URL after a Google sign-in. Your backend exchanges it for tokens.

Use the token's sub (the user's id) as the key in your own database, not the email: the same email belongs to a different user in each of your apps.