OpenID Connect tiene una especificación , hay tutoriales, artículos en el centro y no en el centro Es bastante inútil esculpir otra instrucción paso a paso, que conduce desde un profundo desconcierto hasta el trabajo a través de la autorización y la autenticación. La tarea del texto a continuación es diferente, para describir las ideas subyacentes a las especificaciones (hay más de una).
No voy a saltar sobre el tema del artículo de inmediato, pero comenzaré con cosas simples y muchas más obvias. Continuaré con la forma en que se desarrollaron y lo que envolvieron de acuerdo con los requisitos de los clientes. Me acercaré a él históricamente, es decir, en la forma en que nació.
1)
La tarea mínima es simplemente no permitir que nadie acceda a ninguno de sus recursos. Lo cerramos con nombre de usuario / contraseña, quién sabe qué par de nombres de usuario y contraseñas correctos llegarán al recurso, quién no, no. Esto se llama autenticación , ya que puede usar no solo inicios de sesión con contraseñas (código SMS, por ejemplo, o una llave USB de hardware), sino que estos detalles no son esenciales para nuestro tema. También omitiré el párrafo obligatorio sobre el peligro de transmitir contraseñas a través de Internet de forma abierta, por lo que a todos nos disgusta la autenticación de acceso básico .
Es mejor tener en cuenta esto: a ninguno de los usuarios le gusta ingresar inicios de sesión con contraseñas. Los códigos en SMS no son mejores, y las memorias USB simplemente son odiadas. Para no obligar al usuario a ingresar un inicio de sesión con una contraseña para cada solicitud, el servidor en respuesta a ellos envía una línea de galimatías llamada clave de sesión . Y luego esta clave se aferra a cada solicitud del servidor por parte del cliente (generalmente con un encabezado HTTP, pero esto no es esencial), y el servidor verifica si tiene tal sesión.
Sesión con una clave: los fenómenos, por definición, son temporales, la proporción áurea para la duración de una sesión es aproximadamente "mientras la pestaña del navegador está abierta, pero no más de un día"
2)
Dejaron entrar a cualquiera, eso es bueno. Ahora necesita comprender exactamente a quién dejamos ir. Y no solo para deducir lo que ingresó como nombre en la esquina superior derecha, sino también para decidir qué dejarlo entrar y qué no.
Y todo esto se llama autorización . Y no estoy seguro de ti, pero lo confundo con autenticación todo el tiempo. Para no confundir, una regla relativamente mnemónica, "autorización", de las palabras "autor", "autor" escriben en las portadas de los libros, y nunca escriben "un miembro válido de la Unión de Escritores" allí. Un autor es siempre una persona muy específica. Entonces, la autorización es un proceso cuando entendemos a quién lanzamos exactamente por nombre de usuario y contraseña.
3)
Ok Tenemos un sitio, hay algo secreto en el sitio, en la entrada de la parte secreta requerimos una contraseña, a cada uno se le muestran solo sus secretos y no mostramos extraños. La vida no se detiene, y tenemos otro sitio. Y aquí nuevamente encontramos el problema desde el punto 1, ¡a nadie le gusta ingresar nombres de usuario y contraseñas! Puede combinar la base de usuarios y esto les ahorrará tener que registrarse dos veces, pero ¿cómo evitar que vuelvan a ingresar el nombre de usuario y la contraseña en la entrada? Dada la existencia de algo como la Política del mismo origen (y nuestros sitios están ubicados, por supuesto, en diferentes dominios, entonces las cookies con una clave de sesión no son visibles entre sí). Aquí, para dar importancia al momento, comenzaré un nuevo punto.
4)
SSO , inicio de sesión único : sea cual sea la implementación, Microsoft Kerberos, SAML o algo OAuth 2.0 , además de lo cual se construye OpenID Connect , sobre lo que te escribo aquí, de hecho, bajo el capó siempre hay lo mismo: hay un servidor separado autorización , y cualquier persona que quiera autorizar a un usuario lo redirige a él. Si el usuario ya está autorizado, la sesión se retoma e inmediatamente regresa del servidor de autorización y llega a donde quería. Si no está autorizado, el servidor de autorización resuelve este problema lo mejor que puede, solicitando un inicio de sesión con una contraseña, como regla, y si la solución es exitosa, envía al usuario de regreso.
Además, SAML en este momento la solución, por así decirlo, está desactualizada. Y Kerberos es generalmente una magia cerrada de Microsoft completamente separada que va mucho más allá del alcance del protocolo HTTP. Bueno, nos centraremos en eso. Y luego llegamos al siguiente problema.
Ya existe un escenario de trabajo comprensible: en cualquier situación incomprensible, envíe al usuario al servidor de autorización, déjelo decidir qué hacer con él y devuelva una respuesta lista. Pero, ¿cómo le dice exactamente el servidor de autorización a ese otro servidor que el usuario está autorizado? Aquí volvemos nuevamente a las ideas del párrafo uno, a saber, a la clave de la sesión. Volvamos a lo básico: la presencia de una clave de sesión es un signo de autorización, la clave de sesión en sí abre la puerta a la información del usuario y, no lo creerá, a la información de la sesión. Entonces el servidor de autorización autoriza y entrega la clave de sesión a otro servidor.
Ahora, sin embargo, ya no se llama clave de sesión, sino un token .
Más precisamente, (de acuerdo con el protocolo OAuth 2.0 , sobre el cual se escribe OpenID Connect), estos son dos tokens a la vez: Token de acceso , para conectarlo a todas las solicitudes como claves de sesión recortadas del abuelo, y Token de actualización, para actualizar el Token de acceso cuando se apaga.
Para resumir el subtotal. En lugar de pedirle al usuario un nombre de usuario y contraseña, el servidor lo envía a otro servidor, un servidor de autorización separado. Él hace todo el trabajo y luego da las primeras fichas. En exactamente este escenario, las aplicaciones son autorizadas, móviles y, a veces, de escritorio. Simplemente no realizan redireccionamientos, simplemente envían al servidor de autorización JSON con un nombre de usuario y contraseña, y él les envía tokens en respuesta.
Las aplicaciones móviles y de escritorio pueden hacer esto. Por alguna razón, se consideran más seguros que la web, pero la web tiene una vida más complicada.
6)
Por un lado, no es más complicado, sino más simple. Puede hacer una redirección y no molestarse en presentar un formulario de inicio de sesión y contraseña. Por otro lado, realmente, realmente no quiero arrastrar tokens a través del navegador en claro. Esto es casi tan desagradable como la contraseña sin cifrar en la autenticación de acceso básico . Pero nadie quiere repetir ese viejo error terrible.
No hubo solución al problema, por lo que es muy elegante, pero funciona. Primero, todo va como siempre, cambiando a autorización, autorización propia. Luego, cuando llega el momento de volver con tokens, se produce la redirección inversa. Pero en lugar de tokens, se adjunta un código de una sola vez a la dirección de retorno. El servidor de autorización acaba de generar el código de una sola vez para este momento en particular. Tiene una vida muy corta. Habiendo recibido apenas un código de una sola vez, otro servidor debe meter las faldas, abrir los ojos y apresurarse nuevamente al servidor de autorización para recibir los codiciados tokens del código de una sola vez.
Hay un recurso especial para un viaje con un código para tokens en el servidor de autorización. Acepta, por especificación, no GET, sino POST. Eso de alguna manera nos insinúa que esta solicitud no debe hacerse desde el navegador, sino de servidor a servidor.
Por la misma razón, en cualquier servidor de autorizaciones CORS que se respete, las solicitudes POST están prohibidas.
7)
Por cierto, ¿todavía recuerdas sobre autenticación y autorización? La autenticación es cuando alguien simplemente puede ingresar por usuario y contraseña, o no está permitido. Y la autorización es cuando ya se han puesto en marcha, comienzan a comprender exactamente a quién se pusieron en marcha.
¿Te acuerdas de OAuth 2.0 ? Lo mencioné un par de veces arriba, como una especie de base para OpenID Connect.
¿Recuerdas OpenID Connect ? Este artículo es solo él tonto.
Entonces, OAuth 2.0 es autenticación. Todo el procedimiento ligeramente confuso descrito anteriormente con tres participantes, una contraseña, un código y un token se trata de autenticación, solo de permitir que alguien corra en algún lugar. Protocolo OAuth 2.0.
OpenID Connect es autorización. Es decir, agrega a OAuth aquellas partes donde resulta a quién dejaron ir.
Para hacer esto, se agrega uno más a la lista de tokens, se llama ID Token . Los que siguen el enlace probablemente se sorprendan al no ver nada sobre cualquier ID de token en él. Que la sorpresa no se convierta en un susto, esta identificación de token es el JWT devuelto como una muñeca anidada codificada en base64 en el mismo JSON que el token de acceso y el token de actualización. En cualquier caso, todo lo que querías saber sobre el usuario está en él.
Y también hay un recurso especial en el servidor de autorización llamado información de usuario, donde puede llamar con el token de acceso y obtener el mismo JSON en respuesta que en la identificación del token. Pero, ¿por qué es necesario si la ID de token ya está allí? Pregunta a los autores de la especificación.
OpenID Connect también contiene una descripción de los diversos campos de información del usuario. ¿Cómo puedo obtener esta información, correctamente durante la autorización o en cualquier momento después? Y una descripción de cómo y cuándo el usuario le permitirá utilizar esta información.
O no permitirlo. Entonces, en resumen, OpenID Connect 1.0 está diseñado.
8)
Un poco de oropel en el protocolo. Espero que esté lo suficientemente cansado de leer el artículo en este momento, para no prestar mucha atención a este artículo, simplemente pasándolo por los ojos. Aquí mencionaré los parámetros que están en la especificación, y llevan una carga semántica, pero no están directamente relacionados con la implementación de la idea en sí. Básicamente, agregan seguridad, bueno, o simplemente le permiten transferir información de uno de los participantes en el proceso a otro, si es necesario.
Identificación del cliente y secreto del cliente . El cliente en el idioma del protocolo OpenID Connect no es un navegador en absoluto, sino el otro servidor que necesita autorizar al usuario. Supongamos que tiene un sitio web y desea adjuntarle una autorización de moda a través de Facebook. Y a través de googol. Y no tan de moda a través de Twitter. Implementar el protocolo en el código no será suficiente. También deberá registrarse en Facebook, Google y Twitter, pero no como usuario, sino como el cliente que, como servidor, puede usar su autorización. Al registrarse, recibirá una identificación de cliente y un secreto de cliente del facebook condicional. Y cuando solicite autorización, entre otras cosas, envíe una identificación de cliente. Y cuando vaya con un código único para un token, Client Secret también lo requerirá.
Redirigir URI . Todo es simple aquí. Al enviar a un usuario a un Facebook condicional para iniciar sesión, debe decirle a Facebook dónde devolverle los códigos y tokens después de la autorización. Por supuesto, todavía le da su identificación de cliente. Pero un URI de redireccionamiento separado le permite redirigir después de la autorización a diferentes usuarios a diferentes páginas, por ejemplo, administradores al panel de administración y usuarios normales a sus páginas personales. Práctico. Además, la lista permitida de posibles URI de redireccionamiento especificados en la configuración del cliente en el Facebook condicional es una seguridad adicional.
Alcance Esta es una lista de lo que el servidor quiere saber sobre el usuario del servidor de autorización. Los valores en la lista están separados por espacios, openid debería ser obligatorio entre ellos y luego leer la especificación.
Estado ¿Recuerdas el código de una sola vez, por el cual se emiten los tokens, como un boleto en una cola electrónica? Entonces, el estado es un código, por el contrario, si el servidor de autorización le da el código a otro servidor para que lo devuelva pronto, ese estado le da al otro servidor el servidor de autorización para que lo devuelva al redirigir. Es necesario, según tengo entendido, si otro servidor ya ha logrado crear su propia sesión para que no se pierda en todos estos redireccionamientos.
Existen otros parámetros, como el tipo de solicitud de autorización y la duración del token, pero para comprender por qué no los necesita.
En conclusión Realmente espero que la lectura no demasiado reflexiva y centrada del texto anterior en alguna parte lo haya ayudado a captar las ideas que subyacen a algunos protocolos modernos de control de acceso. Pero al comenzar a implementar, o simplemente a configurar uno de ellos, abra las especificaciones, encuentre un buen tutorial y siga cuidadosamente cada palabra y cada letra. Y deja que la comprensión de las ideas despierte la intuición en ti. Y la intuición, deja que te muerda la corona cada vez que omitas un parámetro que no es tan significativo a primera vista, o un ajuste, y deja esto como un agujero para pequeñas manos sudorosas y juguetonas.
Recuerde que esta es la misma seguridad, y sus reglas, no importa cuán estúpidas y sin sentido puedan parecer, están escritas en sangre. Bueno, tal vez no con sangre, no es una medida de seguridad en la fundición, después de todo, pero el dinero y la reputación son seguros, y el dinero y la reputación tampoco son las cosas que debería arrojar fácilmente de esa manera.
Gracias a JM por el hecho de que el texto que leíste fue mucho mejor que el que escribí.
Buena suerte y no olvides renovar tus certificados a tiempo.