Política de acceso para tipos de otorgamiento de API

Editar en línea

La política de acceso se puede aplicar al uso controlado por API de OpenID Connect y OAuth 2.0. Este uso de API es más conocido como el tipo de otorgamiento Credenciales de contraseña de propietario de recurso (ROPC), pero también incluye el tipo de otorgamiento basado en aserciones JWT. A diferencia del código de autorización y los tipos de otorgamiento implícitos, estos tipos de otorgamiento tienen una diferencia fundamental en cómo operan. No existe ningún agente de usuario de navegador y no se realiza ninguna solicitud al punto final /authorize. Como este punto final de navegador no se utiliza, la política de acceso para una aplicación se debe evaluar de forma distinta.

Cuando se aplica una política de acceso, se abordan estos requisitos empresariales fundamentales:

  • ¿Se ha autenticado lo suficiente el usuario para acceder a esta aplicación?
  • ¿Se permite al usuario autenticado acceder a esta aplicación?
  • ¿Está permitido el dispositivo o el contexto de cliente utilizado para acceder a esta aplicación?

En los flujos de navegador tradicionales se aplican estos requisitos. Si no se cumplen, el navegador solicita MFA o devuelve una página de error al usuario que detiene el acceso. En un tipo de otorgamiento de API, no todas estas facilidades están disponibles. Por tanto, se deben abordar los problemas siguientes.

  • Contexto de recepción desde un dispositivo cliente.
  • Devolución de una solicitud de MFA, que incluye:
    • Las API que se necesitan para cumplir la MFA.
    • Cómo acceder a las API.
Los tipos de otorgamiento controlados por API pueden seguir devolviendo un error, por lo que no se modifica en gran medida una denegación.

Tipo de otorgamiento de policyauth

Para aplicar de forma efectiva una política de acceso a un flujo OAuth 2.0 de solo API, se ha introducido un nuevo tipo de otorgamiento. Este tipo de otorgamiento permite a un cliente presentar algún contexto a la política de acceso antes de cualquier autenticación. Esta capacidad permite implementar una experiencia del usuario mejorada. Por ejemplo, cuando un usuario pulsa un botón de inicio de sesión, antes de que se le solicite que especifique las credenciales, se le evalúa de acuerdo con la política asociada. Si no cumple los requisitos de política, el usuario recibe un mensaje de error que indica que no se puede autenticar ni acceder al recurso debido a los requisitos de política.

Cuando se utiliza el tipo de otorgamiento policyauth, se devuelve una de estas respuestas.
Una denegación
Un error que indica que no se puede otorgar acceso debido a la política.
Una solicitud
Se devuelve una señal que se puede utilizar para acceder a las API de autenticación, con una lista de factores de autenticación aceptables.

Respuestas de solicitud de MFA de /token

Cuando se aplica una política de acceso a un flujo de API OAuth 2.0, debe formar parte del contrato de API una solicitud para MFA. No son posibles los métodos tradicionales de OP que realizan los pasos de MFA como parte de la solicitud a /authorize.

Cuando /token devuelve una solicitud de MFA:

  • El ámbito es mfa_challenge y no se devuelven otros ámbitos.
  • Se emite una señal de acceso.
    • La señal de acceso tiene autorización para acceder a las API de autenticación necesarias. Es importante que se utilice esta señal de acceso y no una señal de acceso de cliente de API normal. Esta señal se utiliza para realizar un seguimiento de los factores de autenticación que ya se han realizado y las acciones anteriores en el otorgamiento.
    • La señal de acceso devuelve active: true de las solicitudes a /introspect. Cuando se utilizan las solicitudes de MFA, cualquier API que proteja un servidor de recursos debe implementar una comprobación de que el scope devuelto de /introspect no es igual a mfa_challenge.
  • Opcionalmente, se enumera una matriz de factores que se pueden realizar para satisfacer esta solicitud allowedFactors.

Presentación de contexto a /token

El cliente de API que realiza una solicitud a /token puede presentar información de contexto bien definida y arbitraria a /token para utilizarla en la evaluación de política de acceso.

