Integrate a generic OIDC and OAuth SPA application

You can configure access to custom OpenID Connect (OIDC) applications by integrating a generic OIDC Single-Page application (SPA) on Identity as a Service. An SPA application is a client application that cannot communicate securely with Identity as a Service using a client secret in order to obtain various tokens. Tokens are returned directly to the SPA.

Before you begin, complete the following:

●        Identify the attributes that Identity as a Service must contain to establish a connection between Identity as a Service and the OIDC application.

●       Configure the account settings of your application to accept authentication attempts from your Identity as a Service account. 

Add generic OIDC SPA application

1.      Log in to an Identity as a Service account with a role assigned that allows you to configure applications on Identity as a Service.

2.      Click > Security > Applications. The Applications List page appears.

3.      Click Add. The Select an Application Template page appears.

4.      Scroll to OpenID Connect and OAuth Cloud Integrations and click Generic SPA Application. The Add Generic SPA Application page appears.

5.      Change the Application Name and Application Description to reflect the custom application you are configuring for SSO through Identity as a Service.

6.      Optional. Add a custom application logo, as follows:

a.      Click next to Application Logo. The Upload Logo dialog box appears.

b.      Click to select an image file to upload.

c.      Browse to select your file and click Open. The Upload Logo dialog box displays your selected image.

d.      If required, resize your image.

e.      Click OK.

7.      Select the Authentication Flow that appears to users during login. You must select at least one. For more information on Passkey log in, see Manage Passkey/FIDO2 authenticators.

8.      Click Next. The Settings page appears.

9.      Complete the following in the General Settings:

a.      Select Enable Organizations and Domain-Based Identity Providers to allow organization information to be returned in OIDC claim values when users log in. When enabled, if users are associated with more than one organization and an organization has not been requested, users can select their organizations after they authenticate to their application.

Note: When organizations are enabled, the corresponding OIDC claims must also be configured. See step 12.

b.      The Client ID is generated when you create the application on Identity as a Service. You cannot modify the Client ID.

c.      From the drop-down list, select the Subject ID Attribute that corresponds with the user attribute.

The Subject ID Attribute can be the user name or the Federation ID listed in the application account details on the OIDC application. This attribute links Identity as a Service to the client OIDC application account.

d.      Select the OIDC Signing Certificate used to connect to the Service Provider.

e.      Optional: Deselect Show Login Redirect URL in My Profile to hide the application from a user's profile.

f.        Optional: Enter the Initiate Login URI to allow users to access the application from Identity as a Service.

The Login URI is the location from which authentication to the OIDC application through Identity as a Service can be initiated.

g.      Click Add to add a Login Redirect URI.

The  URI is the location a user is redirected to after being provided or denied access to the application. The value can be a URL, and you can add more than one value.

Note: The login redirect URI hostname is added as a valid CORS origin for OIDC processing.

h.      Click Add to add a Logout Redirect URI.

The URI is the location a user is redirected to after being logged out from a client application. The value can be a URL, and you can add more than one value. In order to be redirected back to the client application, the logout call by the client application must include the following parameters:

–  The client_id value (or alternatively id_token_hint value that identifies the client id in the aud claim of the supplied id_token).

–  The post_logout_redirect_uri value (or redirect_uri value) that is configured as one of the Logout Redirect URIs.

i.        Enter the Default Resource/Audience Request Value to include this value for the resource or audience parameter for every authorization request.

j.        Optional: Select Respond Immediately for Unsuccessful Responses to return to the application immediately after a login failure, rather than allow user to try again with a different userID.

k.      Deselect Enable Go Back Button if you do not want users to be able to go back to the application login page to log in.

10.  In the Authentication Settings, do the following:

a.      Optional. Select Require Consent to require that users respond to a consent prompt during authentication.

b.      Optional. Enter a Consent Message to include a message to users when consent is requested.

c.      Optional. Enter the Max Authentication Age (seconds) to set the maximum amount of time that can elapse before a user is required to re-authenticate during a new login attempt. Leave this field blank to disable this feature.

d.      Select the Grant Types Supported that your application uses to access OIDC authentication through Identity as a Service.

The grant type tells Identity as a Service what flow to use to return authentication/authorization responses and grant request responses. You can select more than one grant type.

