Skip to main content
Security

Set up SSO with Okta

Connect Okta to Tinct with OpenID Connect or SAML 2.0: what to set on each side.

Last updated 11 days ago

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

Okta speaks both protocols Tinct accepts. Choose OpenID Connect unless your organisation has standardised on SAML: it takes fewer steps and has no certificate to renew.

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 Okta Admin Console (Okta Identity Engine) 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 Okta account that can create app integrations (a super administrator or an application administrator), and an Okta user whose email address is on a verified domain, to run the test sign-in with.

Option A: OpenID Connect

1. Create the app integration

  1. In the Okta Admin Console, go to Applications → Applications and click Create App Integration.
  2. Sign-in method: OIDC - OpenID Connect. Application type: Web Application. Click Next.
  3. App integration name: Tinct.
  4. Grant type: keep Authorization Code only.
  5. Sign-in redirect URIs: Tinct gives you its redirect URI in step 3; leave Okta's example for now, you will replace it. Remove the example under Sign-out redirect URIs.
  6. Assignments: choose Limit access to selected groups and pick the groups that use Tinct, or Allow everyone in your organization to access.
  7. Click Save.
  8. On the General tab, copy the Client ID and the Client secret. Client authentication must be Client secret. You can tick Require PKCE as additional verification: Tinct always sends it.

2. Describe Okta in Tinct

  1. In Tinct, go to Settings → Security, to the Identity provider card, and keep OpenID Connect.
  2. Fill in:
    • Issuer: your Okta address, for example https://acme.okta.com, with no / at the end. Not the Admin Console's address, which has -admin in it (https://acme-admin.okta.com). If your company uses its own authorization server (Security → API → Authorization Servers), give its Issuer URI instead, for example https://acme.okta.com/oauth2/default.
    • Client ID: the client ID from step 1
    • Client secret: the secret from step 1
  3. Click Save identity provider.

3. Register the redirect URI

  1. Copy the Redirect URI the card now shows.
  2. In Okta, open the app integration, click Edit in the General Settings section, replace the example under Sign-in redirect URIs with it, and click Save.

Okta releases the openid, profile and email scopes Tinct asks for without any change.

Then go to Test, then enable.

Option B: SAML 2.0

1. Get Tinct's values

  1. In Tinct, go to Settings → Security, to the Identity provider card.
  2. Under Protocol, choose SAML 2.0. If no connection exists yet, click Get the values for my provider.
  3. Keep the card open: you need its Service provider entity ID and its Single sign-on URL (ACS).

2. Create the app integration

  1. In the Okta Admin Console, go to Applications → Applications and click Create App Integration.
  2. Sign-in method: SAML 2.0. Click Next.
  3. App name: Tinct. Tick Do not display application icon to users unless you turn on sign-in from the provider in Tinct (see below). Click Next.
  4. Under SAML Settings, fill in:
    • Single sign-on URL: Tinct's Single sign-on URL (ACS). Keep Use this for Recipient URL and Destination URL ticked.
    • Audience URI (SP Entity ID): Tinct's Service provider entity ID, pasted as is
    • Default RelayState: leave it empty
    • Name ID format: Persistent
    • Application username: Custom, with user.getInternalProperty("id"). This is the identifier Okta gives each person, which does not change when their username or email address does.
  5. Leave Show Advanced Settings as it is: Okta signs the response and the assertion with RSA-SHA256, and does not encrypt the assertion. If you do turn on Assertion Encryption, keep the Key Transport Algorithm on RSA-OAEP (Tinct refuses RSA15) and an AES encryption algorithm. Click Next.
  6. Choose This is an internal app that we have created, and click Finish.

⚠️ If your organisation cannot use a custom application username, choose the EmailAddress Name ID format with Email as the application username. Tinct recognises a person by the NameID, so when someone's email address changes in Okta, Tinct refuses their sign-in: their account stays linked to the old address.

3. Send the email and the names

Okta sends no attribute to a new SAML app, and the creation wizard does not ask for them. Open the app's Sign On tab, go to Attribute statements, and add three expressions:

NameExpression
emailuser.profile.email
firstNameuser.profile.firstName
lastNameuser.profile.lastName

If a name format is asked for, Basic or Unspecified both do: Tinct matches on the name.

4. Assign the app

On the app's Assignments tab, click Assign, and assign the groups (or the people) that use Tinct. Okta refuses the sign-in of anyone who is not assigned.

When you assign a person, Okta shows their Username for the app, prefilled with their Okta identifier (00u…). Leave it as it is. Despite its label, it is not a name to display: it is the NameID Okta sends, the key Tinct links their account to. Their name comes from the firstName and lastName statements. Replace it, and their Tinct account is linked to the new value, then refused once the identifier comes back.

5. Describe Okta in Tinct

  1. In Okta, on the app's Sign On tab, copy the Metadata URL (https://<your Okta address>/app/<an identifier>/sso/saml/metadata).
  2. Back in Tinct, under Values from your identity provider, choose Metadata URL, and paste it.
  3. Click Save identity provider. Tinct reads Okta's entity ID, sign-on URL and signing certificate from it.

Leave Attribute names empty: email, firstName and lastName are among the names Tinct looks for.

To start sign-in from the Okta dashboard, turn on Allow sign-in started from the identity provider in Tinct, and untick Do not display application icon to users in Okta. Leave both as they are otherwise: see Sign-in started from your provider.

Test, then enable

  1. In the Status card, click Test sign-in. A pop-up opens on Okta's sign-in page.
  2. Sign in as an Okta user assigned to the app whose email address is on one of your verified domains.
  3. The result page shows the email address and the names Tinct received.
  4. Back on the Security page, click Enable.

Tinct only lets in addresses on your verified domains, and, when Create accounts at first sign-in is off, only people you invited.

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

If something goes wrong

  • Okta says you are not assigned to the application. Assign the person, or a group they belong to (OpenID Connect: step 1, SAML: step 4).
  • Okta shows The 'redirect_uri' parameter must be a Login redirect URI in the client app settings (OpenID Connect). Sign-in redirect URIs does not hold Tinct's Redirect URI exactly.
  • Tinct says the issuer could not be used (OpenID Connect). The issuer must be exactly what Okta announces: your Okta address, without -admin and with no / at the end, or the authorization server's Issuer URI. With a custom domain, use the address the authorization server shows as its issuer.
  • Tinct says no email address was sent. On SAML, the email attribute statement is missing (step 3). On either protocol, check that the user has an email address in Okta.
  • Tinct says the address is not on a verified domain. The user's email address in Okta is on another domain: verify that domain, or test with another user.
  • The response is refused for its audience or destination (SAML). Audience URI or Single sign-on URL in Okta is not exactly Tinct's value.

When Okta's keys change

  • OpenID Connect: nothing to do. Tinct reads the current keys from Okta.
  • SAML: Okta's SAML certificate is valid for ten years. To rotate it, generate a new one on the app's Sign On tab (SAML Signing Certificates → Generate new certificate), download it, and register it in Tinct's Signing certificates card as the second certificate. Then Activate it in Okta, and remove the old one from Tinct: see Rotate without downtime. If you activate it in Okta first, Tinct notices the change in the metadata within a day, emails your admins, and offers to apply it; sign-ins fail until then.