Configuración del flujo de credenciales de cliente de OAuth 2.0 en Azure Active Directory B2C

Antes de comenzar, use el selector Elección de un tipo de directiva para elegir el tipo de directiva que va a configurar. Azure Active Directory B2C ofrece dos métodos para definir el modo en que los usuarios interactúan con las aplicaciones: por medio de flujos de usuario predefinidos o de directivas personalizadas totalmente configurables. Los pasos necesarios en este artículo son diferentes para cada método.

El flujo de concesión de credenciales de cliente de OAuth 2.0 permite que una aplicación (cliente confidencial) use sus propias credenciales para autenticarse al llamar a un recurso web, como la API de REST, en lugar de suplantar a un usuario. Este tipo de concesión se usa principalmente para las interacciones entre servidores que se deben ejecutar en segundo plano, sin la interacción inmediata con un usuario. Estos tipos de aplicaciones suelen denominarse demonios o cuentas de servicio.

En el flujo de credenciales de cliente, un administrador concede los permisos directamente en la propia aplicación. Cuando la aplicación presenta un token a un recurso, este exige que la propia aplicación tenga autorización para realizar una acción, ya que no hay ningún usuario implicado en la autenticación. En este artículo se describen los pasos necesarios para autorizar a una aplicación para que llame a una API, y cómo obtener los tokens necesarios para llamar a esa API.

Esta característica está en versión preliminar pública.

Introducción al registro de aplicaciones

Para que la aplicación pueda iniciar sesión con credenciales de cliente y llame a una API web, registre dos aplicaciones en el directorio de Azure AD B2C.

  • El registro de la aplicación permite que la aplicación inicie sesión con Azure AD B2C. El proceso de registro de la aplicación genera un identificador de aplicación, también conocido como identificador de cliente, que permite identificar de forma exclusiva la aplicación. También se crea un secreto de cliente, que la aplicación usa para obtener los tokens de forma segura.

  • El registro de API web permite que la aplicación llame a una API web segura. El registro incluye los ámbitos de la API web. Los ámbitos ofrecen una manera de administrar permisos para los recursos protegidos, como la API web. A continuación, a la aplicación se le conceden permisos para los ámbitos de la API web. Cuando se solicita un token de acceso, la aplicación especifica el parámetro de ámbito .default de la solicitud. Azure AD B2C devuelve los ámbitos de API web concedidos a la aplicación.

En el siguiente diagrama se muestran los registros y la arquitectura de la aplicación:

Diagram of a web app with web A P I call registrations and tokens.

Paso 1: Registro de la aplicación de API web

En este paso, registrará la API web (App 2) con los ámbitos. Más adelante, concede permiso a la aplicación (Aplicación 1) a esos ámbitos. Si ya tiene este registro de aplicación, omita este paso y, a continuación, vaya al siguiente, Paso 1.1 Definir roles de API web (ámbitos).

Siga estos pasos para crear el registro de aplicación de API web (Id. de aplicación: 2):

  1. Inicie sesión en Azure Portal.

  2. Asegúrese de que usa el directorio que contiene el inquilino de Azure AD B2C. Seleccione el icono Directorios y suscripciones en la barra de herramientas del portal.

  3. En la página Configuración del portal | Directorios y suscripciones, busque el directorio de Azure AD B2C en la lista Nombre de directorio y seleccione Cambiar.

  4. En Azure Portal, busque y seleccione Azure AD B2C.

  5. Seleccione Registros de aplicaciones y luego Nuevo registro.

  6. En Nombre, escriba un nombre para la aplicación (por ejemplo, my-api1). Deje los valores predeterminados para URI de redireccionamiento y Tipos de cuenta admitidos.

  7. Seleccione Registrar.

  8. Una vez completado el registro de la aplicación, seleccione Información general.

  9. Anote el valor Id. de aplicación (cliente) para usarlo más adelante al configurar la aplicación web.

    Screenshot that demonstrates how to get a web A P I application I D.

Paso 1.1 Definir roles de API web (ámbitos)

