OAuth
Connecting a sign-in provider (OAuth)
Connect a workspace to your own sign-in provider using OAuth or OpenID Connect.
This screen lets a workspace use your own sign-in provider instead of the default.
A sign-in provider is the service your organisation already uses to check who someone is. Examples include Microsoft Entra, Google, Auth0, and Keycloak.
In plain terms, you connect Verentis to that service so people can sign in with the account they already use.
New to OAuth or OIDC?
OAuth is a way for one app to ask another service for access. OpenID Connect, often shortened to OIDC, adds sign-in on top of OAuth. Before you start, read OAuth and OIDC explained for plain-language definitions of authority or issuer URL, client ID, client secret, scopes, and redirect URI.
How the pieces fit together
Verentis is the application that signs people in through your provider.
Before you fill in this screen, you usually need to create or register an application inside your identity provider. This is often called an OAuth client, OIDC client, or app registration.
Your provider then gives you values to copy into Verentis.
Fields on this screen
ProviderdropdownThe kind of sign-in provider you want to connect. The choices are Generic OIDC, Microsoft Entra, Google, Auth0, Keycloak, and Custom.
Authority / Issuer URLURLThe base web address of your identity provider. The example shown in the UI is https://login.example.com. This is where Verentis goes to start the sign-in.
Client IDtextThe public identifier your identity provider gives to the application you registered there. It tells the provider which application is asking for sign-in.
Client secretsecretA password-like value from your identity provider. If a secret is already set, this screen shows it as dots. Leave it blank to keep the current secret.
ScopestextThe information Verentis may request during sign-in. The default is openid profile email, which asks for sign-in, basic profile information, and email address.
Enabledon/off toggleTurns this sign-in provider connection on or off for the workspace.
Keep the client secret safe
A client secret works like a password for this sign-in connection. Only paste it into the official Verentis settings screen. Do not send it in chat, email, tickets, or screenshots.
Connect a sign-in provider
Decide which provider to use
Choose the service your organisation uses for sign-in. If you are not sure, ask the person who manages your organisation's accounts or identity system.
Create an application in your provider
In your identity provider, create or register a new application. This is often called an OAuth client, OIDC client, or app registration.
The provider should give you a Client ID and usually a Client secret.
Add the Verentis redirect URL in your provider
A redirect URL, also called a callback URL, is where the provider returns users after sign-in.
In your provider, add Verentis's callback address as a redirect URL. Every workspace uses the same address — the Verentis API for this environment:
https://api.uat.verentis.dev/connect/callbackCopy the provider details into Verentis
In the Verentis OAuth settings screen, choose the Provider. Then paste the Authority / Issuer URL, Client ID, and Client secret from your provider.
Set the scopes
Use openid profile email unless your organisation tells you to use different scopes. A scope is a named piece of information or access that Verentis may request.
Enable the connection
Turn Enabled on when you are ready for the workspace to use this provider.
Save and test signing in
Click Save. Then test sign-in with a user account from your provider.
Provider tips
These tips are general. Your provider may use slightly different words.
For Microsoft 365 or Office 365 work and school accounts. Follow the step-by-step guide to register an app in Microsoft Entra ID and copy the values into Verentis.
Create an OAuth client for a web application. Copy the client ID and client secret, and use Google's issuer details for OIDC sign-in.
Create an application in your Auth0 tenant. Use your tenant domain as the authority, then copy the client ID and client secret.
Create a client in the right realm. Use the realm issuer URL as the authority, then copy the client ID and secret.
Use this when your provider supports OpenID Connect but is not listed by name. Look for its issuer URL, client ID, and client secret.
Use this when your organisation has a custom sign-in setup. Ask your identity administrator for the exact values to enter.