Set up SSO with Amazon Cognito

Part of Single sign-on (SSO) for your workspace: step 2 of 3, on Amazon Cognito.

An Amazon Cognito user pool connects to Tinct with OpenID Connect. Cognito cannot send SAML to an application: it only accepts SAML from another provider. If your people already sign in to Cognito through Okta, Microsoft Entra ID or another SAML provider, that still works: Cognito passes them on to Tinct over OpenID Connect.

You must be an admin of the workspace, and the workspace must be entitled to single sign-on. The screens below are those of the Amazon Cognito console as of 2026.

Before you start

• Verify at least one email domain: Verify your email domain. You can describe the connection first, but you cannot enable it until a domain is verified.
• Have an AWS account that lets you manage Cognito user pools, and a user of the pool whose email address is on a verified domain, to run the test sign-in with.
• Know the User pool ID of the pool your people sign in to, for example eu-west-3_AbC123xyz.

⚠️ Tinct lets in any user of the pool whose address is on one of your verified domains. It does not rely on Cognito's email verified flag: your verified domain is what counts. So only your administrators should be able to give a user an address on your domain. In the pool, under Authentication → Sign-up:

* turn Self-registration off, and create users yourself (User management → Users → Create user);

* keep Keep original attribute value active when an update is pending on for email, so that a user who changes their address keeps the old one until they confirm the new one.

1. Create the app client

In the pool, go to Applications → App clients, click Create app client, choose Traditional web application, name it Tinct, leave Return URL empty (Tinct gives you the redirect URI in step 3), and click Create app client.

1. On the App client information card, check that there is a Client secret. Tinct needs one. A client created without a secret cannot be given one later: create another client.
2. Copy the Client ID and the Client secret (click Show client secret).
3. Go to the Login pages tab and click Edit on Managed login pages configuration:
   • Identity providers: Cognito user pool directory, plus any corporate provider your people sign in to Cognito through;
   • OAuth 2.0 grant types: Authorization code grant only;
   • OpenID Connect scopes: OpenID, Email and Profile. Tinct asks for all three, and Cognito refuses the sign-in with invalid_scope when one is missing.
4. Leave Allowed callback URLs as it is for now, and click Save changes.

2. Describe Cognito in Tinct

1. In Tinct, go to Settings → Security, to the Identity provider card, and keep OpenID Connect.
2. Fill in:
   • Issuer: https://cognito-idp.<region>.amazonaws.com/<user pool ID>, for example https://cognito-idp.eu-west-3.amazonaws.com/eu-west-3_AbC123xyz. The Region is the first part of the pool ID.
   • Client ID: the client ID from step 1
   • Client secret: the secret from step 1
3. Click Save identity provider.

💡 The issuer is the cognito-idp address, not your sign-in domain (….auth.<region>.amazoncognito.com or your custom domain). Tinct finds the sign-in domain by itself.

3. Register the redirect URI

1. Copy the Redirect URI the card now shows.
2. In Cognito, open the app client, go to Login pages, click Edit, and paste it into Allowed callback URLs. Remove any placeholder address the console put there. Click Save changes.

Test, then enable

1. In the Status card, click Test sign-in. A pop-up opens on Cognito's sign-in page.
2. Sign in as a user of the pool whose email address is on one of your verified domains. A user you just created with a temporary password is asked to choose a new one first.
3. The result page shows the email address and the names Tinct received.
4. Back on the Security page, click Enable.

When you are confident, go on to Require SSO in your workspace.

If something goes wrong

• Cognito shows redirect_mismatch or An error was encountered with the requested page. Allowed callback URLs does not hold Tinct's Redirect URI exactly.
• Cognito shows invalid_scope. One of OpenID, Email and Profile is not ticked on the app client (step 1).
• Cognito shows unauthorized_client. Authorization code grant is not ticked, or the Cognito user pool directory is not among the client's identity providers.
• Cognito's sign-in page says the login pages are unavailable. The app client has no managed login style: go to Branding → Managed login, click Create a style, and pick the app client.
• Tinct says the issuer could not be used. Check the Region and the User pool ID in the issuer, and that nothing follows the pool ID (no / at the end).
• Tinct says the provider refused the code exchange. The client secret is wrong, or the client has none (step 1).
• Tinct says no email address was sent. The user has no email attribute, or the Email scope is not ticked.
• The names are empty. The user has no given_name and family_name in Cognito, or the Profile scope is not ticked. Tinct only uses them to fill in a new account.
• Tinct says the address is not on a verified domain. The user's email address in Cognito is on another domain: verify that domain, or test with another user.

Good to know

• Keys. Cognito signs with keys it publishes itself; Tinct reads them from Cognito. Nothing to do when they change.
• One pool, one connection. Tinct recognises each person by their Cognito identifier (sub), which belongs to the user pool. Moving to another pool means changing the issuer in Tinct, and everyone is linked again by email address at their next sign-in.
• Session length. After the session length set in the Provisioning card, Tinct sends people back to Cognito. They get through without typing anything while their Cognito session is still open.