En este paso, configurará el URI de id. de aplicación de API web y, a continuación, definirá roles de aplicación. Los roles de aplicación, usados por los ámbitos de OAuth 2.0 y definidos en un registro de aplicación que representa la API. La aplicación usa el URI de id. de aplicación con el ámbito .default. Para definir los roles de seguridad, siga estos pasos:

  1. Seleccione la API web que creó, por ejemplo , my-api1.

  2. En Administrar, seleccione Exponer una API.

  3. Junto a URI de id. de aplicación, seleccione el vínculo Establecer. Reemplace el valor predeterminado (GUID) por un nombre único (por ejemplo, api) y, luego, seleccione Guardar.

  4. Copie el URI del id. de la aplicación. En la captura de pantalla siguiente se muestra cómo copiar el URI del id. de la aplicación.

    Screenshot shows how to copy the application I D.

  5. En Administrar, seleccione Manifiesto para abrir el editor de manifiestos de aplicación. En el editor, localice la appRoles configuración y defina los roles de aplicación que tienen como objetivo applications. Cada definición de roles de aplicación debe tener un identificador único global (GUID) para su valor id. Genere un nuevo GUID ejecutando el comando new-guid en Microsoft PowerShell o un generador GUID en línea. La propiedad value de cada definición de roles de aplicación aparece en el ámbito, la notificación scp. La propiedad value no puede contener espacios. En el ejemplo siguiente se muestran dos roles de aplicación, lectura y escritura:

    "appRoles": [
    {
      "allowedMemberTypes": ["Application"],
      "displayName": "Read",
      "id": "d6a15e20-f83c-4264-8e61-5082688e14c8",
      "isEnabled": true,
      "description": "Readers have the ability to read tasks.",
      "value": "app.read"
    },
    {
      "allowedMemberTypes": ["Application"],
      "displayName": "Write",
      "id": "204dc4ab-51e1-439f-8c7f-31a1ebf3c7b9",
      "isEnabled": true,
      "description": "Writers have the ability to create tasks.",
      "value": "app.write"
    }],
    
  6. En la parte superior de la página, seleccione Guardar para guardar los cambios del manifiesto.

Paso 2: Registro de una aplicación

Para permitir que la aplicación inicie sesión con Azure AD B2C mediante el flujo de credenciales de cliente, puede usar una aplicación existente o registrar una nueva (aplicación 1).

Si usa una aplicación existente, asegúrese de que la aplicación accessTokenAcceptedVersion está establecida en 2:

  1. En Azure Portal, busque y seleccione Azure AD B2C.
  2. Seleccione Registros de aplicaciones y, luego, seleccione la aplicación existente en la lista.
  3. En el menú izquierdo, en Administrar, seleccione Manifiesto para abrir el editor de manifiesto.
  4. Busque el elemento accessTokenAcceptedVersion establezca su valor en 2.
  5. En la parte superior de la página, seleccione Guardar para guardar los cambios.

Siga estos pasos para crear un registro de la aplicación web:

  1. En Azure Portal, busque y seleccione Azure AD B2C

  2. Seleccione Registros de aplicaciones y luego Nuevo registro.

  3. Escriba un Nombre para la aplicación. Por ejemplo, ClientCredentials_app.

  4. Deje los demás valores como están y seleccione Registrar.

  5. Anote el Id. de aplicación (cliente) para usarlo en un paso posterior.

    Screenshot shows how to get the application I D.

Paso 2.1 Creación de un secreto de cliente

Cree un secreto de cliente para la aplicación registrada. La aplicación usa el secreto de cliente para demostrar su identidad al solicitar tokens.

  1. En Administrar, seleccione Certificates & secrets (Certificados y secretos).

  2. Seleccione Nuevo secreto de cliente.

  3. Escriba una descripción para el secreto de cliente en el cuadro Descripción (por ejemplo, clientsecret1).

  4. En Expira, seleccione el tiempo durante el cual el secreto es válido y, a continuación, seleccione Agregar.

  5. Registre el Valor del secreto. Este valor se usa para la configuración en un paso posterior.

    Screenshot shows how to copy the application secret.

Paso 2.2 Conceder permisos de aplicación para la API web

Si desea conceder permisos a la aplicación (Aplicación 1), siga estos pasos:

  1. Seleccione Registros de aplicaciones y, luego, la aplicación que creó (Aplicación 1).

  2. En Administrar, seleccione Permisos de API.

  3. En Permisos configurados, seleccione Agregar un permiso.

  4. Seleccione la pestaña Mis API.

  5. Seleccione la API (Aplicación 2) a la que la aplicación web debe tener acceso. Por ejemplo, escriba my-api1.

  6. Seleccione Permiso de aplicación.

  7. En Permiso, expanda Aplicación y, a continuación, seleccione los ámbitos que definió anteriormente (por ejemplo, app.read y app.write).

    Screenshot shows how to grant the application A P I permissions.

  8. Seleccione Agregar permisos.

  9. Seleccione Conceder consentimiento de administrador para <el nombre de inquilino>.

  10. Seleccione .

  11. Seleccione Actualizar y compruebe que aparece Granted for... (Concedido para...) en Estado para ambos ámbitos.

Paso 3: Obtención de un token de acceso

No hay ninguna acción específica para habilitar las credenciales de cliente para flujos de usuario o directivas personalizadas. Tanto los flujos de usuario de Azure AD B2C como las directivas personalizadas admiten el flujo de credenciales de cliente. Si aún no lo ha hecho, cree un flujo de usuario o una directiva personalizada. A continuación, use su aplicación de desarrollo de API favorita para generar una solicitud de autorización. Cree una llamada como en este ejemplo con la siguiente información como el cuerpo de la solicitud POST:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy>/oauth2/v2.0/token

  • Reemplace <tenant-name> por el nombre del inquilino de Azure AD B2C. Por ejemplo, contoso.b2clogin.com.
  • Reemplace <policy> por el nombre completo del flujo de usuario o la directiva personalizada. Tenga en cuenta que todos los tipos de flujos de usuario y directivas personalizadas admiten el flujo de credenciales de cliente. Puede usar cualquier flujo de usuario o directiva personalizada que tenga o crear una nueva, como el registro o el inicio de sesión.
