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

Field	Description
GENERAL
Display Name	Enter the name of the Service Provider
URL	Not used
Description	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.
Subject	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 CLIENT SP SETTINGS
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”
Scopes	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.
Use PKCE	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. This is meant to be used for exchange token acquired from an IDP outside of TBIO ecosystem and then exchanged for a TBIO access token. A source IDP has to be defined on TBIO for this (or a custom internal IDP would have to be used to do the validation with a Token Validation Workflow). A non-standard parameter `subject_token_issuer_hint` is supported in the request (it should match `Expected Issuer` field on an allowed IDP). That IDP is then used first to check the token validity.
Token Exchange Allowed IDP's	This defines the IDP's which are allowed for token exchange by this SP. If the client provides a valid access token or assertion from this IDP it will be accepted to exchange with the Token Exchange grant. The token is validated using the token introspection endpoint(s) of the allowed IDP(s). 👁️ Visible only when 'Token Exchange Grant enabled' is enabled.
Token Exchange Policy Workflow	This policy workflow can be used to define additional business logic to restrict token exchange logic, for example by querying an external system. The workflow can only keep the validation on valid value or to override from valid to invalid (i.e. not from valid to invalid). This is optional 👁️ Visible only when 'Token Exchange Grant enabled' is enabled. You can find more information on the workflow specifics on Token Exchange Policy Workflow
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. `*.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/TrustBuilder/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".