Breadcrumbs

Setting up Single Sign-On for RAP

Setting Up Google and Microsoft SSO in RAP

This guide explains how to configure Single Sign-On (SSO) so users can log in to RAP with their Google or Microsoft (Azure AD / Entra ID) account instead of a local RAP password.

Overview

RAP supports SSO login via Google and Microsoft only (no other providers are currently supported). Each provider is configured independently, and both can be enabled at the same time.

At a high level, setting this up involves three parts:

  1. Register an OAuth application with Google and/or Microsoft, so they trust RAP to request logins.

  2. Configure the provider in RAP's Admin panel, giving it the credentials from step 1.

  3. Pre-create the RAP user accounts that are allowed to sign in via SSO, and link each one to the matching provider and email address.

Step 3 is easy to miss — SSO login in RAP does not automatically create new accounts. See Provisioning users for SSO below; skipping this step is the most common reason a user's SSO login fails.

Prerequisites

  • You'll need admin access to RAP (a user with permission to manage Admin settings).

  • You'll need admin access to the relevant Google Cloud Console project and/or Azure Portal / Entra ID tenant.

  • RAP must be served over HTTPS in any production environment — both Google and Microsoft require (or strongly prefer) HTTPS redirect URIs, and RAP's own CSRF-state cookie is marked Secure when the request arrives over HTTPS.

  • Before adding any provider in the Admin UI, the RAP server needs a master encryption key configured (RAP_MASTER_KEY) — see Server prerequisite: RAP_MASTER_KEY below. Without it, client secrets entered in the Admin UI will not actually be saved.

  • Know your RAP server's public base URL (e.g. https://rap.yourcompany.com) — you'll need it to build the redirect/callback URL each provider needs to be told about.

Server prerequisite: RAP_MASTER_KEY

RAP encrypts each provider's client secret before storing it in the database, using AES-256-GCM. This requires a 32-byte encryption key, provided to the server as the RAP_MASTER_KEY environment variable.

Ask whoever manages the RAP server deployment to:

  1. Generate a key:

    openssl rand -base64 32

  2. Set it as the RAP_MASTER_KEY environment variable on the RAP server (or as a Docker/Kubernetes secret, if that's how your deployment manages sensitive values), then restart the RAP server so it picks it up.

Important: if RAP_MASTER_KEY is not set, any client secret entered into the Admin UI is silently not stored. If you configure a provider before this key is in place, go back afterwards and re-enter the client secret once the key is set.

(There's also a legacy fallback — a IDP_SECRET_MICROSOFT / IDP_SECRET_GOOGLE environment variable can supply the secret instead. New setups should use RAP_MASTER_KEY and the Admin UI field; the environment-variable route is only there for backward compatibility and shouldn't be needed for a new configuration.)

The redirect (callback) URL

Both Google and Microsoft need to be told exactly where to send the user back to after they log in. RAP's redirect URL always follows this pattern, based on your RAP server's public base URL:

https://<your-rap-server>/sso/callback/google
https://<your-rap-server>/sso/callback/microsoft

For example, if RAP is served at https://rap.yourcompany.com, the Microsoft redirect URI is:

https://rap.yourcompany.com/sso/callback/microsoft

You'll enter this exact URL when registering the application in Google Cloud Console / Azure Portal in the steps below. RAP also auto-fills this value when you create the provider in its own Admin UI, and shows it (read-only, with a copy button) once the provider exists — handy for double-checking it matches what you registered externally.

Setting up Google SSO

1. Register an OAuth client in Google Cloud Console

  1. Go to the Google Cloud Console and select (or create) the project you want to use for RAP.

  2. Configure the OAuth consent screen if you haven't already (Google requires this before you can create credentials).

  3. Go to APIs & Services → Credentials → Create Credentials → OAuth client ID.

  4. Choose Application type: Web application.

  5. Under Authorized redirect URIs, add:

    https://<your-rap-server>/sso/callback/google

  6. Save, then note down the Client ID and Client secret Google generates — you'll need both in RAP's Admin UI.

No special API scopes need enabling — RAP only requests the standard openid email profile scopes.

2. Add the provider in RAP

See Adding a provider in RAP's Admin UI below. For Google, leave Tenant ID blank (it doesn't apply).

By default, RAP will accept a login from any Google account. If you want to restrict logins to accounts belonging to your organisation's Google Workspace, add your Workspace domain(s) (e.g. yourcompany.com) under Allowed tenants — see Restricting who can sign in.

Setting up Microsoft (Azure AD / Entra ID) SSO

1. Register an app in Azure Portal

  1. Go to the Azure Portal → Microsoft Entra ID → App registrations → New registration.

  2. Give it a name (e.g. "RAP SSO").

  3. Under Supported account types, choose the option matching who should be able to sign in (typically "Accounts in this organizational directory only" for a single-tenant setup).

  4. Under Redirect URI, choose platform Web and enter:

    https://<your-rap-server>/sso/callback/microsoft

  5. Register the app, then note down:

    • Application (client) ID

    • Directory (tenant) ID

  6. Go to Certificates & secrets → New client secret, create one, and copy its value immediately (Azure only shows it once). This is the client secret you'll enter into RAP.

No additional API permissions need to be granted — RAP only requests the standard OpenID Connect openid email profile scopes, which don't require admin consent.

2. Add the provider in RAP

See Adding a provider in RAP's Admin UI below. For Microsoft, Tenant ID is required — use the Directory (tenant) ID from step 1.

