Tokens de actualización con OIDC

Obtén información sobre cómo la canalización conforme a OIDC afecta el uso de los tokens de actualización.

Con la canalización conforme a OIDC, los tokens de actualización:

• Ya no se devolverán cuando se use el flujo implícito para la autenticación.
• Se pueden usar con aplicaciones confidenciales.
• Las aplicaciones públicas pueden usarlos con la rotación de tokens de actualización cuando se utiliza el flujo de código de autorización con PKCE.
• Deben usar el endpoint /oauth/token para obtener nuevos tokens, ya que el endpoint /delegation está obsoleto.

Además, hay diferencias en la estructura del token de actualización. Para obtener más información, consulta Tokens de actualización.

​

Legado (delegación)

POST /delegation
Content-Type: 'application/json'
{
  "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
  "client_id": "...",
  "refresh_token": "...",
  "scope": "openid profile"
}

​

conforme a OIDC (endpoint de token)

POST /oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=123&client_id=123&client_secret=123&scope=openid+profile&audience=https%3A%2F%2Fapi.example.com

• Los parámetros audience y client_secret son opcionales.
• client_secret no es necesario para solicitar un refresh_token en una aplicación pública.

Los Tokens de actualización deben mantenerse confidenciales durante la transmisión y el almacenamiento, y solo deben compartirse entre el Servidor de autorización y el cliente al que se emitieron.

​

Más información

• Tokens de acceso con OIDC
• APIs externas con OIDC
• Flujo de código de autorización con OIDC
• Flujo de credenciales del cliente con OIDC
• Delegación con OIDC
• Flujo implícito con OIDC