Single Sign On

We optionally support single sign-on (SSO) on all Tines tenants, paid and Community Edition alike.

This allows users on your Tines account to sign in with their existing account on your external identity provider.

Enabling SSO 

To turn SSO on or off for your tenant, go to "Authentication settings" in the settings menu and follow the instructions.


SAML configuration 

Setting up SSO via SAML requires two pieces of information from your external SAML identity provider (IdP):

  1. A URL, which we’ll redirect users to when signing in.

  2. Your IdP’s X.509 public certificate. You can also instead use a fingerprint, which is a digest of the certificate. This must be generated using SHA-256, such as with Using the fingerprint instead is discouraged, as it prevents extra security features.

Enhanced SAML Security 

Tines also supports additional SAML security features, such as encryption and signing. Contact our support team if you'd like to enable these for your tenant.

OIDC configuration 

Setting up SSO via OpenID Connect (OIDC) requires six pieces of information from your external OpenID provider (OP):

  1. Your OAuth client ID.

  2. Your OAuth client secret.

  3. The authorization endpoint URL - e.g. for Google or https://<YOUR-DOMAIN>/oauth2/authorize for AWS Cognito.

  4. The token endpoint URL - e.g. for Google or https://<YOUR-DOMAIN>/oauth2/token for AWS Cognito.

  5. The issuer or issuer identifier URL - e.g. for Google or https://cognito-idp.<YOUR-REGION><YOUR-USER-POOL-ID> for AWS Cognito.

  6. The JSON Web Key Set (JWKS) URL - e.g. for Google or https://cognito-idp.<YOUR-REGION><YOUR-USER-POOL-ID>/.well-known/jwks.json for AWS Cognito.

Items 3 to 6 can be found in your OP’s "provider metadata" or "discovery document", which is normally located at a URL that ends with .well-known/openid-configuration - e.g. for Google or https://cognito-idp.<YOUR-REGION><YOUR-USER-POOL-ID>/.well-known/openid-configuration for AWS Cognito.

Tines requires that your OP supports the "Authorization code grant" OAuth flow and the "email", "openid" and "profile" OAuth scopes.

Just-in-time user provisioning 

With SSO enabled via SAML or OIDC, administrators can optionally enable just-in-time user provisioning. When enabled, administrators can provide a json configuration mapping a group on their SSO identity provider to a Tines team and role. Once setup, a user signing into Tines for the first time will automatically be placed in the designated team and role mapped to their SSO group in the configuration json without requiring an invitation to the tenant.

Note: A change to the just-in-time configuration will not update existing users' teams and roles.

To setup:

  1. Enable the checkbox entitled "Enable automatic provisioning of SSO users when first accessing the tenant"

  2. Fill in the following blank fields in the json editor:

  • The group_attribute_name field should be filled in with the name of the SAML or OIDC attribute containing a user's group name. In the example below the value for this field would be "Group"

An example of a Group Attribute Statement configuration in Okta.

  • The tenant_owners_group (optional). When provided, users in the SSO group matching this field will be provisioned as tenant owners.

  • An object in the mappings array containing an sso_group with a value matching the name of the desired group in your identity provider, team_name with a value matching the name of the Tines team users from this SSO group should be placed into, and role_name with a value matching the desired team role for those users (team_admin, editor, or viewer). In scenarios where a user is mapped to a team via more than one group, the first applicable entry in the list will be used.

The following example shows how to assign the SSO group called Administrators to get "Tenant Owner" status, and assign members of several groups to join specific teams with different roles.

  "tenant_owners_group": "Administrators",
  "mappings": [
    { "sso_group": "Administrators", "team_name": "Analytics", "role_name": "TEAM_ADMIN" },
    { "sso_group": "Managers", "team_name": "Analytics", "role_name": "TEAM_ADMIN" },
    { "sso_group": "Managers", "team_name": "Incident Response", "role_name": "EDITOR" },
    { "sso_group": "Analysts", "team_name": "Analytics", "role_name": "EDITOR" },
    { "sso_group": "Everyone", "team_name": "Incident Response", "role_name": "VIEWER" },

Optional: For a new user's first name, last name, and avatar to be automatically configured when signing on, the givenname, surname, and avatar attributes can be added to the SAML statement or OIDC claim.

Was this helpful?