Custom OIDC applications

STA includes application-specific templates for integrating applications that use the OIDC protocol. If your OIDC application isn't included in the list of pre-defined templates, use the generic template to configure your custom OIDC applications.

To be suited for OIDC integration in STA, the applications should be web-based. At a minimum, the applications must offer web-based user login initiation, and redirection or response endpoints.

When a user accesses an OIDC application through STA, they are in a STA single sign-on (SSO) session for applications. This SSO session is bound by the regular STA SSO timeout rules.

Configure a custom OIDC application

After you add an application, you configure it so that your users can access it through STA. First you go to the relying party (RP) and configure the OIDC application to use STA as the OIDC provider (OP). The RP is the application that connects to STA for the purpose of authentication and authorization. Then, you configure STA to authenticate the application. Finally, you assign the application to users and groups.

Select a template

1. On the STA Access Management console, select the Applications tab.

   

2. Click Add Application. The Add Application window lists all of the supported applications.

   

3. Select the Generic Template.

4. Enter a Display Name for your application.

   This name is displayed in the list of applications.

   

5. Under Integration Protocol, select OIDC.

6. Select the Access Type:

   • Confidential: This access type is for applications that require a client secret to exchange an authorization code for an access token. STA assigns a client ID and a client secret to an OIDC application when it is added in STA. The application can use these details to identify itself for retrieving access tokens.

     Select the confidential access type for applications that are capable of maintaining the confidentiality of their credentials (for example, a client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.

   • Public: This access type is for applications that are not required to provide a client secret.

     Select the public access type for applications that are incapable of maintaining the confidentiality of their credentials (for example, for clients executing on the device used by the user, such as an installed native application or a web browser-based application).

   Note

   OIDC applications using Public access must meet the following security practices: 

   • HTTPS is strictly enforced on your application for data encryption, thus preventing interception of sensitive data.

   • Choose redirect URLs that are not easy to find, and not too general. When configuring the VALID REDIRECT URL, if you need to include a wildcard character, make the URL path as granular as possible.

   HTML5/JavaScript applications must always use Public access, because there is no way to securely transmit the client secret to them.

7. Click Add.

   STA adds the application in the inactive state.

   Note

   If this is the first generic application that you have added, setup instructions are displayed. The instructions explain that the first step is to configure the SAML service provider to use STA as the OP, and the next step is to configure the application in STA.

   Click the next icon, and then click Begin Setup.

   

8. Go to Configure the OIDC application.

Configure the OIDC application

The Configure tab shows the Step 01: Generic Template Setup settings. Use this information to configure the OIDC application.

1. Use the copy icon to quickly copy the required information that you need to use for the OIDC application.

   • CLIENT ID

   • CLIENT SECRET (if you selected the Confidential Access Type)

   • AUTHORIZATION END POINT URL

   • TOKEN END-POINT URL

   • USER INFO END-POINT URL

   • LOGOUT END-POINT URL

   • WELL KNOWN CONFIGURATION URL

   The CLIENT SECRET is sensitive information, and you must protect it with care.

2. Click Next Step.

   The Configure tab displays Step 02: STA Setup.

   

3. Select the ALLOWED FLOW TYPE.

   The flow type determines how an OIDC application authenticates users, and receives authorization codes and access tokens.

   Access type	Allowed flow type	Description
   Public (native and single-page applications)	Authorization code flow	Offers good security but is susceptible to authorization code interception attacks. The possible attacks are described in the PKCE document.
   	Authorization code + PKCE	Offers the best security. It provides mitigation for all known interception attacks. It is recommended to use S256 mode instead of plain.
   	Implicit flow	Not recommended because token access token leakage can occur. Refer to Implicit Grant in the OIDC best practices document.
   	Authorization code flow and implicit flow	Offers similar security as authorization code but can also be used in implicit mode. Should be avoided.
   Confidential (server-side applications where the source code is not publicly exposed, like cloud services)	Authorization code flow	Offers good security. Authorization code interception attacks are prevented using a shared secret that needs to be stored securely by the client.
   	Implicit flow	Not recommended because access token leakage can occur. Refer to Implicit Grant in the OIDC best practices document. Not suitable for applications that cannot securely store a secret.
   	Authorization code flow and implicit flow	Offers similar security as authorization code but can also be used in implicit mode. Provides some performance enhancements over authorization code flow because tokens are immediately available.

   Note

   If you are using the implicit flow, be aware of the security trade-offs. Ensure that there is no way the access token can be stolen, by employing general good security practices: 

   Use short-lived web sessions on single page apps to defend against session hijacking. Ideally, set web sessions to a value less than or equal to the access token lifetime. STA expires an issued token after 5 minutes.

   Unless the application has a secure method of storing the secret, use the public access type, not the confidential access type.

   If the OIDC application uses JavaScript libraries, the application should regularly check whether the session with STA is active.

4. Gather configuration information from the OIDC application and enter it here:

   • SERVICE LOGIN URL: The sign-on URL of an OIDC application. STA uses this URL to invoke the application when access to it is initiated from the User Portal. As such, if you plan to use the User Portal, it is important that you enter a proper URL in this field.

   • VALID REDIRECT URL: The URL where the user is directed, after successful authorization. An asterisk (*) is supported as a wildcard character at the end of this field to accept redirection to any URL that fits the same base pattern. For example, you can enter https://example.com/*.

     Multiple redirect URLs are supported for a single OIDC application. STA supports POST binding and redirect binding authentication flows, depending on the service provider’s compatibility.

     The OIDC application specifies the redirect URLs to use, and STA is responsible only for validating the application URL.

     Choose redirect URLs that are not easy to find and not too general. When configuring the VALID REDIRECT URL field, if you need to include a wild card character, make the URL path as granular as possible.

   • USERINFO SIGNATURE ALGORITHM: The JSON Web Algorithm (JWA) used for signed UserInfo-endpoint responses.

     Possible values: RSA-SHA256 or unsigned

   • REQUEST SIGNATURE ALGORITHM: The JWA that the application needs to use when sending the OIDC request.

     Possible values: RSA-SHA256, any, or none

     The value any allows for any or no signature algorithm to be used. In other words, any includes the none value.

   • User Identity Claims: Allow STA to convey information identifying the user to the application. This ensures that the application knows who has authenticated and is authorized the rightful access.

     To add a claim, select Add Claim and configure a value mapping. The system supports the following scenarios:

     • Create claims with a user attribute mapping.

     • Create single-value claims with custom text mapping.

     • Create multi-value claims, such as AMR claims, with custom text mapping that return an array of custom values.

     • Create claims with group mapping to return the user groups (including nested groups) in an array of groupnames.

     To remove a claim, select Delete next to the claim name.

5. Click Save Configuration to save the changes or click Discard changes.

   The application is now active and available to be assigned to groups and users.

   You can replace the system-generated application icon with a custom icon.

After adding the application, go to Assign the application to users and groups.

Assign the application to users and groups

You assign an application to users to grant those users with the authorization to access the application. If an application is not assigned to a user, then STA blocks access to the application.

You can assign an application to all users or to specific user groups. An individual user can access the applications that are assigned to all users, or to groups that they are a member of.

If a user is authorized to access an application, the STA authentication flow that is dictated by the applicable policy, scenario, and state of the Single Sign-On (SSO) session applies.

Ensure that users who need access to web applications can use single sign-on (SSO).

1. On the STA Access Management console, select the Applications tab.

2. In the Applications list, select the application.

3. In the application details panel, click the Assign tab.

4. Under Assign to Users, select one of the options:

   • No users (Default)

   • All users

   • Users from any of these user groups: Enter the group names in the text box.

5. Click Save Configuration.

   An Application Assignment entry is added to the audit log each time an application assignment is saved.