Clave Value
grant_type client_credentials
client_id El Id. de cliente del paso 2 Registrar una aplicación.
client_secret El valor Secreto de cliente del Paso 2.1 Crear un secreto de cliente.
scope El URI de id. de aplicación del Paso 1.1 Definir roles de API web (ámbitos) y .default. Por ejemplo, https://contoso.onmicrosoft.com/api/.default o https://contoso.onmicrosoft.com/12345678-0000-0000-0000-000000000000/.default.

La solicitud POST real es similar al ejemplo siguiente:

Solicitud:

POST /<tenant-name>.onmicrosoft.com/B2C_1A_SUSI/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=33333333-0000-0000-0000-000000000000
&client_secret=FyX7Q~DuPJ...
&scope=https%3A%2F%2Fcontoso.onmicrosoft.com%2Fapi%2F.default

Respuesta:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IlBFcG5OZDlnUkNWWUc2dUs...",
    "token_type": "Bearer",
    "not_before": 1645172292,
    "expires_in": 3600,
    "expires_on": 1645175892,
    "resource": "33333333-0000-0000-0000-000000000000"
}

Obtenga información sobre las notificaciones del token de acceso de devolución. En la tabla siguiente se enumeran las notificaciones relacionadas con el flujo de credenciales de cliente.

Notificación Descripción Value
aud Identifica al destinatario previsto del token. Id. de cliente de la API.
sub La entidad de servicio se asocia a la aplicación que inició la solicitud. Es la entidad de servicio de client_id de la solicitud de autorización.
azp Entidad autorizada: la entidad a la que se emitió el token de acceso. El id. de cliente de la aplicación que inició la solicitud. Es el mismo valor que especificó en el client_id de la solicitud de autorización.
scp Conjunto de ámbitos expuestos por la API de aplicación (delimitador de espacio). En el flujo de credenciales de cliente, la solicitud de autorización solicita el ámbito .default, mientras que el token contiene la lista de ámbitos expuestos (y consentidos por el administrador de aplicaciones) por la API. Por ejemplo, app.read app.write.

Paso 3.1 Obtención de un token de acceso con script

Use el siguiente script de PowerShell para probar la configuración:

$appId = "<client ID>"
$secret = "<client secret>"
$endpoint = "https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy>/oauth2/v2.0/token"
$scope = "<Your API id uri>/.default"
$body = "grant_type=client_credentials&scope=" + $scope + "&client_id=" + $appId + "&client_secret=" + $secret

$token = Invoke-RestMethod -Method Post -Uri $endpoint -Body $body

Use el siguiente script de cURL para probar la configuración:

curl --location --request POST 'https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/<policy>/oauth2/v2.0/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--form 'grant_type="client_credentials"' \
--form 'client_id="<client ID>"' \
--form 'client_secret="<client secret>"' \
--form 'scope="<Your API id uri>/.default"'

Paso 4: Personalización del token

Esta característica está disponible solo para directivas personalizadas. En los pasos de configuración, elija Directiva personalizada en el selector anterior.

Las directivas personalizadas proporcionan una manera de ampliar el proceso de emisión de tokens. Para personalizar el recorrido del usuario de las credenciales de cliente de OAuth 2.0, siga las instrucciones sobre cómo configurar un recorrido de usuario de credenciales de cliente. A continuación, en el perfil técnico JwtIssuer, agregue los metadatos ClientCredentialsUserJourneyId con una referencia al recorrido del usuario que ha creado.

En el ejemplo siguiente se muestra cómo agregar ClientCredentialsUserJourneyId al perfil técnico del emisor de tokens.

<TechnicalProfile Id="JwtIssuer">
  <Metadata>
    <Item Key="ClientCredentialsUserJourneyId">ClientCredentialsJourney</Item>
  </Metadata>
</TechnicalProfile>

En el ejemplo siguiente se muestra un recorrido de usuario de credenciales de cliente. Se requieren los primeros y los últimos pasos de orquestación.

<UserJourneys>
  <UserJourney Id="ClientCredentialsJourney">
    <OrchestrationSteps>
      <!-- [Required] Do the client credentials -->
      <OrchestrationStep Order="1" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="ClientCredSetupExchange" TechnicalProfileReferenceId="ClientCredentials_Setup" />
        </ClaimsExchanges>
      </OrchestrationStep>

      <!-- [Optional] Call a REST API or claims transformation -->
      <OrchestrationStep Order="2" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="TokenAugmentation" TechnicalProfileReferenceId="TokenAugmentation" />
        </ClaimsExchanges>
      </OrchestrationStep>

      <!-- [Required] Issue the access token -->
      <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys>

Pasos siguientes

Averigüe cómo puede configurar el flujo de credenciales de contraseña de propietario del recurso en Azure AD B2C