External Providers
External providers let users log in via your organisation's identity provider — Google Workspace, Microsoft Entra ID, or any OIDC-compliant IdP — instead of (or alongside) email and password.
How external login works
When a user selects an external login method, they are redirected to your identity provider to authenticate. On success, they are redirected back to TestOrchestrator and logged in. Their TestOrchestrator account is matched by email address.
Users must be pre-provisioned. External login is an authentication method only — it does not create accounts automatically. A user must already have a TestOrchestrator account (invited or manually created) before they can log in with an external provider. If no matching account exists, the login is denied.
Client secret is never returned by the API Once a client secret is saved, it is encrypted server-side and never included in API responses. When you open the edit form for an existing provider, the client secret field will be empty. Leave it blank to keep the existing secret. Only enter a value when you are intentionally rotating the secret.
Supported provider types
| Provider type | Issuer URL | Notes |
|---|---|---|
https://accounts.google.com |
Create OAuth 2.0 credentials in Google Cloud Console. Set the redirect URI to your workspace callback URL. | |
| Microsoft | https://login.microsoftonline.com/{tenant-id}/v2.0 |
Register an application in Microsoft Entra ID (Azure AD). Replace {tenant-id} with your directory (tenant) ID. |
| Generic OIDC | Your IdP's issuer URL | Supports any OIDC-compliant identity provider. The issuer URL must expose a /.well-known/openid-configuration discovery document. |
Field reference
| Field | Required | Default | Notes |
|---|---|---|---|
| Display name | Yes | — | The label shown on the login page button, e.g. "Log in with Google". |
| Provider type | Yes | Generic OIDC | Selects the provider template. Cannot be changed after creation. |
| Issuer URL | Yes | — | The base OIDC issuer URL. The system appends /.well-known/openid-configuration to discover endpoints. |
| Client ID | Yes | — | The application (client) ID from your identity provider's app registration. |
| Client secret | Yes (new only) | — | Required when adding a provider. Leave blank when editing to keep the existing secret. Enter a new value to rotate it. |
| Scopes | Yes | openid profile email |
Space-separated OIDC scopes to request. Must include openid and email. |
| Email claim | Yes | email |
The JWT claim that contains the user's email address. Used to match the TestOrchestrator account. |
| Name claim | Yes | name |
The JWT claim used for the user's display name. |
| Subject claim | Yes | sub |
The unique user identifier claim from the identity provider. Typically sub for most OIDC providers. |
Managing providers
External providers are managed on the External tab under Admin → Authentication. From the providers list you can:
- Add a new provider — opens a side panel with the configuration form
- Enable / Disable a provider — toggles whether the button appears on the login page
- Edit a provider — update any field except the provider type; leave client secret blank to keep the existing one
- Test a provider — verifies connectivity to the identity provider's discovery endpoint
- Delete a provider — removes it permanently; users who rely on it will need an alternative login method
Test before disabling internal login Always use the Test button to verify a provider is working before you disable internal login. A misconfigured or unreachable OIDC provider combined with disabled internal login will lock all users out of the workspace. See Internal Login for the lockout risk details.
"Can any user with a matching email log in via OIDC?" No. The user must already have a TestOrchestrator account. External login authenticates the user but does not create an account. If a user's email matches an existing account, they are logged in. If there is no matching account, the login is denied and they are shown an error.