Omnissa Cloud Services Console uses OAuth 2.0 so that you can give your applications secure delegated access to the protected resources in your Organization. Omnissa Cloud Services supports web application access where users of your app authorize access, and server-to-server interactions where access tokens are issued directly to your app.
What is OAuth 2.0
OAuth 2.0 is an authorization protocol that lets you grant your apps secure access to your resources. Your client is authorized through an access token. The access token has a scope which defines which resources the token can access. For information about OAuth 2.0, see the OAuth specification at https://tools.ietf.org/html/rfc6749#page-8 or look at this blog post called OAuth 2.0 Simplified at https://aaronparecki.com/oauth-2-simplified/.
How does OAuth 2.0 work with Cloud Services
Omnissa Cloud Services covers several use cases for app authorization leveraging different grant types, such as client credentials, authorization code, and public client with authorization code. Depending on your goals, you choose to create one of three types of OAuth apps that correspond to each grant type – respectively Server to server app, Web app, and Native/Mobile app.
Let's say you are an Organization Owner with access to Omnissa Cloud on AWS. You've developed an app that helps you trade in stocks. You call the app Trading 1.0. You want to run the app on virtual machines that are managed by a vCenter Server, but first, you must authorize your app with the Omnissa Cloud on AWS APIs.
- You create an OAuth 2.0 app in the Cloud Services Console.
- Think of this as a way of registering your Trading 1.0 app.
- You initiate the app's creation by clicking Create App in the Identity and Access Management > OAuth Apps > Owned Apps menu and go through a series of steps.
- At the end of the process, we issue client credentials in the form of an app ID and app secret that are used to identify your client with the APIs.
- You paste these credentials into your script.
- Your app has been created in the Organization, but not yet given access to it.
- You grant access by adding it to the Organization.
- This allows the app to access the services and resources in the Organization that you defined when creating the app.
- This step is required only for apps that are of the Server to server app type, it is not applicable for Web and Native/Mobile apps.
- When you run your Trading 1.0 client app, it requests an access token from the authorization server.
- When authorized, the authorization server sends an access token to the APIs and your client is granted access.
Who can create and manage OAuth apps
As an Organization Owner user, or an Organization Member user with the Developer role, you create and manage your OAuth apps.
You can also manage the OAuth apps created or added by other Organization Owners in your Organization.
Can I regenerate an app secret
Yes, as Organization Owner, you can regenerate the app secret of an OAuth app in your Organization. This is useful if the Organization Owner who created the OAuth app is no longer with your business enterprise and you want to continue running the app.
Can I use an API Token authentication instead of an OAuth app
Yes, if an API mandates that a user is the authenticated entity in the authorization process, you must use an API token instead. To see when to use OAuth apps versus API tokens, see What Is the Difference Between OAuth Apps and API Tokens.
How to manage OAuth 2.0 apps
As an Organization Owner user, you create, view and modify the details of the OAuth 2.0 apps in your Organization.
You can also:
- manage the OAuth apps created or added by other Organization Owner users in your Organization;
- grant access to apps created in any Organization in which you hold the Organization Owner role.
| To... | Do this... |
|---|---|
| View the OAuth apps that have access to your Organization. | Click Identity & Access Management > OAuth Apps. In the Role Assigned Apps section of the page you can view the apps created in other Organizations with access to your Organization. |
| Add an OAuth app created in another Organization. | 1. Click Identity & Access Management > OAuth Apps > Role Assigned Apps. 2. Click Add App. 3. To identify the OAuth app you want to add, select Enter App ID or Search by Organization. 4. Click Continue. 5. If you selected to identify the OAuth app using its ID, you are prompted to enter the OAuth app ID. 6. If you selected to identify the OAuth App through the Organization in which it was created, you are prompted to first select the Organization name from the drop-down menu, and then select the OAuth App from the list of OAuth Apps available in that Organization. The Organization drop-down menu shows only the Organizations where you have Organization Owner access. 7. Review the App Details and click Add. |
| Remove an OAuth app created in another Organization that has access to your Organization. | 1. Click Identity & Access Management > OAuth Apps > Role Assigned Apps. 2. From the list of OAuth apps that displays, select the app you want to prevent from accessing your Organization. 3. Click Remove. |
| To view the apps created in your Organization. | Click Identity & Access Management > OAuth Apps > Owned Apps. Here you can view all the apps that were created in your Organization. - Modify an app. If you change the scoping of an app, your changes are not included to instances of the app located in other Organizations. To update the scoping, Organization Owner users must remove the app from their Organization, and add it again, or edit the app to reflect the updated scoping. - Remove an app from the Organization. - Add an app that has been created in the Organization but not yet given access to the Organization. - Create an app. |
| To create a new OAuth app in your Organization. | 1. Go to Identity & Access Management > OAuth Apps > Owned Apps and click Create App. 2. Select the type of app you want to add. |
| To manage the OAuth apps created in your Organization. | Click Identity & Access Management > OAuth Apps > Owned Apps and select the app you want to manage: - To modify the OAuth app, click Edit. Note:If you change the scoping of an app, your changes are not included to instances of the app located in other Organizations. To update the scoping, Organization Owner users must remove the app from their Organization, and add it again, or edit the app to reflect the updated scoping. - To remove an app, click Delete. Note:This action cannot be reverted. Any application using these client credentials will no longer be able to access protected resources and the credentials will be invalidated. - You add a server to server app that has been created in the Organization but not yet given access to the Organization by selecting the app and clicking Assign Roles. If needed, you modify the available Organization and service roles allowed by the scope of the app, then click Add. If you want to modify the scope of the app first, click Edit and make the required changes to the Organization and service roles. When ready, click Add to This Org. Note: Web/Mobile apps cannot be added to Organizations. |
How to use OAuth 2.0 for server to server apps
If your application requires direct access to another server, without user authorization, you create a Server to server app. This option is based on the OAuth 2.0 client credentials grant type. During this flow, your app uses its OAuth credentials to retrieve an access token.
Scoping has special importance in server to server apps. Scopes provide a way to implement control over what areas in an Organization your client can access - specifically which role in an Organization, and what services and the level of permissions. As an Organization Owner user, you can add your server to server app to any of your Organizations. So while you can specify a wide range of access for your app over many cloud services, access is eventually determined by the services contained in an Organization. You receive notification when you add an OAuth app to an Organization that does not include the services included in the scope of the app.
Prerequisites
You have the required permissions for adding and managing OAuth apps in this Organization.
Procedure
- Log in to Cloud Services Console.
- Click Organization > OAuth Apps, select the Owned Apps, and then click Create New OAuth App.
- Select Server to server app.
- Register your client by entering a name and description.
- Set the Access Token TTL value for the new OAuth app.
The Access Token time to live (TTL) defines the time period the token is valid.- The default Access Token TTL time is 30 minutes.
- The maximum Access Token TTL time you can set is 300 minutes (five hours).
- The minimum Access Token TTL time you can set is 1 minute.
- Define scopes.
Scopes provide a way to implement control over what areas in an Organization your client can access - specifically which role in an Organization, and what services and the level of permissions. - Click Create to generate the client credentials.
- On the OAuth app created pop-up window, copy the credentials or download a JSON file, and click Continue.
You are responsible for storing your credentials in a safe place. - (Optional) Add the app to the active Organization.
You can skip this step and add the app to this Organization, and other Organizations later.
How to use OAuth 2.0 for web apps
If your application is a regular web app that runs on a server, and requires user authorization, you create a Web app. This option is based on the OAuth 2.0 authorization code grant type. During this flow, users authorize your application before it accesses any resources, and your app retrieves an access token and optionally a refresh token.
Prerequisites
You have the required permissions for adding and managing OAuth apps in this Organization.
Procedure
- Log in to Cloud Services Console.
- Click Organization > OAuth Apps, select the Owned Apps tab, and then click Create New OAuth App.
- Select Web/Mobile app and click Continue.
- Register your app by entering the app details:
- Type a name and description for the new OAuth app.
- Enter at least one redirect URI.
After a user authorizes your client, the authorization server redirects the user back to your client to the URI you specified with an access token. It is best practice to add more than one URI. Use the formathttp://acme.com. - Specify a time span for your access token.
- The default Access Token time to live (TTL) setting is 30 minutes.
- The maximum value you can set is 300 minutes (five hours).
- The minimum value you can set is 1 minute.
- If you want your access token to authorize requests continuously, select the Issue a refresh token and set Refresh Token TTL value.
- The default Refresh Token TTL is 30 minutes.
- The maximum value you can set is 300 minutes (five hours).
- The minimum value you can set is 1 minute.
- Define scopes.
Scopes provide a way to implement control over what areas in your Organization your client can access - specifically which of your services and the level of permission. - Select the Open ID check box to get information about the users that authorize your app.
- Click Create to generate the client credentials.
- Copy the credentials or download a JSON file that contains your credentials. You are responsible for storing your credentials in a safe place.
- Click Continue.
- Paste the credentials into your script.
How to use OAuth 2.0 for native and mobile apps
Public clients such as native and mobile apps cannot maintain the confidentiality of a client secret. When using OAuth 2.0 for native and mobile apps, we generate an app ID, and use the Public Key for Code Exchange (PKCE) to provide additional verification.
PKCE is a technique to secure public clients that don't use a client secret. See this blog for more information about using PKCE with mobile apps.
Prerequisites
You have the required permissions for adding and managing OAuth apps in this Organization.
Procedure
- Click your user name and select View Organization > OAuth Apps, select the Owned Apps tab, and then click Create New OAuth App.
- Select Web/Mobile app and click Continue.
- Register your app by entering the app details:
- Type a name and description for the new OAuth app.
- Enter at least one redirect URI.
After a user authorizes your client, the authorization server redirects the user back to your client to the URI you specified with an access token. It is best practice to add more than one URI. Use the formathttp://acme.com. - Specify a time span for your access token.
- The default Access Token time to live (TTL) setting is 30 minutes.
- The maximum value you can set is 300 minutes (five hours).
- The minimum value you can set is 1 minute.
- If you want your access token to authorize requests continuously, select the Issue a refresh token and set Refresh Token TTL value.
- The default Refresh Token TTL is 30 minutes.
- The maximum value you can set is 300 minutes (five hours).
- The minimum value you can set is 1 minute.
- Define scopes.
Scopes provide a way to implement control over what areas in your Organization your client can access - specifically which of your services and the level of permission. - Select the Open ID check box to get information about the users that authorize your app.
- Click Create to generate the client credentials.
- Copy the app ID or download a JSON file that contains the app ID. You are responsible for storing these credentials in a safe place.
- Click Continue.
- Paste the credentials into your script.
What Is the difference between OAuth apps and API tokens
You use both OAuth apps and API tokens to interact with the Omnissa Cloud Services APIs.
Important: Before using OAuth apps of the Server to server type for automated calls to your cloud services, you must first consult the relevant API documentation.
API tokens are issued by users in an Organization and are associated with the user’s account and the Organization from which they generated the API token. Once created by a user in an Organization, OAuth apps act as entities in Server to server interactions and can be used in multiple Organizations. Only the users who created the API tokens can manage them. The owner of the OAuth app is the Organization in which it was created, and can be managed by users who are Organization Owners or Organization Members with a Developer role.
You can use both OAuth apps and API tokens to automate processes that interact with the Omnissa Cloud Services APIs. The difference is that API tokens incorporate the user account in the access token while OAuth apps perform authorization without a user account. When you make a choice of using an API token or an OAuth app to make an API call, you must consider the specific requirements of the API service involved in the interaction.
Some APIs require a user account to be the authenticated entity while others don’t. For example, if you call an API to fetch Billing and Subscription information for your Organization in Omnissa Cloud Services, you can use either an OAuth app of the Server to server type or an API token to make calls to the API service as it does not require authentication through user credentials and accepts client credentials as well. If an API is used by the users of an Organization to update their passwords, the API requires a user to act as the authenticating entity.
Was this page helpful?