validate userinfoclient introspectionclient identityserver endsession oauth-2.0 openid thinktecture-ident-server openid-connect identityserver3

oauth-2.0 - introspectionclient - userinfoclient



IdentityServer Flows (4)

IdentityServer admite diferentes flujos de OpenId Connect definidos en la enumeración de Flows y configurados para clientes. También hay muestras para cada tipo de flujo y muchas referencias a ellos en los documentos, pero no pude encontrar una lista de definición simple de qué flujos están en la documentation como si fueran demasiado obvios para explicar en palabras. Pero supongo que no lo son. ¿Puede contarnos más sobre las diferencias de estos, tal vez podamos agregar eso a los documentos?

Entonces, ¿qué son: flujo implícito , flujo de credenciales de contraseña del propietario del recurso , flujo de código de autorización, flujo de credenciales de cliente , flujo de concesión personalizado y flujo híbrido ? ¿Cuáles son los flujos de OAuth y cuáles son los flujos de OpenID Connect?

¡Gracias!

Los flujos definidos en OAuth2 son solo varias formas para que un cliente reciba un access token de un servidor de proveedor de identidad; IdentityServer en este caso. Comprender los flujos no será fácil a menos que comprenda completamente las entidades especificadas en los diagramas de flujo , como el Resource Owner , el User Agent y el Resource Server . Aquí hay algunas explicaciones breves sobre estas entidades (roles, preciosamente).

Flujo de código de autorización : emite un authorization code antes de emitir un access token .

  • Un cliente solicita un authorization code.
  • IdentityServer Valida al cliente y le pide al propietario del recurso que otorgue la autorización para emitir un authorization code .
  • Luego, el cliente solicita un access token con el authorization code proporcionado
  • El servidor de autorización emite un access token directamente al cliente.

Flujo de código implícito : emite un access token incluso sin authorization code proporcionado.

  • Un cliente solicita un access token directamente.
  • IdentityServer omite validar al cliente (en algunos escenarios, lo hace parcialmente) pero aún así le pide al propietario del recurso que otorgue la autorización para emitir un access token
  • Este flujo nunca emite un authorization code .

El flujo implícito se considera el flujo ideal para un cliente que usa lenguajes de script como javascript ya que el cliente no tiene que solicitar un authorization code y un access token separado, lo que a su vez reduce un viaje de ida y vuelta de red para el cliente.

Flujo de credenciales del cliente : emite un access token sin el permiso del propietario del recurso.

  • Un cliente solicita un token de acceso directamente.
  • IdentityServer valida al cliente y emite un access token inmediato.

Esto es ideal cuando el cliente también es propietario de un recurso, por lo que no necesita ningún permiso de autorización hasta el access token .

Flujo del propietario del recurso : emite un access token si un cliente tiene las credenciales del propietario del recurso (por ejemplo, Id / Contraseña)

  • Un cliente solicita un access token directamente.
  • IdentityServer valida al cliente y verifica la identidad del propietario del recurso.
  • Si es válido, el cliente obtiene el access token instante.

Este flujo es ideal para los clientes que crees que es absolutamente seguro compartir con ellos los identificadores y las contraseñas.

Flujo híbrido (flujo OIDC) : emite un authorization code y un access token .

Esta es una combinación de Authorization code flow de Authorization code flow y Implicit code flow . Por eso se llama Hybrid .

Flujo personalizado

Este es literalmente un flujo personalizable. Esto se puede usar cuando necesita un proceso de autenticación / validación específico en su negocio además de todas las especificaciones de protocolo en OAuth2 .

IdentityServer es muy consciente de este tipo de situación y admite extensibilidades por diseño. El patrón de fábrica, el patrón de decorador y IoC / DI le facilitarán la implementación de funciones adicionales en su IdentityServer .

Desde el primer enlace de privilegio: y OAuth 2 de Aharon Paretzki simplificado

Los flujos deciden cómo se devuelven al cliente el token de ID (es decir, el código de autorización) y el token de acceso (es decir, ''el token''):

Flujo de código de autorización : flujo OAuth 2.0 en el que

  • se devuelve un código de autorización desde el punto final de autorización
  • y todos los tokens (como segunda etapa, a cambio del código de autorización) se devuelven desde el Punto final del token
  • Se utiliza para llamadas basadas en servidor (API) que pueden mantener la confidencialidad de su secreto de cliente. Permite una mayor seguridad, siempre y cuando nadie pueda acceder al "secreto del cliente".

Flujo implícito : flujo OAuth 2.0 en el que

  • todos los tokens se devuelven directamente desde el punto final de autorización
  • y no se utilizan ni el token Endpoint ni un código de autorización.
  • Se utiliza para aplicaciones móviles y basadas en web, que no pueden mantener la confidencialidad del secreto del cliente, por lo que es necesario que el token sea emitido por el servidor de autenticación. Esto es menos seguro y se recomienda que el servidor se configure para denegar llamadas de flujo implícito para el uso de API y permitirlo solo para las aplicaciones basadas en navegador y móviles.

Flujo híbrido : flujo OAuth 2.0 en el que

  • se devuelve un Código de autorización desde el Punto final de autorización,
  • algunos tokens se devuelven directamente desde el Punto final de autorización y otros se devuelven (como segunda etapa, a cambio del código de autorización) desde el Punto final de token.
  • Se usa donde se necesitan ambos flujos.