Get started
Overview
Use Aldelo SSO to sign people in to your app with OpenID Connect.
Aldelo SSO is the sign-in service for Aldelo Cloud. Your app sends people to it to sign in, and gets back standard OpenID Connect tokens that say who they are and which organization they are working in.
How sign-in works
- Your app sends the browser to
https://sso.aldelo.com/authorizewith an authorization code request that uses PKCE. - The person signs in at
sso.aldelo.comand, the first time, agrees to share their details with your app. If your app serves several organizations and they belong to more than one, they choose one. - SSO sends the browser back to your registered redirect URI with a one-time code.
- Your server exchanges the code at
https://sso.aldelo.com/oauth2/tokenfor an ID token and an access token. - Your app validates the ID token and starts its own session for the person.
What you need
- A registered application: a
client_id, your exact redirect URIs and, for a server-side app, a client secret. See Request access. - An OpenID Connect client library that supports the authorization code flow with PKCE. Most maintained libraries do.
- HTTPS for every redirect URI and for your back-channel logout URI.
Endpoints
Point your library at the issuer https://sso.aldelo.com. It reads everything else from the discovery document at https://sso.aldelo.com/.well-known/openid-configuration.
| Endpoint | Use |
|---|---|
/authorize | Start a sign-in (browser redirect). |
/oauth2/token | Exchange the code for tokens (server to server). |
/userinfo | Read the signed-in person's claims with an access token. |
/oauth2/introspect | Ask whether an access token is still active. |
/oauth2/revoke | Revoke an access token. |
/logout | Sign the person out of SSO (browser redirect). |
/api/v1/me/memberships | List the organizations the signed-in person belongs to. |
/.well-known/jwks.json | The public keys that sign every token. |
The API reference documents each endpoint, and OpenAPI (JSON) is the same contract in machine-readable form.
Security at a glance
- PKCE with
S256is required on every sign-in, including sign-ins from server-side apps. - Redirect URIs must match a registered URI exactly. SSO never redirects to an unregistered URI; a request it can't trust shows an error page at
sso.aldelo.cominstead. - Tokens are signed with
RS256. Validate them against the published keys.
Never put secrets in email
Client secrets, tokens and passwords never travel by email, in either direction. If anyone asks you to email one, don't.
Get help
Email developer@aldelo.com. If a sign-in page shows a reference code, include it: it lets us find the exact request.