IdentityServer4. Conceptos básicos. Conexión OpenID, OAuth 2.0 y JWT

Con este post quiero abrir un hilo de artículos dedicados a IdentityServer4. Empecemos por los conceptos básicos.

El protocolo de autenticación más prometedor en este momento es OpenID Connect, y el protocolo de autorización (que proporciona acceso) es OAuth 2.0. Servidor de identidad4 implementa estos dos protocolos. Está optimizado para resolver problemas típicos seguridad

OpenID Connect es un protocolo y estándar de autenticación, no proporciona acceso a recursos (API web), pero desde está diseñado sobre el protocolo de autorización OAuth 2.0, le permite obtener parámetros de perfil de usuario como si tuviera acceso al recurso UserInfo.

JWT (JSON Web Token) es un estándar web que define una forma de transmitir datos de usuario en formato JSON de forma cifrada.

OAuth 2.0 (RFC 6749) es un protocolo y estándar de autorización. Permite que las aplicaciones accedan a recursos protegidos, como las API web.

Echemos un vistazo al diagrama de acceso a un recurso protegido y comprendamos los pasos principales y la terminología aceptada:

1. El cliente solicita permiso al usuario para autenticarse en su nombre. Cliente es una aplicación cliente que accede a recursos protegidos en nombre del propietario del recurso. recurso - estos son todos nuestros servicios protegidos API web.

2. El usuario permite que la aplicación cliente se autentique en su nombre, por ejemplo, ingresando un nombre de usuario y contraseña. El nombre de usuario y la contraseña constituirán una concesión de autorización para la aplicación del cliente. Usuario (propietario del recurso) — un programa o persona que puede otorgar acceso a recursos protegidos, por ejemplo, ingresando un nombre de usuario (nombre de usuario) y una contraseña (contraseña);

3. La aplicación cliente solicita un token de acceso de IdentityServer4 proporcionando información sobre usted mismo (client_id, client_secret), otorgando permiso de autorización por parte del usuario (username, password) y proporcionando grant_type и scope. Luego, el servidor de autorización verifica la autenticidad del cliente y los detalles del propietario del recurso (nombre de usuario y contraseña).

   El protocolo OAuth 2.0 autentica no solo al usuario, sino también a la aplicación cliente que accede a los recursos. Para ello, el protocolo proporciona parámetros tales como client_id и client_secret.
   Identificación del cliente ¿Se utiliza el identificador de la aplicación cliente? IdentityServer4 para buscar información sobre el cliente.
   client_secret Es análoga a una contraseña para una aplicación cliente y se utiliza para autenticar la aplicación cliente en IdentityServer4. El secreto del cliente solo debe ser conocido por la aplicación y la API.. Con base en lo anterior, concluimos que IdentityServer4 necesita saber acerca de sus clientes.

4. Si la aplicación está autenticada y el permiso de autorización es válido, IdentiryServer4 crea access-токен (token de acceso) para la aplicación y una clave de actualización opcional (refresh-токен). Se completa el proceso de autorización. Si la solicitud no es válida o no está autorizada, el servidor de autorización devuelve un código con un mensaje de error apropiado.

5. La aplicación cliente accede a una API web segura para obtener datos y proporciona un token de acceso para la autorización. Si el código de respuesta del servidor de recursos 401, 403 o 498, entonces el token de acceso utilizado para la autenticación no es válido o ha caducado.

6. Si el token es válido, Web API proporciona datos a la aplicación.

Tipos de tokens

Registrado en IdentityServer4 los clientes pueden solicitar IdentityServer4 identity-simbólico, access-token y refresh-simbólico.

• token de identidad (token de identificación) — el resultado del proceso de autenticación. Contiene el ID de usuario e información sobre cómo y cuándo se autentica el usuario. Puedes ampliarlo con tus propios datos.
• token de acceso — se transmite a una API protegida y esta la utiliza para autorizar (permitir el acceso) a sus datos.
• token de actualización (token de actualización) es un parámetro opcional que el servidor de autorización puede devolver en respuesta a una solicitud de token de acceso.

Introduzcamos dos conceptos más:

URL del servidor de autenticación — punto final para obtener una clave de acceso. Dirigiremos todas las solicitudes de provisión y renovación de claves de acceso a esta URL.

URL del recurso — La URL del recurso protegido con el que se debe contactar para acceder al mismo, pasándole la clave de acceso en el encabezado de autorización.

Solicitud de clave de acceso

Para solicitar una clave de acceso, el cliente debe POST solicitud al punto final IdentityServer4 con el siguiente encabezado

'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'

y pasando los siguientes parámetros:

'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'

username, password, client_id и client_secret fueron discutidos anteriormente. Veamos los parámetros restantes:

subvención_tipo — tipo de concesión o tipo de autorización. El tipo de permiso de autorización depende del método de solicitud de autorización utilizado por la aplicación, así como de los tipos de permiso admitidos por la API. En nuestro caso importará password, que está de acuerdo con la especificación OAuth 2.0 Corresponde a la concesión de datos de acceso del propietario del recurso (autorización mediante login y contraseña).

Protocolo OAuth 2.0 define los siguientes tipos de subvenciones que requieren interacción obligatoria con los usuarios:

• Código de Autorización. Es uno de los tipos de permiso de autorización más comunes, porque muy adecuado para aplicaciones del lado del servidor, donde el código fuente de la aplicación y el secreto del cliente no son accesibles para personas externas;
• implícito. El tipo de permiso de autorización implícita lo utilizan aplicaciones móviles y web donde no se puede garantizar la confidencialidad del secreto del cliente;

Y los tipos de subvenciones que se puede ejecutar sin interacción del usuario:

• detalles del propietario del recurso. Este tipo de permiso debe usarse solo si el usuario confía en la aplicación cliente y si se siente cómodo ingresando su nombre de usuario y contraseña. Este tipo de permiso solo debe usarse cuando no haya otras opciones disponibles. Este tipo de permiso es conveniente para clientes corporativos que ya han utilizado credenciales de usuario dentro de su sistema y desean cambiar a OAuth 2.0.
• credenciales del cliente. Se utiliza cuando la aplicación accede a la API. Esto puede resultar útil, por ejemplo, cuando una aplicación desea actualizar su propia información de registro de servicio o redirigir el URI, o acceder a otra información almacenada en la cuenta de servicio de la aplicación a través de la API del servicio.

global - Este es un parámetro opcional. Define el alcance. El token de acceso devuelto por el servidor solo proporcionará acceso a aquellos servicios que se encuentren dentro de ese alcance. Aquellos. Podemos combinar varios servicios bajo un alcance y si el cliente recibe una clave de acceso a este alcance, obtiene acceso a todos estos servicios. El alcance también se puede utilizar para limitar los derechos de autorización (por ejemplo, acceso de lectura o escritura)

Fuente: habr.com