Skip to content

Identity Providers

Taiga Cloud hands off identity authentication to an external provider. Thus, every Taiga Cloud account has an identity held in an identity provider. Today there is exactly one, and it is not one you choose or configure.

Okta, exclusively

All authentication is backed by Okta. There is no alternative provider, and no way to bring your own — no federating your organisation's directory, no SAML or OIDC connection into your tenant, and no "sign in with Google" or similar.

You never deal with Okta directly. Your client talks only to the Taiga Cloud API: the device code flow returns a Taiga Cloud token, and nothing in your code needs an Okta client, an Okta URL or an Okta credential of its own.

Further providers may follow

Support for additional identity providers is something we have scope to add. Nothing else is supported today, and there is no date — so do not design around it.

If it happens, the API contract does not change: the same flow, the same endpoints, the same kind of token. That is the reason it is safe to build against the API now.

Identities are provisioned by Taiga Cloud

There is no self-registration

A Taiga Cloud identity can only be created by Taiga Cloud. You cannot sign yourself up — not from the portal, not from the API, and not from these docs. There is no registration endpoint to find.

Access starts in one of two ways, both covered in Get started:

  • Someone who already administers your customer or project invites you
  • Your organisation is new to Taiga Cloud, in which case it starts with a conversation — Contact sales in the Help menu above

An account with your own organisation's Okta is not a Taiga Cloud account. They are separate directories, and having one says nothing about the other.

What this looks like if you have no account yet

The approval step in the device code flow has nothing to approve against. It fails rather than offering to register you, which is easy to mistake for a broken flow.

Where it appears in the API

User records carry an idp_provider field:

{
  "email": "someone@example.com",
  "idp_provider": "okta"
}

Today it is okta for every identity, so there is nothing useful to branch on. It exists so that a second provider would be visible in the data rather than invisible, and it is the field to watch if that ever happens.

What this means for your client

  • Treat the bearer as opaque. Do not decode it or read provider-specific claims out of it. What a token contains is not part of the contract; what it authorises is
  • Do not hardcode any Okta endpoint. You never need one — every call your client makes is to the Taiga Cloud API
  • Get tokens one way, through the device code flow, and refresh them rather than re-authenticating a person each time

Doing those three things means a change of provider, if it comes, is invisible to your client.