Probar el flujo de acceso entre aplicaciones (XAA)

Aprenda a probar el flujo XAA de extremo a extremo.

Para probar el flujo XAA de extremo a extremo, debe verificar que su inquilino de Auth0 pueda aceptar las solicitudes JWT-Bearer enviadas por la aplicación solicitante. Auth0 se encarga de ello de forma predeterminada.

Antes de poder probar el flujo XAA de extremo a extremo, asegúrese de lo siguiente:

• Actualice el campo Redirect URI con la URL de devolución de llamada de su aplicación de prueba, que actúa como aplicación solicitante en su inquilino de Okta, como se explica en Registrar la aplicación solicitante en Okta.
• Proporcione a su representante de Okta la siguiente información:
  • La URL del emisor de su inquilino de Auth0. Su aplicación de recursos está asociada con la URL del emisor en Okta Integration Network (OIN), lo que permite que las aplicaciones solicitantes hagan referencia a ella al solicitar ID-JAG.
  • El client_id de Auth0 que se asigna a cada aplicación solicitante en la OIN.

Para obtener la URL del emisor y el ID de cliente en su inquilino de Auth0, vaya a Applications, seleccione su aplicación y luego Settings:

Campo	Instrucciones	Ejemplo
URL del emisor	Copie su dominio de Auth0, antepóngale https:// y agregue una barra diagonal al final.	https://tenant.region.auth0.com/ o, si sus clientes usan un dominio personalizado, https://custom-domain.com/.
client_id	Copie el ID de cliente de la aplicación.	ovBLQycaVq6I0Xyuhq84pwDVyJeXWLyx

​

Intercambiar el token de ID por un ID-JAG

Primero, debes iniciar sesión en tu aplicación solicitante con tu inquilino de prueba de Okta. Cuando inicies sesión correctamente y otorgues tu consentimiento, Okta redirige el navegador de nuevo a tu aplicación solicitante con un código de autorización. Luego, tu aplicación solicitante intercambia de forma segura el código de autorización por un token de acceso de Okta y un token de ID.

Para intercambiar el token de ID de Okta por un ID-JAG, la aplicación solicitante realiza una solicitud de intercambio de tokens al endpoint /token de tu inquilino de prueba de Okta con los siguientes parámetros:

POST /oauth2/v1/token HTTP/1.1
Host: {{YOUR_TENANT}}.okta.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience={{YOUR_AUTH0_TENANT_ISSUER_URL}}
&resource={{YOUR_AUTH0_TENANT_API_AUDIENCE}}
&subject_token={{OKTA_ID_TOKEN}}
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&client_id={{REQUESTING_APP_CLIENT_ID_IN_OKTA}}
&client_secret={{REQUESTING_APP_CLIENT_SECRET_IN_OKTA}}

Parámetro	Descripción
grant_type	El tipo de concesión. Configúrelo con el tipo de concesión de intercambio de tokens: urn:ietf:params:oauth:grant-type:token-exchange.
requested_token_type	El tipo de token que el cliente quiere recibir del servidor de autorización. Configúrelo como Identity Assertion Authorization Grant, o ID-JAG: urn:ietf:params:oauth:token-type:id-jag.
audience	El destinatario previsto del token final. Configúrelo con la URL del emisor de su inquilino de Auth0, o con su aplicación de recursos cuyo servidor de autorización se encuentra en esa URL específica.
resource	Opcional. La API de la aplicación de recursos a la que el cliente quiere acceder. Cuando el servidor de autorización emite el token de acceso final, incluye este recurso en el claim aud del token, que la API de la aplicación de recursos usará para validarlo. Si no especifica un parámetro resource, se usará la audiencia predeterminada que configuró para su inquilino en la siguiente solicitud para obtener un token de acceso. Si especifica un resource que no coincide con una audiencia de API válida en su inquilino de Auth0, la solicitud de intercambio de tokens no falla y aun así recibirá un ID-JAG como respuesta. Sin embargo, la solicitud posterior para obtener un token de acceso con el ID-JAG será rechazada por su inquilino de Auth0.
subject_token	El token que el cliente está intercambiando. Para XAA, el token de sujeto es la “prueba” o “afirmación” de la identidad del usuario. Configúrelo con el token de ID de Okta que el IdP usará para verificar la identidad del usuario.
subject_token_type	El tipo de token proporcionado en el parámetro subject_token. Para XAA, especifica que se está presentando un token de ID al servidor de autorización.
client_id	El ID de cliente de la aplicación solicitante dentro del IdP empresarial que realiza la solicitud de intercambio de tokens.
client_secret	El secreto del cliente que usa esa aplicación solicitante para autenticarse ante el IdP empresarial.

La Beta de XAA no admite pasar alcances al endpoint /token de Okta. Puede establecer los alcances en la siguiente solicitud al endpoint /token de Auth0 una vez que la aplicación solicitante reciba el ID-JAG.

En un entorno de producción, la aplicación solicitante realiza la solicitud de intercambio de tokens al endpoint /token del inquilino de Okta de su cliente.

​

Envíe el ID-JAG al endpoint /token de Auth0

Una vez que la aplicación solicitante obtiene un ID-JAG, envía una solicitud de token de acceso al endpoint /token de su inquilino de Auth0:

POST https://{{YOUR_AUTH0_TENANT_DOMAIN}}/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id={{REQUESTING_APP_CLIENT_ID_IN_AUTH0}}
&client_secret={{REQUESTING_APP_CLIENT_SECRET_IN_AUTH0}}
&scope=scope1%20scope2%20
&assertion={{ID_JAG}}

Parámetro	Descripción
grant_type	El tipo de concesión. Indica al Servidor de autorización que espere un JSON Web Token (JWT) como credencial principal en la solicitud.
client_id	El ID de cliente de la aplicación solicitante en el Servidor de autorización de la aplicación de recursos que realiza la llamada a la API.
client_secret	El secreto del cliente de la aplicación solicitante en el Servidor de autorización de la aplicación de recursos que realiza la llamada a la API.
scope	El conjunto de permisos que la aplicación solicitante solicita para el token de acceso.
assertion	El ID-JAG o JSON Web Token (JWT) que actúa como portador de la aserción de identidad.

Después de que el Servidor de autorización de Auth0 valida el ID-JAG para verificar la identidad del usuario, emite un token de acceso para acceder a la audiencia de la API de destino de tu inquilino de Auth0. El token de acceso también incluye los alcances solicitados que están permitidos por RBAC y otras políticas configuradas en tu inquilino de Auth0.

El Servidor de autorización de Auth0 no emite tokens de actualización en respuesta a intercambios de tokens ID-JAG. Como resultado, la aplicación solicitante debe obtener un nuevo ID-JAG del IdP empresarial y pasar por los controles de acceso aplicables para obtener un nuevo token de acceso mediante XAA.