Add sign-in to your app
Register your product as an application, approve where it may send users back to, then sign people in from your own screens.
Register your application
- Create the applicationIn the dashboardApplications›Create application
Name it after the product people will recognise, for example “Acme web app”.
- 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://. Plainhttp://is allowed only forlocalhost. - No wildcards and no
#fragments. - Add each environment separately: production, staging and local development.
- Use
- 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
| Approach | Best for | Availability |
|---|---|---|
| Sign-in API | Apps with their own sign-in screen | Available |
| OAuth 2.0 with PKCE | Apps that redirect to TrustPort and get a code back | Preview |
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.
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:
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=S256TrustPort returns the browser to your redirect URI with a code and your state. Check that state matches, then exchange the code from your server:
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_VERIFIERDiscovery
OIDC-aware libraries can configure themselves from the discovery document:
GET https://id.trustportidentity.com/.well-known/openid-configuration