Single Sign-On (SSO) using OpenID Connect (OIDC) allows your organization to authenticate users through a centralized Identity Provider (IdP), while Tagd acts as the relying party. Your identity provider stays in charge of authentication, including multi-factor authentication and conditional access, and Tagd never sees a password.
Prerequisite: An identity provider that supports OpenID Connect with the authorization code flow and a published discovery document (for example, Microsoft Entra ID (Azure AD), Okta or Google Workspace).
Important: Tagd authenticates to your token endpoint using client_secret_post. client_secret_basic, which is the default in most identity providers, is not supported. If your identity provider cannot use client_secret_post, use SAML 2.0 instead.
The following details are required when configuring your Identity Provider:
Parameter | Value |
Sign-in redirect URI | https://tagd-prod-platform.auth.eu-north-1.amazoncognito.com/oauth2/idpresponse |
Grant type | Authorization code |
Scopes | openid email profile |
Client authentication | client_secret_post |
ID token signing | RS256, ES256 or HS256, with a kid published at your JWKS endpoint |
In your Identity Provider create an application,
Create a new OpenID Connect application of type Web Application, a confidential client with a client secret. A single-page or native/mobile application type will not work
Set the grant type to Authorization Code and enter the sign-in redirect URI provided above
Set client authentication to client_secret_post
Configure the claims to be included in the ID token
email (Mandatory, granted by the email scope)
given_name (first name, granted by the profile scope)
family_name (last name, granted by the profile scope)
groups (Mandatory, minimum one group is required). If groups is listed under scopes_supported in your discovery document (https://<your-issuer>/.well-known/openid-configuration), nothing needs to be configured. Otherwise add a groups claim to the application. The claim must be issued in the ID token or userinfo response, not only in the access token. Group names may only contain letters, digits and . - * _ (for example Acme-Legal, not Acme Legal)
Assign test users to both the application and the group. A user who is not assigned cannot sign in
Choose a sign-out URL (Mandatory). Either your identity provider's sign-out endpoint, which also signs the user out of your identity provider, or a landing page such as your intranet. The URL must start with https://. Also add it to the application's sign-out redirect URIs
Choose your preferred sign-in alias, for example "company". Your login link will be https://prod.tagd.ai/api/v1/auth/login?org=company. Use lowercase letters, digits and hyphens only
Send the following details to [email protected]
Issuer URL, exactly as your discovery document reports it (https://, no trailing slash)
Client ID
Client secret, sent through a secure channel such as a password manager share link. Not in the body of an email or a chat message
Confirmation that client authentication is set to client_secret_post
Sign-out URL
Preferred sign-in alias
Test user email address
Group names to sync, spelled exactly as they appear in the groups claim
Claim names, if they differ from email, given_name, family_name and groups
Optional: a group that should grant the Tagd Administrator role
Name and email of a technical contact for the go-live
Never send user passwords, private keys or identity provider API tokens. Once provided, OpenID Connect authentication will be configured by our team for your organization.
Before rolling out SSO to all users the setup is tested together with someone from our team.
Open the login link and verify that it redirects straight to your identity provider
Perform a test login using an IdP user account, including any multi-factor step
Verify that the user's name and email appear correctly in Tagd
Verify that the user is added to the mapped group in Tagd and has the expected role
Verify that signing out ends the Tagd session and lands on your sign-out URL
Verify that a user who is not assigned to the application cannot sign in
We strongly recommend testing with a limited group of users first. Report any issues to [email protected]
Coordinate the go-live of the SSO integration in collaboration with your designated contact from our team:
Decide on go-live date, and make sure your technical contact is reachable during the go-live.
Assign users to the Tagd app in your identity provider. When a user signs in via SSO for the first time, their account will be automatically created or linked based on their email address. Group memberships from your identity provider add the user to the matching Tagd groups.
Inform your users about the setup and share the login link. Users sign in with their corporate credentials and do not need a separate Tagd password.