Autorización del acceso a aplicaciones web mediante OpenID Connect y Azure Active Directory

OpenID Connect es una capa de identidad sencilla basada en el protocolo OAuth 2.0. OAuth 2.0 define mecanismos para obtener y usar tokens de acceso para acceder a los recursos protegidos, pero no define métodos estándar para proporcionar información de identidad. OpenID Connect implementa la autenticación como una extensión para el proceso de autorización de OAuth 2.0. Proporciona información sobre el usuario final en forma de un id_token que comprueba la identidad del usuario y proporciona información de perfil básica sobre el usuario.

OpenID Connect es nuestra recomendación si va a compilar una aplicación web hospedada en un servidor y a la que se accede a través de un explorador.

Registre su aplicación con el inquilino de Azure Active Directory (AD)

En primer lugar, registre la aplicación con el inquilino de Azure Active Directory (Azure AD). Esto le proporcionará un identificador de aplicación para la aplicación, así como habilitarlo para recibir tokens.

1. Inicie sesión en Azure Portal.

2. Elija su entidad de Azure AD seleccionando su cuenta en la esquina superior derecha de la página, luego seleccione la opción de menú Cambiar directorio y, a continuación, seleccione la entidad adecuada.

   • Omita este paso si solo tiene un inquilino de Azure AD en su cuenta o si ya ha seleccionado el inquilino de Azure AD adecuado.

3. En Azure Portal, busque y seleccione Azure Active Directory.

4. En el menú de izquierda de Azure Active Directory, seleccione registros de aplicacionesy, a continuación, seleccione Nuevo registro.

5. Siga las indicaciones y cree una nueva aplicación. No importa si es una aplicación web o una aplicación cliente pública (& escritorio móvil) para este tutorial, pero si desea ejemplos específicos para aplicaciones web o aplicaciones cliente públicas, consulte nuestras guías de inicio rápido .

   • Nombre es el nombre de la aplicación y describe la aplicación a los usuarios finales.
   • En Supported account types (Tipos de cuenta compatibles), seleccione Accounts in any organizational directory and personal Microsoft accounts (Cuentas en cualquier directorio de organización y cuentas personales de Microsoft).
   • Proporcione el URI de redirección. En el caso de las aplicaciones web, esta es la dirección URL base de la aplicación donde los usuarios pueden iniciar sesión. Por ejemplo: http://localhost:12345. Para el cliente público (móvil y de escritorio), Azure AD lo utiliza para devolver respuestas de token. Escriba un valor específico de la aplicación. Por ejemplo: http://MyFirstAADApp.

6. Una vez completado el registro, Azure AD asignará a la aplicación un identificador de cliente único (el identificador de aplicación ). Necesita este valor en las secciones siguientes, así que cópielo desde la página de la aplicación.

7. Para buscar la aplicación en Azure Portal, seleccione Registros de aplicacionesy, a continuación, seleccione Ver todas las aplicaciones.

Flujo de autenticación con OpenID Connect

El flujo de inicio de sesión más básico contiene los pasos siguientes: cada uno de ellos se describe en detalle a continuación.

Documento de metadatos de OpenID Connect

OpenID Connect describe un documento de metadatos que contiene la mayoría de la información necesaria para que una aplicación realice el inicio de sesión. Esto incluye información como las direcciones URL que se van a usar y la ubicación de las claves de firma pública del servicio. El documento de metadatos de OpenID Connect se puede encontrar en:

https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration

Los metadatos son un documento simple de notación de objetos JavaScript (JSON). Consulte el siguiente fragmento de código para obtener un ejemplo. El contenido del fragmento se describe completamente en la especificación OpenID Connect de . Tenga en cuenta que proporcionar un identificador de inquilino en lugar de common en lugar de {tenant} anterior dará lugar a URI específicos del inquilino en el objeto JSON devuelto.

