SSO Provider Examples

SSO provider examples

Step-by-step setup for common identity providers. Read Single sign-on (OIDC) first for how accounts are created and matched.

Replace https://desk.example.com with your console's address (APP_URL) throughout.

What every provider needs

At the provider	Value
Client type	Confidential (it gets a client secret), authorization code flow
Redirect URI for console sign-in	https://desk.example.com/login/oidc/callback
Redirect URI for RustDesk client sign-in	https://desk.example.com/login/oidc/client-callback
Post-logout redirect URI, only with Sign out of the provider too	https://desk.example.com/login
Scopes	openid email profile (the console's default)

Settings → SSO shows the console callback. Register the client callback too, or Continue with SSO in the RustDesk app fails at the provider with a redirect URI error.

The console sends PKCE (S256) and a nonce, checks the ID token's signature, issuer, audience and expiry, and also reads the userinfo endpoint. It uses these claims: sub (identity), email (linking an existing account and the domain allowlist), name, and preferred_username (the new account's username).

Microsoft Entra ID

Checked against Microsoft's documentation and Entra's live discovery and signing keys. Thanks to Voljka1, who wrote up a working setup in #124.

In the Entra admin center (entra.microsoft.com):

1. Entra ID → App registrations → New registration.
   • Name: anything, e.g. CortenDesk.
   • Supported account types: Accounts in this organizational directory only (single tenant).
   • Redirect URI: platform Web, https://desk.example.com/login/oidc/callback.
2. Authentication → Web → Add URI: https://desk.example.com/login/oidc/client-callback. If you will turn on Sign out of the provider too, also add https://desk.example.com/login: Entra only returns to a post-logout URL that matches a registered redirect URI. Leave the implicit grant and hybrid flow boxes unticked; the console uses the authorization code flow.
3. Certificates & secrets → New client secret. Copy the Value (not the Secret ID); Entra shows it once. Secrets expire. Note the date: an expired secret makes every SSO sign-in fail.
4. API permissions: Microsoft Graph delegated openid, profile, email (User.Read is there by default and does no harm). If your tenant does not let users consent to apps, select Grant admin consent.
5. From Overview, copy the Application (client) ID and the Directory (tenant) ID.

In CortenDesk, Settings → SSO:

Field	Value
Provider URL	https://login.microsoftonline.com/<tenant-id>/v2.0
Client ID	Application (client) ID
Client secret	The secret's Value
Require the provider to assert email verification	Off. Entra never sends email_verified, so turning this on refuses everyone.

Test Connection should report "Connected to https://login.microsoftonline.com//v2.0 — N signing key(s) published."

Things to know:

• Use your tenant ID, not common or organizations. Those endpoints publish a placeholder issuer (https://login.microsoftonline.com/{tenantid}/v2.0) that never matches the issuer in a real token, so Test Connection passes but every sign-in fails with "unexpected issuer". The tenant's domain (contoso.onmicrosoft.com) works in place of the ID.
• Email. With the email scope, Entra includes email for users who have a mail address on their account. Adding email as an optional claim under Token configuration is harmless but not needed, and editing the manifest by hand is not needed either. Users without a mail address have no email: they can still sign in, but they cannot be linked to an existing console account by address, and an Allowed email domains list refuses them.
• Usernames for new accounts come from preferred_username, which in Entra is the user principal name: jane.doe@contoso.com becomes jane_doe_contoso_com.
• given_name and family_name are not used, so there is no need to add them.

Keycloak

Tested end to end, console and RustDesk client.

1. In your realm, Clients → Create client: OpenID Connect, a client ID such as cortendesk.
2. Client authentication: On. Authentication flow: Standard flow only.
3. Valid redirect URIs: both callback URLs from the table above. Valid post logout redirect URIs: https://desk.example.com/login.
4. Credentials tab: copy the client secret.

In CortenDesk: Provider URL https://keycloak.example.com/realms/<realm>, plus the client ID and secret.

If the console reaches Keycloak at a different address than browsers do (for example http://keycloak:8080 inside a Docker network), put the internal address in Provider URL and the browser's origin, such as https://keycloak.example.com, in Browser-facing provider URL. That field takes the scheme, host and port only, no path. Keycloak's issuer must be the same on both addresses: set its hostname (KC_HOSTNAME) to the public one.

Google Workspace

Checked against Google's live discovery and signing keys.

1. Google Cloud console → APIs & Services → OAuth consent screen. For a Workspace organization choose Internal, so only your users can sign in.
2. Credentials → Create credentials → OAuth client ID, type Web application. Add both callback URLs under Authorized redirect URIs.
3. Copy the client ID and secret.

In CortenDesk: Provider URL https://accounts.google.com. Add your domain under Allowed email domains if the consent screen is External.

Google has no sign-out endpoint, so Sign out of the provider too has no effect there; signing out of the console still works. Google sends no preferred_username, so new usernames come from the person's name.

Authentik

Written from Authentik's documentation; not tested end to end here.

1. Applications → Providers → Create → OAuth2/OpenID Provider. Client type Confidential. Add both callback URLs as redirect URIs. Pick a Signing Key so tokens are signed with RS256.
2. Applications → Create an application using that provider. Note its slug.

In CortenDesk: Provider URL https://authentik.example.com/application/o/<slug>/, plus the client ID and secret. Leave Require the provider to assert email verification off.