Grant Types Supported options include:

–  Authorization CodeID Tokens, Access Tokens, and Refresh Tokens obtained by the client application from the Identity as a Service OpenID Provider are passed by reference. The client application communicates directly with Identity as a Service to obtain these  tokens. The supported response type is  Code.

–  Implicit ID Tokens and Access Tokens obtained by the client application from the Identity as a Service OpenID Provider are passed by value. The tokens are sent back directly to the application as part of the response to the authorization request. Supported request types are id_token and id_token token.

–  JWT IDaaSAn authentication API-based grant type to obtain ID, Access, and Refresh Tokens. API calls are used to acquire these tokens.

–  None (OIDC No Flow)This is typically used for OIDC test purposes. No OIDC tokens are sent back as part of the authorization request response.

–  Refresh TokenA refresh token grant request is used to obtain a new access token and refresh token for a valid refresh token.

e.      The Authorization Code PKCE Code Challenge must be used by clients to authenticate to the Authorization Server when an Authorization Code grant type is used. This value is set to S256 by default.

f.        Select Include Authentication Time to include the authentication time with all tokens.

g.      From the ID Token Signing Algorithm drop-down list, select the signing algorithm that is used to sign the ID Tokens during authentication.

h.      Set the ID Token Timeout to the time (in minutes) that the ID token is valid before it expires.

i.        From the User Info Signing Algorithm drop-down list, select the signing algorithm used to sign the user info data during authentication.

j.        Set the User Info Access Token Timeout to the time (in minutes) that the access token is valid before it expires.

11.   Select the Supported Scopes.

A scope is a group of claims required for a connection between Identity as a Service and the OIDC application. Scopes are requested by the client during an authorization request. You can select more than one scope.

●       Your unique identifier (selected by default). If disabled, the OIDC application is strictly using an access token that can be used to access a resource server API on behalf of a user.

●       Address

●       Email address

●       Telephone number

●       Profile information

 Note: Click the arrow next to each scope to see the list of Implied Claims included in the scope. The list of Implied Claims is defined by OpenID Connect and cannot be modified.

Every Implied Claim included in the scopes you select under Supported Scopes should have an associated Identity as a Service user attribute so that the attribute is returned as part of the OIDC tokens sent back to the client. For example, if you select Address as a Supported Scope, then you must define an Identity as a Service user attribute for each Implied Claim associated with Address. See Add a user attribute.

12.  If required, add Supported Claims to map OIDC claims to Identity as a Service user attributes and related user information.

The supported claims define the claims that the client requests during an authorization request or claims that are returned automatically by IDaaS. A claim value can be derived based on a  user attribute, for example, <FirstName>. A claim value can also be derived based on a user related attribute, for example, [Groups]. The required claims depend on the OIDC application that you are configuring Identity as a Service.

The default claims are

●       email

●       family_name

●       given_name

●       name

●       phone_number

You can group claims, for example, the default claim, name, includes the user attribute First Name, a text-based value of a space and the user attribute value of Last Name so that the claim returned to the client is First Name <space> Last Name, for example Alice Gray.

13.  To add a claim:

a.      Ensure that you have already created the required User Attributes in Identity as a Service (see Create and manage user attributes).

a.      Click . The Add Claim dialog box appears.

b.      In the Claim Name field, do one of the following:

i)        Select the Claim Name from the drop-down list.

-OR-

ii)      Type a Claim Name to create a new custom claim.

c.      In the Enter the Claim value expected by the Service Provider field, enter the following, as required:

–  User Attribute Value—An Identity as a Service user attribute (see Create and manage user attributes).

–  Text-Based Value—A-text based value. For example, to add a space between two claims or add text information.

–  Related Value—Include user group or authenticator attributes. See Configure OIDC claim to include user authenticators, groups or organizations.

Example:  some text <first Name> <Last Name> [Groups]

d.      Select Always Return with User Info to always return the user information with the claim.

e.      Select Always Return with ID Token to always return the ID Token with the claim.

f.        Click Add.

Note: If required, click next to the claim and make the required changes. Click to delete a claim.

14.  Click Submit.

15.  Protect the application with a resource rule.