Skip to main content

August 11, 2026

Add OAuth 2.0 User Access Clients to Omnissa Access

To enable a single application to register with Omnissa Access services to allow user access the application, create a user access token client.

Omnissa Access uses OAuth 2.0 to enable applications to register with Omnissa Access and create a secure delegated access to applications that are enabled in the Hub catalog. The OAuth client is authorized through an access token.

You can create and update two types of OAuth 2 clients: Public client and Confidential client.

Public clients like native and single-page apps run in environments that cannot maintain the confidentiality of a client secret. When the client type is Public, you can select the grant type to be either the Password or Authorization Code grant.

When you select Authorization Code for the client type Public, PKCE (Proof Key of Code Exchange) support is enforced and cannot be removed. The PKCE extension protocol helps prevent authorization code interception attacks. The scope options for public clients are restricted to user-based scopes only. Scope options for public clients cannot be configured with privileged scopes like Admin.

Confidential clients are apps that can securely authenticate with the authorization server. Their client ID and secret are safe. If Authorization Code grant type is chosen for the client type Confidential, the PKCE option is enabled by default. You can remove the PKCE option for confidential clients.

For OAuth 2.0 clients that use the grant type Password Grant, you can choose to validate passwords against a third-party OpenID Connect identity provider by selecting the authentication method associated with the identity provider in the OAuth 2.0 Management > Password Validation tab. See Enabling Password Validation with a Third-Party Identity Provider for OAuth 2.0 Clients Using Password Grant Flow for information.

Procedure

  1. In the Omnissa Access console Settings > OAuth 2.0 Management page, click ADD CLIENT.

  2. In the Add Client page, configure the following.

    Label Description
    Access Type Options are to create either a User Access Token or a Service Client Token. Select User Access Token.
    Client Type Public or Confidential
    Select Public when apps run in environments that cannot maintain the confidentiality of a client secret.
    Select Confidential when apps can securely authenticate with the authorization server. When the client type is Confidential, the client page is refreshed and the Client ID and the hidden Shared Secret are displayed.
    Client ID When you select Confidential, enter a unique client identifier for the application. The client ID is used to authenticate to Omnissa Access. The client id must not match any client id in your tenant. The following characters can be used, alphanumeric (A-Z, a-z, 0-9) period (.), underscore (_), hyphen (-) and at sign (@).The client identifier can be no more than 256 characters.
    Grant Type Select one or more of the following grant types.
    • Client Credentials Grant displays when they client type is Confidential.
    • Password Grant. You can select Password Grant for either Public or Confidential client type.
    • Authorization Code Grant. You can select Authorization Code Grant for either the Public or Confidential client type. When you select Authorization Code Grant, the Redirect URI setting is displayed under Grant Type. When Authorization Code is selected, the PKCE support setting is enabled by default.
    • Refresh Token Grant is enabled by default when the Issue refresh token setting is enabled.
    Redirect URI Enter the registered redirect URI for Authorization Code Grant. Enter as https://redirecturi.com.
    You can use a comma separated list to add more than one redirect URL.
    User Grant Enable Prompt Users for scope acceptance.
    Scope The scope defines which part of the user's account the token can access. The scopes you can select from include Email, Profile, User, NAPPS, OpenID, Group, and Admin. Select one or more identity scopes that you want as part of the OAuth 2.0 authorization request.
    When you select Admin, the Admin Roles setting is displayed.
    PKCE Support When the grant type is Authorization Code Grant, the PKCE support check box is enabled. If the client type is Public, you cannot deactivate PKCE support. If the client type is Confidential, you can select to deactivate PKCE support.
    Admin Roles For Confidential client types, you can select the Admin setting in Scope and in the drop-down menu, select the admin roles granted to the admin.
    Issue refresh token To allow for the return of a refresh token, leave this option enabled.
    Refresh token TTL Set the Refresh Token time to live value. New access tokens can be requested until the refresh token expires. See Managing OAuth 2.0 Clients in Omnissa Access.
    Access token TTLThe access token expires in the number of seconds set in Access Token TTL. If Issue Refresh Token is enabled, when the access token expires, the application uses the refresh token to request a new access token.
    Idle Token TTLConfigure how long a refresh token can be idle before it cannot be used again.
    Token TypeFor Omnissa Access, the token type is Bearer.
    User GrantPrompt users for scope acceptance is enabled. Users are shown a message that lists the scopes that are being sent.
  3. Click SAVE.

    When the client type is Confidential, the client page is refreshed and the Client ID and the hidden Shared Secret are displayed.

  4. Copy and save the client ID and generated shared secret. You add this information when you configure the application.

    The client secret must be kept confidential. If a deployed app cannot keep the secret, configure them with the client type Public.

    Note: The shared secret is not saved. If you loose the secret code, you must generate a new secret, and update the app that uses the same shared secret with the regenerated secret.

    To regenerate a secret, click the client ID that requires a new secret from the OAuth 2.0 Management page and click REGENERATE SECRET.

What to do next

In the resource application, configure the client ID and the generated shared secret. See the application documentation.

Was this page helpful?

Provide feedback for this topic

Was this topic helpful?

Please do not include any personal or confidential information.

Generating link…