Skip to main content
Skip table of contents

OAuth Service Provider

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

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

General Settings

Field

Description

Display Name

User defined name of the Service Provider

URL

Not used

Description

User defined description of the Service Provider

Authentication Scheme

Defines which IDP(s) that can authenticate a user for this Service Provider, and how the user can authenticate.

Type

"OAUTH Client"

Subject

Primary user attribute that is used to identify the user.

Client ID

This is a generated ID that uniquely identifies the Service Provider.  The client has to provide this ID with a secret before it can access the Service Provider.
Because IDHub acts as an Identity Provider, it generates the Client ID and Secret.
The Client ID and Secret is only generated when the Service Provider is initially created. Note that the secret is only showed once. If you didn't save it, it is lost.   
Then you can only generate a new Client ID and Secret (making the old ones obsolete immediately).

Callback URL's

After a user successfully (or unsuccessfully) authorizes an application, IDHub will redirect the user back to the URL provided in the Authentication Request.  

This Callback URL provided in the Authentication Request must be defined (whitelisted) as a Callback URL in IDHub.

The whitelisting is required, because information is sent to the callback URL. This is sensitive information that should be sent only to accepted domains.

Scopes

Defines which scopes IDHub can allow the user to authorize for this Service Provider.
To use the OpenIDConnect protocol instead of the OAuth Protocol, the "openid" scope MUST be allowed on this SP.

For more information on the field, see below

Client Profile

Defines if the client can securely store a secret.

When this is set to "Public" a PKCE (Proof Key for Code Exchange) is required.

Authorization Code Flow Enabled

Allows IDHub 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.

Client Authentication Enabled

Allows IDHub 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 IDHub 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 JWT Bearer Grant Type.

This grant allows the client to exchange access tokens.
In 9.4 and earlier versions: we only trust our own IDP's originating tokens.
From 9.5 onwards, it's possible to use tokens from other IDP's; which includes SAML Assertions.

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 [LINK] 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 IDHub 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. *.trustbuilder.com to allow access from all subdomains.

Audience

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

Issuer

Defines who issues the ID Tokens. If left empty, the default https://domainname.ext/idhub/oidc  is applied.

JWKS URL

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"

Certificates

Certificates are managed at Certificate Overview. 

It is still possible to import certificates without needing to leave the Service Provider screen.

Field

Description

Context

Defines what the certificate is used for.  There is only one option:

Key - Signing: Used to sign messages to the SP

Certificate Alias

The alias of the certificate to use for this context.

Used From

Defines from when this certificate may be used.  These periods may not overlap for "Key - Signing" certificates.

Used Until

Defines until when this certificate may be used.

Allowed Scopes

Field

Description

Name

Name of the scope, as defined in "scopes"
Click the checkbox before the name to enable or disable this scope.

Type

OAuth: Defines which API's (method & URL) the client is given authorization for.
OpenID: Contains a set of attributes that can the user can authorize the IDP to include in the ID Token.

To use the OpenIDConnect protocol instead of the OAuth Protocol, the "openid" scope MUST be allowed on this SP.

Description

User defined description of the Scope

Is Default

If no scopes are specified in the request, authorization for this scope is requested by default. Multiple scopes can be marked as default.

JavaScript errors detected

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

If this problem persists, please contact our support.