Skip to main content
Skip table of contents

OAuth Service Provider

Configure a Service Provider that uses the OAUTH or OpenID Connect Protocol for authentication and/or authorization. 

TrustBuilder will act as an (intermediary) Identity Provider for the Service Provider.

General Settings




Display Name

Enter the name of the Service Provider


Not used


Enter a description of the Service Provider

Authentication Scheme

Select the Authentication Scheme which defines the IDP(s) that can authenticate a user for this Service Provider, and how the user can authenticate.


Select the primary user attribute that is used to identify the user.

Manage Certificates

Add a Certificate or Import a Certificate.

See Managing Certificates


OAuth Policy

Select the OAuth Policy version 2.0.

OAuth 2.1 is an in-progress effort to consolidate and simplify the most commonly used features of OAuth 2.0.

Client ID

The input will be replaced by the Client ID which will be generated after clicking on Save & Close

Callback URLs

Add a callback URL to which the response will be sent. This is the endpoint to which the authorization server redirects the user after authentication, allowing the Service provider to receive tokens and complete the authentication process.

It is also known as a redirect URI.

Request URIs

Add a request URI which is endpoint provided by the Service Provider to receive authorization responses from the authorization server. (OAuth setting)

Propagate to attribute set

Check the box to propagate the scope attributes to attribute set.

TrustBuilder will use the attribute set that contains all of the attributes defined in the incoming OpenID scope and the least additional attributes.

See “How to propagate OIDC SP scope to match with SAML IdP attributes


Check the box(es) for the relevant scope.

Is Default? → If no scope is specified in the request, authorization for that scope will be requested by default. Multiple scopes can be marked as default.

Click to see available scopes and their descriptions

- administrator → Grants access to the administration part of the protected API

- attribute → Able to edit user attributes

- config:read → Allows reading configuration

- config:write → Allows editing configuration

- consents → Able to edit user consent

- openid → Defines if a request is an OpenID Connect request

- user → Able edit user

- userdata → Provides access to user data

- users:config:write → Allows editing user config

- users:read → Allows reading all users

- users:self → Allows reading/editing the authenticated user

- users:write → Allows editing all users

To add a new scope, go to Access Management > Scopes > +Add New Scope

Client Profile

Select the profile of the client application according to its ability to preserve the confidentiality of credentials (client identifier and client secret).

  • CONFIDENTIAL → Confidential client applications are running on a protected server. They have the ability to store secrets securely. They authenticate with the authorization server using both a client identifier and a client secret during the token exchange.
    Examples: web applications running on a server or mobile applications that can securely store their credentials.

  • PUBLIC → Public client applications are unable to keep their credentials confidential. They rely on authentication means such as using a combination of client identifier and PKCE (Proof Key for Code Exchange) during the authorization code flow. The PKCE is required to ensure that the authorization code cannot be intercepted.
    Examples: client applications implemented in environments where the client-side code can be easily inspected by end-users, such as JavaScript running in a browser or a mobile app.

Authorization Code Flow Enabled

Check the box to allow TrustBuilder to provide Authorization Code Grants

Authorization Code Grants should be used when there is an actual user that can be asked to log in and approve access for the client.


Check the box to use PKCE during the authorization code grant. The PKCE is required with public client applications to ensure that the authorization code cannot be intercepted.

Client Authentication Enabled

Allows TrustBuilder to provide Client Credentials Grants

Client Credentials Grant are used in a machine-to-machine context, when there is no user to complete the log in procedure or to provide authorization. In this case the client will simply authenticate itself.

Implicit flow enabled

Allows TrustBuilder to provide Implicit Grants.

Implicit grants are intended to be used for user-agent-based clients (e.g. single page web apps) that can’t keep a client secret because all of the application code and storage is easily accessible.

Token Exchange Grant enabled

Enables the use of a Token Exchange Grant Type.

This grant allows the client to exchange access tokens.

Token Exchange Allowed IDP's

Enabled when 'Token Exchange Grant enabled' is checked.

This defines all the IDP's which are trusted; if the client provides a valid access token or assertion from this IDP; it will be accepted to exchange with the Token Exchange grant.

Token Exchange Policy Workflow

Enabled when 'Token Exchange Grant enabled' is checked.
This policy workflow can be used to define additional business logic to restrict token exchange logic, for example by querying an external system.
More information on the Token Exchange Policy Workflow here

JWT Bearer Grant enabled

Enables the use of a JWT Bearer Grant Type.

This grant is used when the client wants to receive access tokens without transmitting sensitive information such as the client secret. This can also be used with trusted clients to gain access to user resources without user authorization.

Resource Owner Credential Grant enabled

Allows the usage of a Resource Owner Credential grant.

This grant is used for trusted first party clients both on the web and in native device applications.

Access Token Type

Defines the type of Bearer Token that is dispensed.  Supported types:

  • JWT: JSON Web Tokens. An access token that contains more context about a user (but is not a fully compliant ID Token).  

  • Opaque: Token that contains only a random string with no context about a user.  It acts only as an Access Token.

Access Token Time To Live

Defines the duration of how long the access token remains valid after dispensing it.

Refresh Token Enabled

Allows TrustBuilder to dispense Refresh Tokens.  A refresh token can be used to obtain a new Access Token, without asking the user to log in again.

Refresh Token Time To Live

Defines the duration of how long the refresh token remains valid after dispensing it.

ID Token Time To Live

Defines the duration of how long the ID Token remains valid after dispensing it.

Client Authentication Type

  • HTTP Basic Authentication Scheme: The client's authentication parameters are included in the http Authentication header

  • HTTP POST from body: The client's authentication parameters are included in the body of the http request, which are posted to the server

  • Client secret JWT: The client's authentication parameters are added as a JWT, that is signed using a shared secret.

  • Private Key JWT: The client's authentication parameters are added as a JWT, that is signed using the client's private key.

Cross Origin Request

Specify additional domains from which Cross-Origin Requests are accepted.  

Eg. * to allow access from all subdomains.


Additional Audience(s) that this ID Token is intended for.
The Client ID of the Service Provider is applied as an audience automatically.


Defines who issues the ID Tokens.

If left empty, the default https://domainname.ext/TrustBuilder/oidc is applied.


Instead of defining a trust certificate for the public keys of the client, it's possible to provide a JWKS url, where the current key can be fetched.
This key is used to validate the signature of the JWT bearer token (Client Authentication Type must be set to "Private Key JWT".

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.