Arquitectura de autenticación basada en mecanismo de token

Hay dos tipos de autenticación comunes, uno basado en sesión y el otro basado en token, hablemos de la diferencia entre estos dos tipos de autenticación.

Sesión

Token

Actualmente existen dos estándares de autorización comúnmente utilizados en la industria. Uno es usar auth2, que es más adecuado para terceros similares. inicios de sesión autorizados, como los servicios de inicio de sesión confiables de WeChat, Weibo y QQ. El otro es oauth, lo que significa que terceros pueden solicitar autorización para obtener recursos sin conocer el usuario y la contraseña. Es más adecuado para la verificación de permisos de usuario y la asignación de permisos de acceso, como los sitios web de inicio de sesión comunes que asignan recursos visibles (botones, menús). , etc.).

El sistema de comercio electrónico Javashop utiliza el método oauth para implementar el estándar de autenticación. Introduzcamos el esquema oauth usando una aplicación del sistema como ejemplo.

1. Inicie sesión

El servidor verifica la contraseña y devuelve access_token y refresco_token después del éxito. El cliente registra el token anterior. Accediendo a la API

Antes de acceder a la API, analice el token de acceso y verifique si ha caducado. Si no ha caducado, solicite la API. Si no ha caducado, el cliente registra el token.

3. Token de actualización

Lleve un token de actualización con una fecha de vencimiento y reemplácelo con un token válido. Si el token de actualización caduca, el usuario debe iniciar sesión nuevamente.

4. Cerrar sesión

Para solicitar una API de cierre de sesión, tanto el servidor como el cliente deben eliminar el almacén de tokens.

1. La API solicitada por el cliente

lleva información de access_token. Si el entorno de generación no lleva access_token directamente, se utilizará la verificación de firma cifrada. Vea el mecanismo anti-repetición a continuación.

2. Obtener el token

Dependiendo del entorno, existen diferentes métodos para obtener el token.

3. Analizar el token

La herramienta JWT analizará el token.

4. Lea el token de redis

Lea el token de acceso conectando la clave y el uid. Si el token del usuario no existe, significa que el usuario ha cerrado sesión.

5. Verificar token

Determine si el token pertenece a uid, determine si el token ha caducado y, si ha caducado, realice el siguiente proceso para actualizar el token.

6. Inyectar permisos

Si la verificación del token es exitosa, los permisos se generan en función de la información del usuario y se inyectan en el contexto de seguridad de Spring.

1. El cliente solicita que la API

lleve refresco_token. Si es un entorno de producción, la información de refresco_token no se transportará directamente. Consulte lo siguiente para evitar ataques de repetición.

2. Obtener el token

Dependiendo del entorno, los métodos para obtener el token también son diferentes.

3. Analiza el token

El token es analizado por la herramienta JWT.

4. Lea el token

Lea el token de acceso según la clave de empalme de uid. Si el token del usuario no existe, cierre la sesión del usuario.

5. Verificar el token

Determine si el token pertenece al uid y si ha caducado. Si caduca, se devolverá un error de caducidad de refresco_token. el usuario necesita iniciar sesión nuevamente.

6. refresco_token

Si la verificación de refresco_token es exitosa, regenere el token de acceso y el refresco_token, calcule la fecha de vencimiento anterior hacia atrás desde la hora actual, reemplace el token del usuario en redis y devuelva el token. al cliente.

1. Lectura de parámetros

1. En el entorno de producción, el token no se puede pasar directamente, pero se deben pasar los datos de la firma y el lado del servidor obtiene la firma a través de la firma de Redis. controlar.

2. En un entorno que no sea de producción, lea el token directamente desde el encabezado.

2. En el entorno de producción, pase los siguientes parámetros

memberid (ID de usuario)

nonce (cadena aleatoria, 6 dígitos)

marca de tiempo (marca de tiempo actual, en segundos)

sign= md5( uid nonce timestamp token )

Lógica de verificación

1. Marca de tiempo de verificación

Determine si la marca de tiempo ha excedido los 60 segundos. Si excede los 60 segundos, se considera un golpe de poder de repetición.

2. Verificar nonce

Primero verifique si el nonce existe en reids. Si existe, se considera un hit de repetición; de lo contrario, se registrará en redis (clave: "nonce. " uid "_" nonce), el tiempo de vencimiento es 60 s.

3.

3. Verificar firma

3.

4. Verificar token

Obtenga el token de uid, la lógica de verificación es la misma que el proceso de autenticación.

Por supuesto, existen varias soluciones implementadas en diferentes escenarios comerciales. Esta solución es solo para su referencia.