Adding OpenID Connect Applications to Omnissa Access

You can add applications that use the OpenID Connect (OIDC) authentication protocol to the Omnissa Access catalog and manage them like any other applications in the catalog. You can apply an access policy to each application to specify how users are authenticated based on criteria such as network range and device type. After you add the application, you assign it to users and groups.

To add an OpenID Connect application, you specify the application's target URL, redirect URL, client ID, client type, and client secret (optional, based on the client type).

When you add an OpenID Connect application to the catalog, an OAuth 2.0 client is automatically created in Omnissa Access for the application. The client is created with the configuration information you specify while adding the application, which includes the target URL, redirect URL, client ID, client type, and client secret (optional, based on the client type).

The client type determines whether the OAuth 2.0 client is a Public or Confidential client. For more information about the types of clients, see Add OAuth 2.0 User Access Clients to Omnissa Access. Proof Key for Code Exchange (PKCE), an extension of the OAuth 2.0 protocol that improves the security of the Authorization Code flow, is always enforced for a Public client and is optional with a Confidential client. Note that Omnissa Access supports only the S256 code challenge method for PKCE.

All other parameters use default values. These include:

• Grant type: authorization_code, refresh_token

• Scope: admin, openid, user

• Display user grant: false

• Access token time-to-live (TTL): 3 hours

• Refresh token time-to-live (TTL): Enabled and set to 90 days

• Refresh token idle time-to-live (TTL): 4 days

You can view the OAuth 2.0 client for the application on the Settings > OAuth 2.0 Management page. In the Clients tab, find and click the client ID to view the configuration information.

Caution: Do not delete the OAuth 2.0 client associated with the application or the application will no longer be available to users.

When you delete the application from the catalog, the OAuth 2.0 client is also deleted.

Authentication Flow when Application is Accessed from Omnissa

When a user clicks the application in Omnissa, the authentication flow is as follows:

1. The user clicks the application in Omnissa.
2. Omnissa Access redirects the user to the target URL.
3. The application redirects the user to Omnissa Access with an authorization request.
4. Omnissa Access authenticates the user based on the authentication policy that you specified for the application.
5. Omnissa Access checks whether the user is entitled to the application.
6. Omnissa Access sends the authorization code to the redirect URL.
7. Using the authorization code, the application requests the access token.
8. Omnissa Access sends the ID token, access token, and refresh token to the application.

Authentication Flow when Application is Accessed Directly from Service Provider

When a user accesses the application directly from the service provider, the authentication flow is as follows:

1. The user clicks the application.
2. The user is redirected to Omnissa Access for authentication.
3. Omnissa Access authenticates the user based on the authentication policy that you specified for the application.
4. Omnissa Access checks whether the user is entitled to the application.
5. Omnissa Access sends an ID token to the service provider.

Endpoints Available for OIDC Applications

For the endpoints available for OIDC applications, see the OIDC section in the Omnissa Access API Reference. You can also retrieve the OpenID Provider configuration from the well‑known URI /acs/.well-known/openid-configuration, which publishes metadata describing the available OIDC and OAuth 2.0 endpoints.