TrustPortDocs

Register your application

  1. Create the application
    In the dashboardApplications›Create application

    Name it after the product people will recognise, for example “Acme web app”.

  2. Add redirect URIs

    List every address your app may send users back to after sign-in, one per line. TrustPort only ever redirects to an address on this list, matched exactly.

    • Use https://. Plain http:// is allowed only for localhost.
    • No wildcards and no #fragments.
    • Add each environment separately: production, staging and local development.
  3. Save the client secret

    You'll see the client ID and client secret. The secret is shown once; store it in your server's secret manager. If it leaks, choose Rotate secret and the old one stops working.

To review every approved address across all your applications in one place, open Redirects in the dashboard. You can add or remove addresses there too.

Choose how users sign in

ApproachBest forAvailability
Sign-in APIApps with their own sign-in screenAvailable
OAuth 2.0 with PKCEApps that redirect to TrustPort and get a code backPreview

Sign-in API

Your app collects the email and password and sends them from your server to TrustPort.

curl -X POST https://id.trustportidentity.com/api/v1/auth/login \
  -H "Content-Type: application/json" \
  -H "X-Tenant-ID: $TRUSTPORT_WORKSPACE_ID" \
  -d '{ "username": "ada@example.com", "password": "…" }'

Three things can come back:

  • Tokens. The person is signed in. Keep the tokens as described in Sessions and tokens.
  • A two-factor challenge (mfa_required: true). Ask for the code and complete the sign-in; see Two-factor authentication.
  • An error. Show the message to the person. The same message is used for an unknown email and a wrong password, on purpose.
Call the sign-in API from your server, not from browser code you ship to users. Sign-in is rate limited per IP address, and you don't want your users' attempts sharing a limit with an attacker's.

OAuth 2.0 with PKCE

Send the browser to the authorize endpoint with your client ID, an approved redirect URI, a random state and a PKCE challenge:

Authorize
https://id.trustportidentity.com/oauth/authorize
  ?response_type=code
  &client_id=$CLIENT_ID
  &redirect_uri=https://app.example.com/callback
  &scope=openid profile email
  &state=$RANDOM_STATE
  &code_challenge=$CODE_CHALLENGE
  &code_challenge_method=S256

TrustPort returns the browser to your redirect URI with a code and your state. Check that state matches, then exchange the code from your server:

Token exchange
curl -X POST https://id.trustportidentity.com/oauth/token \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -d grant_type=authorization_code \
  -d code=$CODE \
  -d redirect_uri=https://app.example.com/callback \
  -d code_verifier=$CODE_VERIFIER
In preview
The authorize step currently expects the person to be signed in to TrustPort already. A hosted sign-in page that collects credentials during the redirect is on the way. Until then, the Sign-in API is the simplest route.

Discovery

OIDC-aware libraries can configure themselves from the discovery document:

Discovery
GET https://id.trustportidentity.com/.well-known/openid-configuration
© TrustPort IdentitySomething unclear? Tell us and we'll fix the page.