Con este post, quiero abrir una serie de artículos dedicados a IdentityServer4. Comenzaremos con los conceptos básicos.
El protocolo de autenticación más prometedor en la actualidad es , y el protocolo de autorización (provisión de acceso) es . implementa estos dos protocolos. Está optimizado para resolver problemas típicos de seguridad.
— es un protocolo y estándar de autenticación, no otorga acceso a recursos (Web API), pero dado que está diseñado sobre un protocolo de autorización , permite obtener los parámetros del perfil del usuario como si hubieras accedido al recurso .
(JSON Web Token) es un estándar web que define la forma de transmitir datos del usuario en formato JSON de manera encriptada.
— es un protocolo y estándar de autorización. Permite a las aplicaciones acceder a recursos protegidos, como Web API.
Veamos el diagrama de acceso a un recurso protegido y analicemos los pasos principales y la terminología adoptada:
El cliente solicita al usuario permiso para autorizar en su nombre. Cliente — es la aplicación cliente que accede a los recursos protegidos en nombre del propietario de los recursos. El recurso — son todos nuestros servicios protegidos .
El usuario permite a la aplicación cliente autorizar en su nombre, por ejemplo, ingresando su nombre de usuario y contraseña. El nombre de usuario y la contraseña servirán como el grant de autorización para la aplicación cliente. User (propietario de recursos) — es el programa o persona que puede otorgar acceso a recursos protegidos, por ejemplo, ingresando el nombre de usuario (username) y la contraseña (password);
La aplicación cliente solicita un token de acceso a
IdentityServer4proporcionando información sobre sí misma (client_id,client_secret), otorgando permiso de autorización por parte del usuario (username,password) y presentandogrant_typeyscope. Luego, el servidor de autorización verifica la autenticidad del cliente y las credenciales del propietario de recursos (nombre de usuario y contraseña).El protocolo OAuth 2.0 no solo autentica al usuario, sino también a la aplicación cliente que accede a los recursos. Para ello, el protocolo contempla parámetros como client_id y client_secret.
client_id — es el identificador de la aplicación cliente utilizadoIdentityServer4para buscar información sobre el cliente.
client_secret es un equivalente de la contraseña para la aplicación cliente y se utiliza para autenticar la aplicación cliente enIdentityServer4. el secreto del cliente debe ser conocido solo por la aplicación y la API. A partir de lo anterior, concluimos que IdentityServer4 debe conocer a sus clientes.Si la autenticidad de la aplicación se confirma y el permiso de autorización es válido,
IdentiryServer4creaun token de accesopara la aplicación y un token de actualización opcional (refresh-token). El proceso de autorización ha finalizado. Si la solicitud es inválida o no autorizada, el servidor de autorización devuelve un código con el mensaje de error correspondiente.La aplicación cliente solicita datos a la API web protegida, proporcionando el token de acceso para la autorización. Si el código de respuesta del servidor de recursos , o , el token de acceso utilizado para la autenticación es inválido o ha expirado.
Si el token es válido,
Web APIproporciona los datos a la aplicación.
Tipos de tokens
Se permite a los clientes registrados solicitar IdentityServer4 identity IdentityServer4 -token,access -token yrefresh -token.identity-token (token de identificación)
- es el resultado del proceso de autenticación. Contiene el identificador del usuario y la información sobre cómo y cuándo el usuario se autentica. Se puede ampliar con datos propios. access-token (token de acceso)
- se transmite a la API protegida y se utiliza para autorizar (dar acceso) a sus datos. refresh-token (token de actualización)
- es un parámetro opcional que el servidor de autorización puede devolver en respuesta a la solicitud del token de acceso. Introduzcamos otros dos conceptos:
Authenticatation Server Url
es el punto final para obtener el token de acceso. Todas las solicitudes para otorgar y renovar los tokens de acceso se dirigirán a esta URL. Resource Url
es la URL del recurso protegido al que se debe acceder, pasando el token de acceso en el encabezado de autorización. Solicitud del token de acceso
Para solicitar el token de acceso, el cliente realiza
una solicitud al punto final POST con el siguiente encabezado IdentityServer4 '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}'
fueron discutidos anteriormente. Revisemos los demás parámetros:username, password, client_id y client_secret были разобраны выше. Разберём остальные параметры:
grant_type — tipo de concesión o tipo de autorización. El tipo de autorización depende del método de solicitud de autorización utilizado por la aplicación, así como de los tipos de autorización admitidos por la API. En nuestro caso, tendrá el valor password, que según la especificación OAuth 2.0 corresponde a la concesión de credenciales de acceso del propietario del recurso (autenticación por nombre de usuario y contraseña).
Protocolo OAuth 2.0 define los siguientes tipos de concesiones que requieren interacción obligatoria con los usuarios:
- código de autorización (authorization code). Es uno de los tipos de autorización más comunes, ya que se adapta bien a aplicaciones del lado del servidor (server-side applications), donde el código fuente de la aplicación y el secreto del cliente no están disponibles para terceros;
- implícito (implicit). El tipo de autorización implícito se utiliza en aplicaciones móviles y web, donde la privacidad del secreto del cliente no puede garantizarse;
Y los tipos de autorizaciones que se pueden llevar a cabo sin interacción interactiva con los usuarios:
- credenciales del propietario del recurso (resource owner). Este tipo de autorización debe usarse solo cuando la aplicación cliente goza de la confianza del usuario y el usuario está cómodo ingresando su nombre de usuario y contraseña. Este tipo de autorización debe usarse solo cuando no hay otras opciones disponibles. Este tipo de autorización es conveniente para clientes empresariales que ya han utilizado las credenciales del usuario dentro de su sistema y desean pasar a
OAuth 2.0. - credenciales del cliente. Se utilizan cuando la aplicación accede a la API. Esto puede ser útil, por ejemplo, cuando la aplicación desea actualizar su propia información de registro en el servicio o URI de redirección, o acceder a otra información almacenada en la cuenta de la aplicación en el servicio a través de la API del servicio.
scope — es un parámetro opcional. Define el ámbito de visibilidad. El token de acceso devuelto por el servidor proporcionará acceso solo a los servicios que entren en este ámbito. Es decir, podemos combinar varios servicios bajo un mismo ámbito y si el cliente obtiene una clave de acceso a este ámbito, obtiene acceso a todos estos servicios. Además, el ámbito puede ser utilizado para restringir los derechos de autorización (por ejemplo, acceso de lectura o escritura).
Fuente: habr.com