Se deben incluir tres fragmentos de información de contexto obligatorios.

  • sessionId: un identificador de sesión arbitrario emitido y mantenido por el cliente de OAuth.
  • ipAddress: como el cliente de OAuth es el responsable de las interacciones con el agente de usuario, se debe proporcionar explícitamente la dirección IP del usuario.
  • userAgent: de forma similar a la dirección IP, se debe proporcionar explícitamente el agente de usuario del usuario.

Se pueden incluir más parámetros y se pueden crear condiciones de atributo de contexto en estos valores.

Nota: Si el context parámetro no se incluye en una solicitud a /token, no se aplica la política de acceso.

Se proporciona el contexto a /token en forma de JSON codificado en base64. Un ejemplo de carga útil JSON para el contexto es:

{
    "sessionId":"MDNjZmQ3NDM2NjFmMDc5NzVmYTJmMT",
    "ipAddress":"129.42.38.10",
    "userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36"
}

La información de contexto se considera fiable, porque la presenta un cliente de API al que se ha emitido un conjunto de credenciales de cliente seguro. Este cliente de API debe asegurarse de que no permite que el agente de usuario consumidor presente arbitrariamente el contexto, que se puede utilizar para eludir los controles empresariales.

El contexto debe proporcionarse siempre que se invoque una política de acceso en todos los tipos de concesión de la API: policyAuth JWT Bearer,, ROPC y refresh token.

Satisfacción de mfa_challenge

Para satisfacer una solicitud de MFA devuelta por el punto final /token, se pueden utilizar las API de factores de autenticación. Estas API se utilizan para satisfacer los requisitos del primer y segundo factor. La señal de acceso que se devuelve en la respuesta mfa_challenge se utiliza para solicitar el factor adecuado. Después de una finalización satisfactoria del factor, se devuelve un JWT. Este JWT contiene algunos fragmentos de información clave.

  • El grant_id que se deriva de la señal de acceso utilizada para solicitar la API del factor. Este ID mantiene la correlación entre las distintas solicitudes a /token.
  • El factor que se ha realizado y los factores que se han realizado anteriormente.

Este JWT se presenta a /token como parte de un flujo de tipo de otorgamiento jwtBearer. Se reevalúa la política de acceso y se emite una señal totalmente autorizada u otra solicitud.

Para recibir un JWT de una verificación de factor, es necesario incluir el parámetro returnJwt=true de la cadena de consulta.
Nota:
  • Para las API de factor transitorio, el campo sub del JWT se rellena con la información transitoria utilizada en la solicitud. Por ejemplo, el correo electrónico o el número de teléfono en lugar de un userId.
  • Cuando se establece returnJwt=true, las API de verificación que normalmente devuelven un código de estado de 204 sin ningún cuerpo HTTP, cambian su código de estado a un 200. Devuelven el content-type de application/json y tienen una respuesta como:
    {
    "assertion:"ey..."}
    Para las verificaciones de factores que ya devuelven JSON, se añade la propiedad assertion a la respuesta.

Aplicación de política de acceso a distintos tipos de otorgamiento

Cuando configura una aplicación, existe una opción que indica si la política de acceso se aplica a un tipo de otorgamiento específico.

Esta configuración controla si la política de acceso se evalúa en una solicitud como /token que se basa en el valor del parámetro grant_type. Esta evaluación se aplica independientemente de las invocaciones anteriores de /token para un otorgamiento específico.

Esta configuración se puede aplicar a los tipos de otorgamiento siguientes:
policyauth
La política de acceso debe estar siempre habilitada.
ROPC
La política de acceso se puede inhabilitar si el consumo del tipo de otorgamiento ROPC no admite la respuesta mfa_challenge.
JWT Bearer
Cuando la política de acceso está inhabilitada en el tipo de otorgamiento jwt-bearer, no se puede realizar una MFA a través del flujo policyauth. No se ejecutará una política de acceso después de que se realice el primer factor.
Refresh token
Se puede aplicar solo a un subconjunto de solicitudes refresh_token que utilizan el parámetro de contexto original_grant_type como condición de atributo de contexto.