{
    "authorization_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/authorize",
    "token_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/token",
    "token_endpoint_auth_methods_supported":
    [
        "client_secret_post",
        "private_key_jwt",
        "client_secret_basic"
    ],
    "jwks_uri": "https://login.microsoftonline.com/common/discovery/keys"
    "userinfo_endpoint":"https://login.microsoftonline.com/{tenant}/openid/userinfo",
    ...
}

Si su aplicación tiene claves de firma personalizadas como resultado del uso de la característica de asignación de declaraciones , debe anexar un parámetro de consulta appid que contenga el identificador de la aplicación para obtener un enlace jwks_uri que apunte a la información de clave de firma de su aplicación. Por ejemplo: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e contiene el elemento jwks_uri de https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e.

Envío de la solicitud de inicio de sesión

Cuando la aplicación web necesita autenticar al usuario, debe dirigir al usuario al punto de conexión de /authorize. Esta solicitud es similar a la primera etapa del flujo de autorización por código de OAuth 2.0, con algunas diferencias importantes.

• La solicitud debe incluir el ámbito openid en el parámetro scope.
• El parámetro response_type debe incluir id_token.
• La solicitud debe incluir el parámetro nonce.

Por lo tanto, una solicitud de ejemplo tendría este aspecto:

// Line breaks for legibility only

GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%3a12345
&response_mode=form_post
&scope=openid
&state=12345
&nonce=7362CAEA-9CA5-4B43-9BA3-34D7C303EBA7

En este punto, se le pide al usuario que escriba sus credenciales y que complete la autenticación.

Respuesta de ejemplo

Una respuesta de ejemplo, enviada a la redirect_uri especificada en la solicitud de inicio de sesión después de que el usuario se haya autenticado, podría tener este aspecto:

POST / HTTP/1.1
Host: localhost:12345
Content-Type: application/x-www-form-urlencoded

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&state=12345

Respuesta de error

Las respuestas de error también pueden enviarse al redirect_uri para que la aplicación pueda controlarlas adecuadamente:

POST / HTTP/1.1
Host: localhost:12345
Content-Type: application/x-www-form-urlencoded

error=access_denied&error_description=the+user+canceled+the+authentication

Códigos de error para errores del endpoint de autorización

En la tabla siguiente se describen los distintos códigos de error que pueden devolverse en el parámetro error de la respuesta de error.

Validar el "id_token"

La recepción de un id_token no es suficiente para autenticar al usuario; debes validar la firma y verificar las declaraciones en el id_token según los requisitos de tu aplicación. El punto de conexión de Azure AD usa tokens web JSON (JWT) y criptografía de clave pública para firmar tokens y comprobar que son válidos.

Puede optar por validar el id_token en el código de cliente, pero una práctica habitual es enviar el id_token a un servidor back-end y realizar la validación allí.

Es posible que también desee validar las reclamaciones adicionales en función de su escenario. Algunas validaciones comunes incluyen:

• Asegurarse de que el usuario o la organización se ha registrado en la aplicación.
• Asegurarse de que el usuario tiene la debida autorización/privilegios mediante las declaraciones wids o roles.
• Asegurarse de que se ha alcanzado un cierto nivel de seguridad en la autenticación, como la autenticación multifactor.

Una vez que haya validado el id_token, puede iniciar una sesión con el usuario y usar las declaraciones en el id_token para obtener información sobre el usuario en tu aplicación. Esta información se puede usar para mostrar, para registros, personalización, etc. Para obtener más información sobre id_tokens y reclamaciones, lea AAD id_tokens.

Envío de una solicitud de cierre de sesión

Cuando quieres cerrar la sesión del usuario de la aplicación, no es suficiente borrar las cookies de tu aplicación o finalizar la sesión con el usuario. También debe redirigir al usuario a la end_session_endpoint para cerrar sesión. Si no lo hace, el usuario podrá volver a autenticarse en la aplicación sin volver a escribir sus credenciales, ya que tendrá una sesión de inicio de sesión único válida con el punto de conexión de Azure AD.

