En los dos artículos anteriores, presentamos el código de autorización OIDC y el modo PKCE mejorado por el código de autorización. Esta vez nos centraremos en el modo (Credenciales de cliente). El modo Credenciales de cliente es uno de los modos de autorización de OIDC. Una autenticación y modo de autorización en el que el cliente (aplicación) obtiene un token de acceso (token de acceso) del servidor OIDC en su propio nombre, y se usa a menudo para proteger API o escenarios de IoT.
[ Authing es el único producto de nube de identidad de escenario completo centrado en el desarrollador en China, que proporciona más de 1000 API y SDK de todos los lenguajes principales, y tiene una comunidad ecológica de cientos de miles de desarrolladores. 】
01. Credenciales del cliente
El modo Credenciales de cliente se utiliza para la autorización de servidor a servidor (autorización M2M) sin la participación del usuario. Debe crear una cuenta de acceso a la programación por adelantado y entregar el par de claves AK y SK a la persona que llama. Cabe señalar que cada proveedor implementa esto de manera diferente. Por ejemplo, la implementación de Credenciales de cliente por parte de Okta y Auth0 es para use Client La identificación y el secreto del cliente se entregan a la persona que llama, y Authing es para crear una cuenta de acceso programático en la aplicación y entregar el AK/SK a la persona que llama. No hay diferencia en el uso de la persona que llama. The Authing El método es más adecuado para múltiples La persona que llama administra.
⚠️ El modo Credenciales de cliente no admite Refresh Token.
En general, existen los siguientes procesos:
1. La persona que llama al recurso envía sus credenciales AK, SK y el alcance del permiso que se solicitará al punto final de autorización de autenticación.
2. Si las credenciales son correctas y la persona que llama tiene permisos de recursos, Authing emite un AccessToken para ello.
3. La persona que llama lleva el access_token para solicitar el servidor de recursos.
4. Después de que el servidor de recursos verifique que el token pasa, devuelve los recursos relevantes.
El diagrama de flujo es el siguiente:
1.1 Prepárese para conectarse
1.1.1 Crear una aplicación y configurarla en Authing
Como de costumbre, primero debe crear una aplicación en Authing.
Configurar el modo de autorización
Crear una cuenta de acceso programático y dársela a la persona que llama a la API
1.1.2 Definir autoridad en Auhing y autorizar cuenta AK SK
Nota: Durante la autenticación del usuario, el alcance corresponde a la información del usuario, y cuando AK/SK obtiene el token, el alcance debe corresponder al permiso de API autorizado.
1.1.2.1 Especificación de permiso de alcance
Los elementos de permiso de alcance de Authing están separados por espacios, y el formato de cada elemento es
recurso:recurso-identificador:recurso-operación
recurso: identificador de recurso: operación de recurso.
Los siguientes son todos los formatos de alcance admitidos por Authing:
1. El significado es el permiso de lectura del recurso del libro numerado 1
book:1:read
2. El significado es el permiso de lectura de todos los recursos del libro.
book:*:read
3. El significado es el permiso de lectura de todos los recursos del libro.
book:read
4. El significado es todos los permisos de operación de todos los recursos del libro.
book:*:*
5. El significado es todos los permisos de operación de todos los recursos del libro.
book:*
6. El significado es todos los permisos de operación de todos los recursos del libro.
book:
7. Significa todos los permisos de operación de todos los recursos.
*:*:*
8. Significa todos los permisos de operación de todos los recursos.
*:*
9. Significa todos los permisos de operación de todos los recursos
*
1.1.2.2 Definir recursos relacionados en la gestión de autoridad de autenticación
Definimos el recurso libro:
1.1.2.3 Autorizar cuentas de acceso programático
Aquí autorizamos a la persona que llama A de la cuenta de acceso a la programación recién creada, lo que permite que la persona que llama A acceda a la API /book con una solicitud GET, y solo puede obtener la orden con ID 20150
1.2 Prueba de acceso
1.2.1 Lista de interfaces de llamada requeridas
POST${host}/oidc/token 获取 Token
POST${host}/oidc/token/introspection 校验 Token
POST${host}/oidc/revocation 吊销 Token
1.2.2 Ejecutar en Postman
La interfaz que se presentará a continuación se puede experimentar con bifurcación a través de nuestra colección de cartero en línea
1.2.3 Obtener token
POST${host}/oidc/token
Después de que el usuario complete la operación de inicio de sesión en el lado de Authing, Authing devolverá el código generado como un parámetro a la dirección redirect_uri. En este momento, el token de acceso access_token correspondiente se puede obtener a través de la interfaz de código por token.
Solicitud de ejemplo :
curl --location 'https://{host}/oidc/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={AccessKey}' \
--data-urlencode 'client_secret={SecretKey}' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=book:20150:GET book:20150:POST'
Ejemplo de respuesta (éxito) :
{
"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Il9xcEhRQXFvbXd0Z3BKX2xZVHNtN2FMVEU3YUtJb0tQeFN5by1faDdGUVkifQ.eyJhenAiOiI2M2Y0ODA5OTlkNGY0MDRiZTViNDQ0NGEiLCJhdWQiOiI2M2Y0ODI1ZDhhNWRmNjYyNTU4YjI4MTQiLCJzY29wZSI6ImJvb2s6MjAxNTA6R0VUIiwiaWF0IjoxNjgxNzExNDU2LCJleHAiOjE2ODE3MTIwNTYsImp0aSI6IlBiSks5djNFTS1rS1o3bms4VmdBRms3eVVPRzJES2NwYUQ2M2gxaThmVlkiLCJpc3MiOiJodHRwczovL29pZGMtY2xpZW50LWNyZWRlbnRpYWxzLmF1dGhpbmcuY24vb2lkYyJ9.qPcJU84C9Ztjm5dk-im8ntatPaB5P8j3ZPdW1eoi-V5po8k32jexUemSEHInEfqdxcnY7OyR1pph6JVjehmoCAX6gqA_3fv20hUjnWQNqcZegAiNea4jQbLKlMsYnTQhhJWmzhs64LwCJD1RqQy0VtoL2ZVVfAEpySHWL6TwWVz0AkvQpZbzkF6FRCa03rli_jc1BNtpGUhvNdtGs6xJMMLJZ31dptrLlSSWSQ71t05fqBfEiToN6-JkwKXJedpHBvFWt_-XncQbksdQQc6krTcgaWkrIbv6LblTrtAifXLfOsANweOAG8QoKLh55vSMMBXdzdw-IzXeCDuwQT5P2w",
"token_type":"Bearer",
"expires_in":600,
"scope":"book:20150:GET",
"rejected_scope":"book:20150:POST"
}
Aquí scope es el recurso al que la cuenta de acceso debería permitir el acceso, y disabled_scope es el permiso que solicitamos pero fue rechazado. Acabamos de asignar el permiso book:20150:GET a la persona que llama A, por lo que solicitamos book: 20150: al mismo tiempo. Permisos GET y book:20150:POST, el permiso book:20150:POST será rechazado y la persona que llama puede usar el token para llamar a la API protegida después de obtener access_token.
Ejemplo de respuesta (fallido) :
{
"error": "server_error",
"error_description": "编程访问账号不存在！"
}
1.2.4 Verificar token
POST${host}/oidc/token/introspection
Después de que el servidor de la API recibe la solicitud de llamada de la interfaz, puede llamar a esta interfaz para verificar la validez del access_token y si tiene permiso para llamar a la API correspondiente.
Este punto final acepta access_token, id_token, refresh_token y devuelve un valor booleano que indica si está activo o no. Si el token está activo, también se devolverán datos adicionales sobre el token. Un token se considera inactivo si no es válido, está caducado o revocado.
access_token se puede firmar con el algoritmo de firma RS256 o el algoritmo de firma HS256. Aquí está la diferencia entre los dos algoritmos de firma:
RS256 es un algoritmo de firma digital que utiliza el algoritmo RSA, que utiliza un par de claves pública/privada para cifrar y verificar la información. Los tokens generados con firmas RS256 son más seguros que los tokens generados con firmas HS256 porque firmar con un par de claves RSA proporciona un mayor nivel de protección. Los tokens que usan el algoritmo de firma RS256 se pueden verificar usando la clave pública, que se puede obtener a través del punto final JWK.
HS256 es un algoritmo de firma digital que utiliza una clave simétrica. Utiliza la misma clave para firmar y verificar. El algoritmo de firma HS256 tiene un rendimiento más rápido que el algoritmo de firma RS256 porque utiliza una clave simétrica en lugar de un par de claves pública/privada RSA para la firma y verificación. Los tokens que utilizan el algoritmo de firma HS256 se pueden verificar mediante un secreto compartido (clave de aplicación).
En aplicaciones prácticas, el algoritmo RS256 es más seguro, pero también consume más recursos.Si el sistema requiere un alto rendimiento, puede elegir el algoritmo de firma HS256. Verificación en línea :
Parámetros de la solicitud :
Solicitud de ejemplo :
curl --location --request POST 'https://{host}/oidc/token/introspection' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={应用ID}' \
--data-urlencode 'client_secret={应用密钥}' \
--data-urlencode 'token={ token }' \
--data-urlencode 'token_type_hint=access_token'
Ejemplo de respuesta de verificación access_token (verificación aprobada)
{
"active": true,
"aud": "63f4825d8a5df662558b2814",
"client_id": "63f480999d4f404be5b4444a",
"exp": 1681713127,
"iat": 1681712527,
"iss": "https://oidc-client-credentials.authing.cn/oidc",
"jti": "EpveFqLsgskNIre8fK-h0AOK6oBIfZH6erT5iSrRKmd",
"scope": "book:20150:GET",
"token_type": "Bearer"
}
Ejemplo de respuesta de verificación access_token (verificación fallida):
{
"active": false
}
1.2.5 Retirar token
POST${host}/oidc/token/revocation
El servicio API puede revocar el access_token de la persona que llama a través de esta interfaz.
Parámetros de la solicitud :
Solicitud de ejemplo :
curl --location --request POST 'https://{host}/oidc/token/revocation' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={应用ID}' \
--data-urlencode 'client_secret={应用密钥}' \
--data-urlencode 'token= {token}' \
--data-urlencode 'token_type_hint=access_token'
Ejemplo de respuesta (éxito) :
HTTP 200 OK
Ejemplo de respuesta (fallido) :
{
"error": "xxxx","error_description": "xxxx"
}
02. Resumen de este capítulo
En este capítulo, presentamos el uso del modo Credenciales de cliente para proteger las API.Hasta ahora, hemos presentado los modos de autorización de OIDC comúnmente utilizados.
[Authing es el único producto de nube de identidad de escenario completo centrado en el desarrollador en China, que proporciona más de 1000 API y SDK de todos los lenguajes principales, con una comunidad ecológica de cientos de miles de desarrolladores. 】
El siguiente es el catálogo de artículos de la serie de mejores prácticas del protocolo de autenticación OIDC y OAuth2.0, haga clic en el enlace para ver el texto original:
Editado el 2023-04-27 11:45