Adding a provider in RAP's Admin UI

  1. Log in to RAP as an administrator.

  2. Go to Admin → Identity Providers.

  3. Click Add Identity Provider.

  4. Fill in the fields:

    FieldNotesProvider typeGoogle or Microsoft. Can't be changed after the provider is created.EnabledTurn this off to temporarily disable a provider without deleting its configuration.Client IDFrom Google Cloud Console / Azure Portal.Tenant IDMicrosoft only — the Directory (tenant) ID from Azure Portal. Not shown for Google.Client SecretFrom Google Cloud Console / Azure Portal. Requires RAP_MASTER_KEY to be configured on the server (see above) or it won't be saved. When editing an existing provider, leave this blank to keep the currently stored secret.Allowed tenantsOptional access restriction — see Restricting who can sign in. Leave empty to allow any account from the provider.Auto-provision / Require admin approval for account linkingSee Known limitation below — these currently have no effect.

  5. Save. The provider takes effect immediately — no server restart is needed.

  6. Once saved, re-open the provider to see its auto-generated Redirect URI field — confirm it exactly matches what you registered with Google/Microsoft in the steps above.

You can configure one Google provider and one Microsoft provider at a time (the "Add" button disables once both exist).

Restricting who can sign in

By default, a provider accepts a login from any account that provider issues a token for — anyone with a Google account, or anyone in any Azure AD tenant. The Allowed tenants field on each provider restricts this:

  • Microsoft: add one or more Azure AD tenant GUIDs. Only users belonging to a listed tenant can sign in. This is validated against the token's tid claim, not just the user's email domain.

  • Google: add one or more Google Workspace hosted domains (e.g. yourcompany.com). Only accounts belonging to a listed Workspace domain can sign in. Personal @gmail.com accounts won't match a domain restriction.

Leave this field empty to allow any account from that provider to attempt to sign in — note this only controls whether RAP will process the login at all; the user still needs a matching pre-provisioned RAP account (next section) to actually get in.

Provisioning users for SSO

This is the step most likely to be missed. RAP does not automatically create a new user account the first time someone signs in via SSO — an admin must pre-create the account first, matching it to the provider and email address that will be used to sign in.

  1. Go to Admin → Users → Add User.

  2. In the Provider field, select Microsoft or Google (instead of Local). The password fields will disappear — SSO users don't have a local RAP password.

  3. Enter the user's email address exactly as it appears in their Google/Microsoft account — this is what RAP matches against on first login.

  4. Set up the user's groups/permissions as normal, then save.

  5. The user can now sign in via the "Sign in with Google/Microsoft" button on the RAP login page. On their first successful SSO login, RAP links their external account to this RAP user record; from then on they'll be recognised automatically.

If a user tries to sign in via SSO without a matching pre-created account (matching provider + email), the login will fail.

Known limitation: Auto-provision / approval toggles

The Admin UI currently shows Auto-provision and Require admin approval for account linking toggles on each provider. As of this writing, these settings are not yet wired up to any behaviour — regardless of how they're set, a user account still must be pre-created by an admin as described above before that user can sign in via SSO. Don't rely on these toggles to enable self-service account creation yet.

Enabling SSO on the login page

The "Sign in with Google / Microsoft" buttons on RAP's login page appear automatically once at least one enabled provider exists — no separate switch is needed for a standard deployment.

If your deployment's SPA is built with a custom rapConfig.json, note it contains an ssoEnabled flag (defaults to true). This would only need to be set to false if you specifically want to hide the SSO buttons on the login page even while providers are configured server-side — most deployments can leave this alone.

Testing it

  1. Open RAP's login page in an incognito/private browser window.

  2. Confirm the "Sign in with Google" and/or "Sign in with Microsoft" button(s) appear.

  3. Click through and sign in with an account matching a pre-provisioned RAP user (see above).

  4. You should land back in RAP, logged in as that user.

Troubleshooting

Symptom

Likely cause

No SSO button appears on the login page

No provider is Enabled in Admin → Identity Providers, or GET /sso/providers isn't reachable from the SPA — check server connectivity and that at least one provider is enabled.

Provider redirects back with an error, or "redirect URI mismatch"

The redirect URI registered in Google Cloud Console / Azure Portal doesn't exactly match RAP's — compare it against the Redirect URI field shown when editing the provider in RAP.

Redirect URI RAP generated is http:// instead of https://

RAP is behind a reverse proxy/load balancer that isn't forwarding the original protocol. Ensure the proxy sends X-Forwarded-Proto: https (and X-Forwarded-For) to the RAP server.

User completes provider login but RAP says login failed

No matching pre-provisioned RAP user exists for that provider + email combination — see Provisioning users for SSO. Also check the email is verified by the provider (RAP requires an OIDC-verified email for the first-login account-linking match).

Client secret doesn't seem to "stick" after saving a provider

RAP_MASTER_KEY isn't configured on the server — see Server prerequisite. Set it, restart the server, then re-enter the client secret.

Only some users in our Azure tenant / Google Workspace can sign in, others can't, even though all are pre-provisioned

Check the Allowed tenants field isn't restricting to the wrong tenant ID / domain.

Notes on how this works (for reference)

  • RAP uses the standard OAuth 2.0 Authorization Code flow with PKCE, plus OpenID Connect ID token validation (issuer, audience, nonce, and tenant/domain checks) — not a bundled vendor SDK.

  • Client secrets are encrypted at rest (AES-256-GCM) and are never returned by RAP's API once saved — only re-enter a secret if you're changing it.

  • An SSO session's lifetime tracks RAP's normal license-server session, the same as a password login — there's nothing SSO-specific to configure for session length.