VMware Cloud Services Console uses OAuth 2.0 so that you can give your applications secure delegated access to the protected resources in your Organization. VMware 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 VMware Cloud Services

VMware 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 VMware 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 VMware Cloud on AWS APIs.

  1. 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.
  2. 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.
  3. 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.