Compartir a través de

OAuth 2.0 y OpenID Connect (OIDC) en la plataforma de identidad de Microsoft

  • Artículo

No es necesario saber sobre OAuth ni OpenID Connect (OIDC) en el nivel de protocolo para usar la plataforma de identidad de Microsoft. Pero encontrará términos y conceptos de protocolo cuando use la plataforma de identidad para agregar autenticación a las aplicaciones. A medida que trabaja con el Centro de administración de Microsoft Entra, nuestra documentación y bibliotecas de autenticación, conocer algunos fundamentos puede ayudar a su integración y experiencia general.

Roles en OAuth 2.0

Hay cuatro partes que suelen estar implicadas en un intercambio de autenticación y autorización de OAuth 2.0 y OpenID Connect. Estos intercambios a menudo se denominan flujos de autenticación o flujos de autorización.

Diagrama que muestra los roles de OAuth 2.0

  • Servidor de autorización: la plataforma de identidad de Microsoft es el servidor de autorización. También denominado proveedor de identidades o IdP, controla de forma segura la información del usuario final, su acceso y las relaciones de confianza entre las partes del flujo de autenticación. El servidor de autorización emite los tokens de seguridad que las aplicaciones y las API usan para conceder, denegar o revocar el acceso a los recursos (autorización) después de que el usuario ha iniciado sesión (autenticado).

  • Cliente: el cliente de un intercambio de OAuth es la aplicación que solicita acceso a un recurso protegido. El cliente podría ser una aplicación web que se ejecuta en un servidor, una aplicación web de una sola página que se ejecuta en el explorador web de un usuario o una API web que llama a otra API web. A menudo, verá que el cliente se conoce como aplicación cliente, aplicación o app.

  • Propietario del recurso: el propietario del recurso de un flujo de autenticación suele ser el usuario de la aplicación o el usuario final en la terminología de OAuth. El usuario final "posee" el recurso protegido (sus datos) al que accede la aplicación en su nombre. Los propietarios del recurso pueden conceder o denegar a la aplicación (al cliente) acceso a los recursos que posee. Por ejemplo, la aplicación podría llamar a la API de un sistema externo para obtener la dirección de correo electrónico de un usuario desde su perfil en ese sistema. Sus datos de perfil son un recurso que el usuario final posee en el sistema externo y el usuario final puede dar su consentimiento a la solicitud de acceso a los datos de la aplicación o denegarla.

  • Servidor de recursos : el servidor de recursos hospeda o proporciona acceso a los datos de un propietario del recurso. La mayoría de las veces, el servidor de recursos es una API web como front-end de un almacén de datos. El servidor de recursos se basa en el servidor de autorización para realizar la autenticación y usa la información en los tokens de portador emitidos por el servidor de autorización para conceder o denegar el acceso a los recursos.

Tokens

Las partes de un flujo de autenticación utilizan tokens de portador para asegurar y verificar una entidad de seguridad (usuario, host o servicio) y autenticarla y para conceder o denegar el acceso a recursos protegidos (autorización). Los tokens de portador de la plataforma de identidad de Microsoft tienen el formato JSON Web Tokens (JWT).

La plataforma de identidad usa tres tipos de tokens de portador como tokens de seguridad:

  • Tokens de acceso: el servidor de autorización emite tokens de acceso a la aplicación cliente. El cliente pasa tokens de acceso al servidor de recursos. Los tokens de acceso contienen los permisos que el servidor de autorización ha concedido al cliente.

  • Tokens de identificador: el servidor de autorización emite tokens de identificador a la aplicación cliente. Los clientes usan tokens de identificador al iniciar la sesión de los usuarios y para obtener información básica sobre ellos.

  • Tokens de actualización: el cliente usa un token de actualización, o RT, para solicitar nuevos tokens de acceso e identificador desde el servidor de autorización. El código debe tratar los tokens de actualización y su contenido de cadena como datos confidenciales porque la finalidad es que solo los use el servidor de autorización.

Registro de aplicación

La aplicación cliente necesita una manera de confiar en los tokens de seguridad que emite la plataforma de identidad de Microsoft. El primer paso para establecer la confianza es registrar la aplicación. Al registrar la aplicación, la plataforma de identidad le asigna automáticamente algunos valores, mientras que otros se configuran en función del tipo de la aplicación.

Dos de las configuraciones de registro de aplicaciones a las que se hace referencia con más frecuencia son las siguientes:

  • Identificador de aplicación (cliente): también denominado identificador de aplicación e Id. de cliente, la plataforma de identidad asigna este valor a la aplicación. El Id. de cliente identifica de forma única la aplicación en la plataforma de identidad y se incluye en los tokens de seguridad que emite la plataforma.
  • URI de redirección: el servidor de autorización usa un URI de redirección para dirigir el agente de usuario del propietario del recurso (explorador web o aplicación móvil) a otro destino después de finalizar su interacción. Por ejemplo, después de que el usuario final se autentica con el servidor de autorización. No todos los tipos de cliente usan URI de redirección.

El registro de la aplicación también contiene información acerca de los puntos de conexión de autenticación y autorización que usará en el código para obtener los tokens del identificador y acceso.

Puntos de conexión

La plataforma de identidad de Microsoft ofrece servicios de autenticación y autorización mediante implementaciones compatibles con los estándares de OAuth 2.0 y OpenID Connect (OIDC) 1.0. Los servidores de autorización que cumplen los estándares, como la plataforma de identidad, proporcionan un conjunto de puntos de conexión HTTP para que los usen las partes de un flujo de autenticación para ejecutar el flujo.

Los URI de punto de conexión de la aplicación se generan automáticamente al registrar o configurar la aplicación. Los puntos de conexión que use en el código de la aplicación dependen del tipo de la aplicación y de las identidades (tipos de cuenta) que debe admitir.

Dos puntos de conexión de uso frecuente son el punto de conexión de autorización y el punto de conexión de token. Estos son ejemplos de los puntos de conexión authorize y token:

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or domain name.

Para encontrar los puntos de conexión para una aplicación que ha registrado, en el Centro de administración de Microsoft Entra navegue a:

Identidad>Aplicaciones>Registros de aplicaciones><SU-APLICACIÓN>>Puntos de conexión

Pasos siguientes

A continuación, obtenga información acerca de los flujos de autenticación de OAuth 2.0 usados por cada tipo de aplicación y las bibliotecas que puede usar en las aplicaciones para realizarlos:

Se recomienda encarecidamente no crear su propia biblioteca ni llamadas HTTP sin procesar para ejecutar flujos de autenticación. Una Biblioteca de autenticación de Microsoft es más segura y más fácil de usar. Sin embargo, si el escenario impide usar nuestras bibliotecas o simplemente quiere obtener más información sobre la implementación de la plataforma de identidad de Microsoft, tenemos una referencia de protocolo: