Set up your identity provider

For SSO, the callback URL, sign-out URL, initiate login link, application type, grant type, scopes and claims, and the issuer in Okta, Auth0, Entra and Ping.

Create a web application in your identity provider, then bring its issuer, client ID and client secret to Settings, Single sign-on.

You do not have to copy these values from this page. Settings, Single sign-on shows them under Set up your identity provider. The callback, the sign-out URL, the initiate login URL and the scopes each have a copy button, and the initiate login URL is built for each of your verified domains.

Settings for the app in your provider

Setting	Value
Application type	Web application: a confidential client that keeps a secret. Not a single-page app, not a native app.
Grant type	Authorization code with PKCE, challenge method `S256`. No implicit flow, no client credentials.
Sign-in redirect URI (callback)	`https://api.tapper.ai/auth/sso/callback`
Sign-out redirect URI	`https://app.tapper.ai/log-in`
Initiate login URI (app tile)	`https://app.tapper.ai/sso/<your-verified-domain>`
Scopes	`openid email profile`
Claims	An `email` that is not explicitly marked unverified, plus the person's name.
CORS or trusted origins	Nothing to add.

Application type

Tapper's sign-in runs on Tapper's servers and uses your client secret, so the app has to be the confidential kind. A single-page or native app cannot hold a secret and does not work.

PKCE

Tapper always sends the PKCE challenge, so leave PKCE switched on even though the client is confidential.

This is the address your provider opens when someone clicks the Tapper tile. Use the link for a domain you have verified, such as https://app.tapper.ai/sso/acme.com. You can also use https://app.tapper.ai/sso, which asks for a work email first. Neither link sends anyone to your provider until their email domain is verified.

Claims

Your provider must return an email address. A sign-in with no email, or with one your provider explicitly marks as unverified (email_verified: false), is refused. A provider that does not send that flag at all, as many corporate directories do, is fine. The profile scope also brings the person's name, which fills in a new account.

CORS

There is nothing to configure. Sign-in happens as a redirect in the browser's address bar. No Tapper page calls your provider from JavaScript, so no trusted-origin or CORS entry is needed.

Where the issuer lives

Create an OIDC Web Application. The issuer is your org authorization server: https://your-company.okta.com, with nothing after the host. Do not use a custom authorization server such as https://your-company.okta.com/oauth2/default. It has its own access policies and refuses to issue the sign-in code unless a policy includes the Tapper application, so people see "You are not allowed to access this app" even when they are assigned to it.

Then decide who may sign in: assign the users or groups who should have Tapper, or switch on Federation Broker Mode so everyone in the org can. Okta refuses the sign-in for anybody who is neither assigned nor covered by that setting, with the same "You are not allowed to access this app" message.

Any provider that publishes a standard OpenID Connect discovery document works, not only these four.

Check it

Back in Tapper, click Test connection on the single sign-on page. It reads the discovery document and the signing keys from the issuer and reports the first step that fails, so you can fix the issuer before anyone tries to sign in. See Single sign-on for the rest of the set-up.