Puedes simplemente redirigir al usuario a la end_session_endpoint que aparece en el documento de metadatos de OpenID Connect.

GET https://login.microsoftonline.com/common/oauth2/logout?
post_logout_redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F

Cierre de sesión único

Al redirigir al usuario a la end_session_endpoint, Azure AD borra la sesión del usuario desde el explorador. Sin embargo, es posible que el usuario siga iniciando sesión en otras aplicaciones que usan Azure AD para la autenticación. Para permitir que esas aplicaciones cierren la sesión del usuario simultáneamente, Azure AD envía una solicitud HTTP GET a la LogoutUrl registrada de todas las aplicaciones a las que el usuario ha iniciado sesión actualmente. Las aplicaciones deben responder a esta solicitud borrando cualquier sesión que identifique al usuario y devuelva una respuesta 200. Si desea admitir el cierre de sesión único en su aplicación, debe implementar dicho LogoutUrl en el código de su aplicación. Puede establecer el LogoutUrl desde Azure Portal:

1. Inicie sesión en Azure Portal.
2. Elija su Active Directory haciendo clic en su cuenta en la esquina superior derecha de la página.
3. En el panel de navegación izquierdo, elija azure Active Directoryy, después, elija Registros de aplicaciones y seleccione la aplicación.
4. Haga clic en Configuración, luego en Propiedades y busque el cuadro de texto URL de cierre de sesión.

Adquisición de tokens

Muchas aplicaciones web no solo necesitan iniciar sesión del usuario, sino también acceder a un servicio web en nombre de ese usuario mediante OAuth. Este escenario combina el uso de OpenID Connect para la autenticación de usuario y, simultáneamente, para adquirir una authorization_code que se puede utilizar para obtener access_tokens mediante el flujo de código de autorización de OAuth de .

Obtención de tokens de acceso

Para adquirir tokens de acceso, debe modificar la solicitud de inicio de sesión anterior:

// Line breaks for legibility only

GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e        // Your registered Application ID
&response_type=id_token+code
&redirect_uri=http%3A%2F%2Flocalhost%3a12345          // Your registered Redirect Uri, url encoded
&response_mode=form_post                              // `form_post' or 'fragment'
&scope=openid
&resource=https%3A%2F%2Fservice.contoso.com%2F        // The identifier of the protected resource (web API) that your application needs access to
&state=12345                                          // Any value, provided by your app
&nonce=678910                                         // Any value, provided by your app

Al incluir ámbitos de permisos en la solicitud y usar response_type=code+id_token, el punto de conexión de authorize garantiza que el usuario haya consentido los permisos indicados en el parámetro de consulta scope y devuelva a la aplicación un código de autorización para intercambiar un token de acceso.

Respuesta exitosa

Una respuesta correcta, enviada al redirect_uri mediante response_mode=form_post, tiene el siguiente aspecto:

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...&state=12345

Respuesta de error

Las respuestas de error también pueden enviarse al redirect_uri para que la aplicación pueda controlarlas adecuadamente:

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

error=access_denied&error_description=the+user+canceled+the+authentication

Para obtener una descripción de los posibles códigos de error y su acción de cliente recomendada, consulte Códigos de error para errores de punto de conexión de autorización.

Una vez que haya obtenido una autorización code y una id_token, puede iniciar la sesión del usuario y obtener, en su nombre, tokens de acceso. Para iniciar sesión el usuario, debe validar el id_token exactamente como se ha descrito anteriormente. Para obtener fichas de acceso, siga los pasos indicados en la sección "Usar el código de autorización para solicitar una ficha de acceso" de nuestra documentación del flujo OAuth de .

Pasos siguientes

• Obtenga más información sobre los tokens de acceso .
• Obtenga más información sobre el id_token y las reclamaciones.