Skip to main content
Passport signs people in through your identity provider using OpenID Connect (authorization code with PKCE). Each workspace brings its own IdP, configured in Settings. Sign-in is available on the Enterprise plan.

​
How it works

When SSO is configured, the sign-in page redirects to your IdP. Passport exchanges the authorization code for tokens, then validates the ID token cryptographically: the signature against your IdP’s JWKS, plus the issuer, audience, and a per-attempt nonce. The email address is taken from the verified token (falling back to the userinfo endpoint only if the token omits it), and it must be a verified email. This is what proves your IdP actually vouched for the identity rather than trusting an unsigned response.
Passport does not hard-fail when the IdP omits the email_verified claim entirely (Microsoft Entra and some Okta or Google configurations do). Because your admin configured that exact issuer and the ID token is already cryptographically validated, an absent claim is trusted. An explicit email_verified: false is still rejected.

​
What you need

Issuer URL

Your IdP’s issuer, for example https://your-org.okta.com. Passport reads its discovery document at /.well-known/openid-configuration.

Client ID and secret

From a web application (confidential client) you register in your IdP.

Redirect URI

https://<your-passport-host>/auth/callback
The requested scopes are openid email profile.
The issuer URL is validated when you save it. In production it must be a public HTTPS endpoint. Passport resolves the host and refuses issuers that point at private, loopback, link-local, or cloud-metadata addresses, and re-checks on every redirect it follows. An internal or non-HTTPS issuer will be rejected with “That identity-provider URL isn’t allowed.”

​
Configure SSO in Passport

1

Register an application in your IdP

Create a web application (confidential client) with the redirect URI https://<your-passport-host>/auth/callback. Note the client ID and client secret.
2

Enter the details in Settings

In Passport, open Settings and set the issuer URL, client ID, and client secret. The secret is encrypted at rest. Save.
3

Test the sign-in

Sign out and visit the sign-in page. It should redirect to your IdP and return you signed in.
When a workspace uses its own configured IdP, the IdP vouching for a person is treated as proof they belong to the company, so they auto-join. If the workspace has no admin yet, the first person to sign in through its own IdP becomes the admin.

​
Okta walkthrough

1

Create the app integration

In the Okta Admin Console, go to Applications, then Create App Integration. Choose OIDC - OpenID Connect and Web Application.
2

Set the redirect URI

Under Sign-in redirect URIs, add https://<your-passport-host>/auth/callback.
3

Assign users

Assign the people or groups who should be able to sign in.
4

Copy the credentials

From the app’s General tab, copy the Client ID and Client secret. Your issuer is your Okta org URL, for example https://your-org.okta.com.
5

Enter them in Passport

Paste the issuer, client ID, and secret into Passport Settings and save.

​
Microsoft Entra ID walkthrough

1

Register an application

In the Microsoft Entra admin center, go to App registrations, then New registration.
2

Set the redirect URI

Add a Web platform redirect URI of https://<your-passport-host>/auth/callback.
3

Create a client secret

Under Certificates and secrets, create a new client secret and copy its value.
4

Find your issuer

Your issuer is https://login.microsoftonline.com/<tenant-id>/v2.0. Use the tenant ID from the app’s Overview page.
5

Enter them in Passport

Paste the issuer, the Application (client) ID, and the client secret into Passport Settings and save.
Entra typically omits email_verified. Passport handles this correctly, as described above, so Entra sign-in works without extra configuration.