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.