Skip to main content
Feedback

Adding an OIDC identity provider

Add an OpenID Connect (OIDC) identity provider to your tenant.

Overview

Flow allows you to delegate flow user authentication to an OIDC identity provider (IdP). For example, you can use this to apply SSO (Single Sign On) authentication to your flows.

Any flow protected with OIDC identity provider authentication will act as a relaying party to accept an OIDC access token issued by the OIDC IdP. This means that users can only access the flow once they have successfully signed in through the identity provider.

  • When a flow protected by an OIDC identity provider is executed, the user is redirected to the identity provider to sign in.

  • Once the user has successfully signed in to the identity provider, they are redirected back to the flow with an OIDC access token.

  • The flow checks if the access token is valid. If it is valid the user is signed in to the flow.

Before you begin

Before adding an OIDC identity provider, you will need to have created an application in the IdP service, added at least one user, and copied a number of values to use during installation. You will need these values:

  • Client ID

  • Client Secret key

  • Well Known URL

  • Allowed Audience

Redirect URI: If required, the Redirect URI endpoint for an IdP service using a OIDC identity provider is:

Adding an OIDC identity provider

To add an OIDC identity provider to your tenant:

  1. On the Home tab, select Identity Providers from the main menu.

  2. The Identity Providers page is shown. Any existing identity providers that you have set up are displayed on the page. Click New Identity Provider.

  3. Name: Enter a name for the identity provider.

  4. Type: Select "OIDC" from the drop-down menu. Additional fields are now shown, allowing you to configure the identity provider.

  5. Client ID: The full Client ID obtained from your IdP application. The Client ID is the public identifier required for all OIDC protected flows.

  6. Client Secret: The full Client Secret key obtained from your IdP application. For security reasons, previously added keys are not shown.

  7. Well Known URL: The Well Known configuration URL for the IdP authorization server. This metadata declares the endpoint locations and capabilities of the authorization server.

    Example: "https://www.example.com/auth/realms/master/.well-known/openid-configuration"

  8. Allowed Audience: The audience (resource URI or server) for the access token. This must match the "aud" claim in the access token.

  9. Scope: Scope is a mechanism in OAuth 2.0 that limits an application's access to your account. It serves as a way for the Flow builder to define the permissions required by you when logging in using the identity provider (IDP) as part of the Flow. 

  10. Resource: Some IdPs such as Microsoft Azure AD allow you to specify where the resource/data belongs, to control access to this resource/data. This field can be left blank if this feature is not used or required by your IdP.

  11. PKCE: (Proof Key for Code Exchange) is an extension to the OAuth 2.0 protocol that enhances the security of authorization code flows, especially for public clients such as mobile and single-page applications. It helps mitigate the risk of authorization code interception attacks by requiring you to generate a unique code challenge and verifier during the authorization process.

    • None - This option indicates that no code challenge method is used. In this case, you do not send a code challenge with the authorization request. This approach is generally not recommended due to its lack of security.
    • S256 - This option specifies that the code challenge is derived using the SHA-256 hashing algorithm. By using S256, you enhance security by transforming the code verifier into a hashed code challenge, making it significantly more difficult for an attacker to guess the original code verifier. This is the recommended approach for implementing PKCE.
    • Plain - The Plain option indicates that the code challenge is the same as the code verifier, meaning no transformation is applied. While this method is simpler, it is less secure than the S256 option, as it does not hide the code verifier. 

  12. Allowed Grant Types - Currently supports two OAuth grant types: 

    • Authorization Code: This is the default grant type. In this case, when running the process, you will be redirected to log in with the identity provider. After successful login, you will be redirected back to the Flow. This method is commonly used for applications that require user authentication.
    • Client Credentials: In this grant type, the client provides the equivalent of a username and password when starting a Flow. This approach is mostly used when a backend system initiates a Flow directly via the Flow API without user interaction.

  13. Send Access Token to Connectors: Enable this setting to send the access token of the OIDC identity provider runtime user in a connector request. Requests made to a connector in a flow will then include an additional x-boomi-flow-user-access-token request header. This optional setting is disabled by default.

  14. Custom Attribute Mappings: These fields allow you to enter custom Attribute names, to customize the default attribute mappings. Enter a new attribute mapping name in the Claim Name field for each attribute as required.

  15. Comments: Enter comments or any useful information about this identity provider configuration.

  16. Click Save.

  17. You are returned to the Identity Providers page, with the new OIDC identity provider shown in the table.

Next steps

You can now apply authentication to flows in your tenant using the identity provider as required, either to control access to an entire flow, or by using swimlanes to control access to specific sections of a flow.

On this Page