VMware Consola de Cloud Services utiliza OAuth 2.0 para que pueda conceder a las aplicaciones acceso delegado seguro a los recursos protegidos de su organización. VMware Cloud Services admite el acceso a las aplicaciones web en las que los usuarios de su aplicación autoricen el acceso y las interacciones de servidor a servidor cuando los tokens de acceso se emitan directamente a su aplicación.

¿Qué es OAuth 2.0?

OAuth 2.0 es un protocolo de autorización que le permite conceder a las aplicaciones acceso seguro a sus recursos. Se autoriza al cliente con un token de acceso, en cuyo ámbito se definen los recursos a los que este puede acceder. Para obtener información sobre OAuth 2.0, consulte las especificaciones de OAuth en https://tools.ietf.org/html/rfc6749#page-8 o lea la publicación de blog OAuth 2.0 Simplified (en inglés) en https://aaronparecki.com/oauth-2-simplified/.

Cómo funciona OAuth 2.0 con VMware Cloud Services

VMware Cloud services abarca varios casos de uso para la autorización de aplicaciones mediante diferentes tipos de concesión, como client credentials, authorization code, y public client con authorization code. En función de sus objetivos, debe crear uno de los tres tipos de aplicaciones de OAuth que correspondan a cada tipo de concesión (respectivamente, la aplicación de servidor a servidor, la aplicación web y la aplicación nativa/móvil).

Supongamos que es un Propietario de la organización con acceso a VMware Cloud on AWS. y ha desarrollado una aplicación que le ayuda a operar con sus existencias. Su aplicación se llama Trading 1.0 y desea ejecutarla en máquinas virtuales que están administradas con vCenter Server, pero antes debe autorizar la aplicación con las API de VMware Cloud on AWS.

  1. Cree una aplicación de OAuth 2.0 en Consola de Cloud Services. Considere este paso como una forma de registrar la aplicación Trading 1.0. Para iniciar la creación de la aplicación, haga clic en Crear aplicación en el menú Organización > Aplicaciones de OAuth y realice los pasos que se le indiquen. Al final del proceso, emitimos credenciales de cliente (un identificador y un secreto de la aplicación) que se utilizan para identificar al cliente con las API. Pegue estas credenciales en el script.
  2. La aplicación se creó en la organización, pero aún no se le concedió acceso a ella. Para concederle acceso, agréguela a la organización. Esto permite que la aplicación acceda a los servicios y los recursos de la organización que definió al crear la aplicación. Este paso solo es necesario para las aplicaciones del tipo servidor a servidor. No es relevante para las aplicaciones web y nativas/móviles.
  3. Al ejecutar la aplicación cliente Trading 1.0, esta solicita un token de acceso del servidor de autorización. Cuando se autoriza, el servidor de autorización envía un token de acceso a las API y se concede acceso al cliente.

¿Quién puede crear y administrar aplicaciones de OAuth?

Como usuario Propietario de la organización o usuario Miembro de la organización con la función de usuario Desarrollador, puede crear y administrar aplicaciones de OAuth.

También puede administrar las aplicaciones de OAuth que creen o agreguen otros usuarios con la función Propietario de la organización.

¿Se puede volver a generar un secreto de la aplicación?

Sí, como Propietario de la organización, puede volver a generar el secreto de una aplicación de OAuth de su organización. Esto resulta útil si el Propietario de la organización que creó la aplicación de OAuth ya no está en su empresa y usted desea seguir ejecutando esa aplicación.

¿Se puede utilizar una autenticación de token de API en lugar de una aplicación de OAuth?

Sí, si una API exige que un usuario sea la entidad autenticada del proceso de autorización, debe utilizar un token de API en lugar de la aplicación de OAuth. Para comprobar cuándo se deben utilizar las aplicaciones de OAuth o los tokens de API, consulte Diferencias entre las aplicaciones de OAuth y los tokens de API.