[Permiso] Introducción al protocolo OpenID Connect

Introducción al protocolo OpenID Connect

1. Introducción

OpenID Connect es un protocolo de autenticación interoperable basado en la especificación OAuth 2.0. Utiliza un flujo de mensajes REST / JSON simple para implementar, en comparación con cualquier protocolo de autenticación anterior, los desarrolladores pueden integrar fácilmente.
OpenID Connect permite a los desarrolladores autenticar usuarios en sitios web y aplicaciones sin tener que tener un archivo de contraseña administrativa. OpenID Connect permite que todo tipo de clientes, incluido JavaScript basado en navegador y aplicaciones móviles nativas, inicien el flujo de inicio de sesión y reciban afirmaciones verificables sobre la identidad del usuario que inició sesión.

2. Básico

En términos simples, OIDC es un mecanismo de seguridad para que las aplicaciones se conecten al servidor de autenticación de identidad para obtener información del usuario y devolver esta información a la aplicación de una manera segura y confiable.
Los protocolos OpenID y OAuth a menudo se mencionan juntos, pero existen diferencias entre los dos:

• OpenID es Autenticación, que consiste en autenticar la identidad del usuario y determinar si su identidad es válida, es decir, hacerle saber al sitio web que "usted es el usuario que reclama".
• OAuth es Autorización, es decir, autorización. Cuando se sabe que la identidad del usuario es legal, el usuario está autorizado para permitir ciertas operaciones, es decir, para que el sitio web sepa "qué tienes permitido hacer". Se puede
  ver que la autorización debe realizarse después de la autenticación, solo se puede autorizar después de confirmar la identidad del usuario

Autenticación + OAuth2.0 = OpenID Connect

Tres, proceso

OAuth2 proporciona un token de acceso para resolver el problema de autorizar a los clientes de terceros a acceder a los recursos protegidos; de manera similar, OIDC proporciona un token de identificación sobre esta base para resolver el problema de los clientes de terceros que identifican a los usuarios. El núcleo de OIDC es proporcionar información de autenticación de identidad de usuario a clientes de terceros en el proceso de autorización de OAuth2. El token de ID está empaquetado en formato JWT. Gracias al mecanismo autónomo, compacto y a prueba de manipulaciones de JWT, ID-Token se puede pasar de forma segura a programas de cliente de terceros y verificar fácilmente.

Se puede ver que OIDC sigue el proceso del protocolo OAuth. Al solicitar Access-Token, también devuelve ID-Token para verificar la identidad del usuario.

1. El cliente envía una solicitud de autenticación al servicio de autenticación;
2. El usuario final realiza la confirmación de autorización en la página de autenticación (opcional);
3. El servicio de autenticación verifica la solicitud de autenticación y envía el token de identificación al cliente;
4. El cliente solicita el servicio y la solicitud lleva el token de identificación;
5. El servicio comercial devuelve una respuesta comercial después de verificar si el token de identificación es legal

Cuatro, datos en formato JWT (JSON Web Token)

El ID Token devuelto por el servicio de autenticación debe cumplir estrictamente con la definición de JWT (JSON Web Token). La siguiente es la definición de JWT (JSON Web Token):

1. iss: debe. Identificador de emisor, el identificador único del servicio de autenticación, una URL https que distingue entre mayúsculas y minúsculas, no contiene componentes de consulta ni fragmentos.

2. Sub: obligatorio. Subject Identifier, el identificador del usuario final proporcionado por iss, es único dentro del rango de iss, puede tener hasta 255 caracteres ASCII y distingue entre mayúsculas y minúsculas.

3. aud: Debe. La (s) audiencia (s), que identifica la audiencia del token de identificación, debe contener OAuth2 client_id, una matriz de cadenas que distingue entre mayúsculas y minúsculas.

4. exp: debe. El tiempo de vencimiento, el token de identificación después de este tiempo no será válido.

5. iat: debe. Emitido en el momento, el momento en que se construyó el JWT.

6. auth_time: AuthenticationTime, la hora en que el usuario final completa la autenticación.

7. Nonce: una cadena aleatoria proporcionada al enviar una solicitud de autenticación, que se utiliza para ralentizar los ataques de reproducción y también se puede utilizar para asociar sesiones de cliente. Si el nonce existe, el cliente debe verificarlo.

8. acr: opcional. La referencia de clase de contexto de autenticación representa un valor de referencia de contexto de autenticación, que se puede utilizar para identificar la clase de contexto de autenticación.

9. amr: opcional. Referencias de métodos de autenticación, representa un conjunto de métodos de autenticación.

10. azp: opcional. Parte autorizada, utilizado junto con aud. Este valor solo se usa cuando la parte autenticada y la audiencia (aud) son inconsistentes y rara vez se usa en general.

Ejemplos son:

{
	"iss": "https://1.2.3.4:8443/auth/realms/kubernetes",
	"sub": "547cea22-fc8a-4315-bdf2-6c92592a6e7c",
	"aud": "kubernetes",
	"exp": 1525158711,
	"iat": 1525158411,
	"auth_time": 0,
	"nonce": "n-0S6_WzA2Mj",
	"acr": "1",
	"azp": "kubernetes",
	"nbf": 0,
	"typ": "ID",
	"session_state": "150df80e-92a1-4b0c-a5c5-8c858eb5a848",
	"userId": "123456",
	"preferred_username": "theone",
	"given_name": "the",
	"family_name": "one",
	"email": "[email protected]"
}