Saltar al contenido principal
Tradicionalmente, las aplicaciones que no podían almacenar secretos de forma segura usaban el Flujo implícito. El uso de este flujo ya no se considera una práctica recomendada para solicitar ; las implementaciones nuevas deben usar el Flujo de código de autorización con PKCE. Sin embargo, cuando se usa con el modo de respuesta Form Post, el Flujo implícito sí ofrece un flujo de trabajo más ágil si la aplicación solo necesita un para autenticar al usuario; en estos casos, se usaría como parte del Flujo híbrido. ya no se devolverán al usar el Flujo implícito para la autenticación. Además, el proceso compatible con OIDC afecta al Flujo implícito en las siguientes áreas: solicitud de autenticación, respuesta de autenticación, estructura del token de ID y estructura del token de acceso.

​
Solicitud de autenticación

​
Legado

GET /authorize?
    response_type=token
    &scope=openid email favorite_color offline_access
    &client_id=123
    &state=af0ifjsldkj
    &redirect_uri=https://app.example.com
    &device=my-device-name
El parámetro device solo es necesario si solicita un Token de actualización al incluir el scope offline_access. Para obtener más información, consulte token de actualización.

​
Conforme a OIDC

GET /authorize?
    response_type=token id_token
    &scope=openid email
    &client_id=123
    &state=af0ifjsldkj
    &nonce=jxdlsjfi0fa
    &redirect_uri=https://app.example.com
    &audience=https://api.example.com

​
Respuesta de autenticación

​
Legado

HTTP/1.1 302 Found
Location: https://app.example.com/#
    access_token=SlAV32hkKG
    &expires_in=86400
    &state=af0ifjsldk
    &id_token=eyJ...
    &refresh_token=8xLOxBtZp8
    &token_type=Bearer
  • El token de acceso devuelto es válido para llamar al endpoint /userinfo.
  • Solo se devolverá un token de actualización si se pasó el parámetro device y se solicitó el scope offline_access.

​
Conforme a OIDC

HTTP/1.1 302 Found
Location: https://app.example.com/#
    access_token=eyJ...
    &expires_in=86400
    &state=af0ifjsldk
    &id_token=eyJ...
    &token_type=Bearer
  • El token de acceso devuelto es válido para llamar al endpoint /userinfo (siempre y cuando la API especificada por el parámetro audience use RS256 como algoritmo de firma) y, opcionalmente, al especificado por el parámetro audience.
  • Si usa response_type=id_token, Auth0 solo devolverá un token de ID. Los tokens de actualización no están permitidos en el grant implícito. Use prompt=none en su lugar.

​
Estructura del token de ID

​
legado

​
Conforme a OIDC

  • La claim favorite_color debe tener un espacio de nombres y agregarse mediante una Rule. Para obtener más información, consulta Crear claims personalizadas con espacio de nombres.
  • Después de validar el token de ID, la aplicación debe validar el para mitigar ataques de repetición.

​
Estructura del token de acceso (opcional)

​
legado

HTTP
SlAV32hkKG
El Token de acceso devuelto es opaco y solo es válido para llamar al endpoint /userinfo.

​
Conforme a OIDC

  • El token de acceso devuelto es un válido para llamar al endpoint /userinfo (siempre que la API especificada por el parámetro audience use RS256 como algoritmo de firma), así como al servidor de recursos especificado por el parámetro audience.
  • Aún podría devolverse un token de acceso opaco si /userinfo es la única especificada.

​
Más información