Set Up Your Identity Provider
The callback URL, the sign-out URL, the initiate-login link, the application type, the grant type, the scopes and the claims - and where to find the issuer in Okta, Auth0, Microsoft 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 off this page. Settings → Single sign-on shows the same list under Set up your identity provider, each with a copy button, and builds the sign-in link for your own domains.
Values Tapper Needs From You
| Setting | Value |
|---|---|
| Application type | Web application - a confidential client that keeps a secret. Not a single-page app, not native. |
| Grant type | Authorization code with PKCE, challenge method S256. Nothing else: no implicit, 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, never explicitly marked unverified, plus the person's name. |
| CORS / trusted origins | Nothing to add. |
Application type. Tapper's sign-in runs on our 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 will not work.
PKCE. Tapper always sends the PKCE challenge, so leave PKCE switched on even though the client is confidential.
The initiate login URI is the address your provider opens when someone clicks the Tapper tile. Use the link for a domain you have verified - https://app.tapper.ai/sso/acme.com. Before any domain is verified, https://app.tapper.ai/sso works too; it asks for a work email first.
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 simply does not send that flag - as many corporate directories do - is fine. The profile scope also brings the person's name, which is used to fill 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 ever 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.