Nota. traducir: Este excelente artículo de Okta explica cómo funcionan OAuth y OIDC (OpenID Connect) de una manera simple y clara. Este conocimiento será útil para desarrolladores, administradores de sistemas e incluso "usuarios habituales" de aplicaciones web populares, que probablemente también intercambien datos confidenciales con otros servicios.
En la Edad de Piedra de Internet, compartir información entre servicios era fácil. Simplemente le dio su nombre de usuario y contraseña de un servicio a otro, para que ingresara a su cuenta y recibiera la información que necesitaba.
"Dame tu cuenta bancaria". “Prometemos que todo estará bien con la contraseña y el dinero. ¡Eso es honesto, honesto!" * je je *
¡Horror! Nadie debería exigir a un usuario que comparta un nombre de usuario y una contraseña, cartas credenciales, con otro servicio. No hay garantía de que la organización detrás de este servicio mantenga los datos seguros y no recopile más información personal de la necesaria. Puede sonar loco, ¡pero algunas aplicaciones todavía usan esta práctica!
Hoy en día existe un único estándar que permite que un servicio utilice de forma segura los datos de otro. Desafortunadamente, dichos estándares utilizan mucha jerga y términos, lo que complica su comprensión. El objetivo de este material es explicar su funcionamiento mediante ilustraciones sencillas (¿Crees que mis dibujos se parecen a los embadurnamiento de los niños? ¡Vaya!).
Por cierto, esta guía también está disponible en formato de vídeo:
Damas y caballeros, bienvenidos: OAuth 2.0
es un estándar de seguridad que permite que una aplicación obtenga permiso para acceder a información en otra aplicación. Secuencia de pasos para la emisión de un permiso [permiso] (o consentimiento [consentir]) llaman a menudo autorización [autorización] o autorización delegada [autorización delegada]. Con este estándar, permite que una aplicación lea datos o use las funciones de otra aplicación en su nombre sin darle su contraseña. ¡Clase!
Como ejemplo, supongamos que descubre un sitio llamado "Juego de palabras desafortunado del día". [Juego de palabras terrible del día] y decidió registrarse en él para recibir juegos de palabras diarios en forma de mensajes de texto en el teléfono. Te gustó mucho el sitio y decidiste compartirlo con todos tus amigos. Después de todo, a todos les gustan los juegos de palabras espeluznantes, ¿verdad?
“Juego de palabras desafortunado del día: ¿escuchó sobre el tipo que perdió la mitad izquierda de su cuerpo? ¡Ahora siempre tiene razón!”. (traducción aproximada, porque el original tiene su propio juego de palabras - traducción aproximada)
Está claro que escribir a cada persona de la lista de contactos no es una opción. Y, si eres un poco como yo, harás todo lo posible para evitar el trabajo innecesario. ¡Afortunadamente, Terrible Pun of the Day puede invitar a todos tus amigos por sí mismo! Para hacer esto, solo necesita abrir el acceso al correo electrónico de sus contactos: ¡el sitio mismo les enviará invitaciones (reglas OAuth)!
“¡A todo el mundo le encantan los juegos de palabras! - ¿Ya iniciado sesión? “¿Le gustaría permitir que el sitio web Terrible Pun of the Day acceda a su lista de contactos? - ¡Gracias! A partir de ahora, enviaremos recordatorios todos los días a todos tus conocidos, ¡hasta el final de los tiempos! ¡Tu eres el mejor amigo!"
- Elige tu servicio de correo electrónico.
- Si es necesario, vaya al sitio de correo e inicie sesión en su cuenta.
- Dale permiso a Terrible Pun of the Day para acceder a tus contactos.
- Regrese al sitio Terrible Pun of the Day.
En caso de que cambie de opinión, las aplicaciones que usan OAuth también brindan una forma de revocar el acceso. Una vez que decida que ya no desea compartir contactos con Terrible Pun of the Day, puede ir al sitio de correo y eliminar el sitio de juegos de palabras de la lista de aplicaciones autorizadas.
Flujo OAuth
Acabamos de pasar por lo que suele llamarse Arroyo [fluir] OAuth. En nuestro ejemplo, este flujo consta de pasos visibles, así como varios pasos invisibles, en los que dos servicios acuerdan un intercambio seguro de información. El ejemplo anterior de Terrible Pun of the Day usa el flujo de OAuth 2.0 más común, conocido como flujo de "código de autorización". [flujo de "código de autorización"].
Antes de profundizar en los detalles de cómo funciona OAuth, hablemos del significado de algunos términos:
- Propietario del recurso:
¡Eres tú! Usted posee sus credenciales, sus datos y controla todas las actividades que se pueden realizar en sus cuentas. - Cliente:
Una aplicación (por ejemplo, el servicio Terrible Pun of the Day) que quiere acceder o realizar ciertas acciones en nombre de Propietario del recurso'A. - Servidor de autorización:
La aplicación que sabe Propietario del recurso'a y en que u Propietario del recursoYa tengo una cuenta. - Servidor de recursos:
Interfaz de programación de aplicaciones (API) o servicio que Cliente quiere usar en nombre Propietario del recurso'A. - URI de redirección:
el enlace que Servidor de autorización redirigirá Propietario del recurso'y después de dar permiso Cliente'en. A veces se denomina "URL de devolución de llamada". - Tipo de respuesta:
El tipo de información que se espera recibir Cliente. Los más comunes Tipo de respuesta'ohm es el código, eso es Cliente espera recibir Código de Autorización. - Lo que hacemos:
Esta es una descripción detallada de los permisos que se requieren Cliente'y, como acceder a datos o realizar ciertas acciones. - Consentimiento:
Servidor de autorización boina Scopessolicitado Cliente'om, y pregunta Propietario del recurso'a, ¿está listo para proporcionar Cliente'tener los permisos apropiados. - ID de cliente:
Este ID se utiliza para identificar Cliente'a en Servidor de autorización'mi. - Secreto del cliente:
Esta es la contraseña que solo se conoce Cliente'tu y Servidor de autorización'en. Les permite compartir información de forma privada. - Código de Autorización:
Código temporal con un período de validez corto, que Cliente proporciona Servidor de autorizacióny a cambio de El acceso de emergencia. - El acceso de emergencia:
La clave que el cliente utilizará para comunicarse con Servidor de recursos'om. Una especie de credencial o tarjeta llave que proporciona Cliente'tener permiso para solicitar datos o realizar acciones en Servidor de recursos'e en su nombre.
Nota: A veces, Authorization Server y Resource Server son el mismo servidor. Sin embargo, en algunos casos, estos pueden ser servidores diferentes, incluso si no pertenecen a la misma organización. Por ejemplo, el Servidor de autorización puede ser un servicio de terceros en el que confía el Servidor de recursos.
Ahora que hemos cubierto los conceptos básicos de OAuth 2.0, volvamos a nuestro ejemplo y analicemos más de cerca lo que sucede en el flujo de OAuth.
- Usted Propietario del recurso, desea proporcionar el servicio Terrible Pun of the Day (Clientey) acceder a tus contactos para que puedan enviar invitaciones a todos tus amigos.
- Cliente redirige el navegador a la página Servidor de autorización'a e incluir en la consulta ID de cliente, URI de redirección, Tipo de respuesta y uno o más Scopes (permisos) que necesita.
- Servidor de autorización te verifica, solicitando un nombre de usuario y contraseña si es necesario.
- Servidor de autorización muestra un formulario Consentimiento (confirmaciones) con una lista de todos Scopessolicitado Cliente'om. Estás de acuerdo o te niegas.
- Servidor de autorización te redirige al sitio Cliente'a, usando URI de redirección con Código de Autorización (Código de Autorización).
- Cliente se comunica directamente con Servidor de autorización'ohm (sin pasar por el navegador Propietario del recurso'a) y envía con seguridad ID de cliente, Secreto del cliente и Código de Autorización.
- Servidor de autorización comprueba los datos y responde con El acceso de emergencia'om (token de acceso).
- Ahora Cliente puedo usar El acceso de emergencia para enviar una solicitud a Servidor de recursos para obtener una lista de contactos.
ID de cliente y secreto
Mucho antes de que permitiera que Terrible Pun of the Day accediera a sus contactos, el Cliente y el Servidor de autorización habían establecido una relación de trabajo. El Servidor de Autorización generó el ID del Cliente y el Secreto del Cliente (a veces llamado ID de la aplicación и App secreta) y los envió al Cliente para una mayor interacción dentro de OAuth.
"- ¡Hola! ¡Me gustaría trabajar contigo! - ¡Claro, no hay problema! ¡Aquí está su identificación de cliente y secreto!”
El nombre implica que el secreto del cliente debe mantenerse en secreto para que solo el cliente y el servidor de autorización lo conozcan. Después de todo, es con su ayuda que el Servidor de Autorización confirma la verdad del Cliente.
Pero eso no es todo... ¡Dé la bienvenida a OpenID Connect!
OAuth 2.0 solo está diseñado para autorización - para proporcionar acceso a datos y funciones de una aplicación a otra. (OIDC) es una capa delgada sobre OAuth 2.0 que agrega los detalles de inicio de sesión y perfil del usuario que inició sesión en la cuenta. La organización de una sesión de inicio de sesión a menudo se denomina autenticación [autenticación]e información sobre el usuario que inició sesión en el sistema (es decir, sobre Propietario del recurso'e), - información personal [identidad]. Si el servidor de autorización es compatible con OIDC, a veces se lo denomina proveedor de datos personales [proveedor de identidad]porque proporciona Cliente'tener información sobre Propietario del recurso'mi.
OpenID Connect le permite implementar escenarios en los que se puede usar un solo inicio de sesión en varias aplicaciones; este enfoque también se conoce como inicio de sesión único (SO). Por ejemplo, una aplicación puede admitir la integración de SSO con redes sociales como Facebook o Twitter, lo que permite a los usuarios usar una cuenta que ya tienen y prefieren usar.
El flujo (flow) de OpenID Connect tiene el mismo aspecto que en el caso de OAuth. La única diferencia es que en la solicitud principal, el ámbito específico utilizado es openid, - A Cliente eventualmente se pone como El acceso de emergenciaY Token de identificación.
Al igual que en el flujo de OAuth, El acceso de emergencia en OpenID Connect, este es un valor que no está claro Cliente'en. desde el punto de vista Cliente'pero El acceso de emergencia representa una cadena de caracteres que se pasa junto con cada solicitud a Servidor de recursos'y, que determina si el token es válido. Token de identificación representa una cosa completamente diferente.
El token de identificación es un JWT
Token de identificación es una cadena de caracteres con formato especial conocida como JSON Web Token o JWT (a veces, los tokens JWT se pronuncian como "jots"). Para los observadores externos, JWT puede parecer un galimatías incomprensible, pero Cliente puede extraer información diversa del JWT, como ID, nombre de usuario, hora de inicio de sesión, fecha de vencimiento Token de identificación'a, la presencia de intentos de interferir con el JWT. Datos dentro Token de identificación'a se llaman aplicaciones [reclamación (es].
En el caso de OIDC, también hay una forma estándar por la cual Cliente puede solicitar información adicional sobre el individuo [identidad] de Servidor de autorización'a, por ejemplo, una dirección de correo electrónico usando El acceso de emergencia.
Más información sobre OAuth y OIDC
Entonces, revisamos brevemente cómo funcionan OAuth y OIDC. ¿Listo para profundizar más? Aquí hay recursos adicionales para ayudarlo a obtener más información sobre OAuth 2.0 y OpenID Connect:
Como siempre, siéntete libre de comentar. Para estar al día de nuestras últimas noticias, suscríbete a и Okta para desarrolladores!
PD del traductor
Lea también en nuestro blog:
- «";
- «";
- «";
- «".
Fuente: habr.com