Nota de traducción.: En este maravilloso material de Okta, se explican de manera simple y visual los principios de funcionamiento de OAuth y OIDC (OpenID Connect). Estos conocimientos serán útiles para desarrolladores, administradores de sistemas e incluso para “usuarios comunes” de aplicaciones web populares que probablemente también intercambian datos confidenciales con otros servicios.
En la ‘edad de piedra’ de Internet, compartir información entre servicios era sencillo. Solo tenías que dar tu nombre de usuario y contraseña de un servicio a otro, para que este entrara en tu cuenta y obtuviera cualquier información que necesitara.
‘Proporciona tu cuenta bancaria’. — ‘¡Prometemos que tu contraseña y dinero estarán seguros. ¡Realmente lo prometemos!’ *ji-ji*
¡Horror! Nunca nadie debería exigir al usuario que comparta su nombre de usuario y contraseña, sus credenciales, con otro servicio. No hay garantía de que la organización detrás de ese servicio mantenga los datos seguros y no reúna más información personal de la que necesita. Puede parecer absurdo, pero algunas aplicaciones aún utilizan esta práctica.
Hoy en día existe un estándar único que permite que un servicio utilice de manera segura los datos de otro. Desafortunadamente, estos estándares están repletos de jerga y términos, lo que dificulta su comprensión. El objetivo de este material es explicar, a través de ilustraciones simples, cómo funcionan (¿Crees que mis dibujos parecen garabatos de niños? ¡Bueno, está bien!).
Por cierto, esta guía también está disponible en formato de video:
Damas y caballeros, den la bienvenida a: OAuth 2.0
— es un estándar de seguridad que permite que una aplicación obtenga permiso para acceder a la información de otra aplicación. El proceso para otorgar el permiso [permission] (o consentimiento [consent]) a menudo se llama autorización [authorization] o incluso autorización delegada [delegated authorization]. Con este estándar, permites que una aplicación lea datos o use funciones de otra aplicación en tu nombre, sin revelar tu contraseña. ¡Genial!
Como ejemplo, imaginemos que encuentras un sitio llamado ‘El juego de palabras terrible del día’ [Terrible Pun of the Day] y decidieron registrarse para recibir diariamente juegos de palabras en forma de mensajes de texto en el teléfono. Te gustó mucho el sitio, y decidiste compartirlo con todos tus conocidos. Después de todo, a todos les gustan los juegos de palabras, ¿verdad?
«El juego de palabras desafortunado del día: ¿Escucharon sobre el chico que perdió la mitad izquierda de su cuerpo? ¡Ahora siempre tiene razón!» (la traducción es aproximada, ya que en el original hay un juego de palabras propio — nota del traductor)
Está claro que escribir a cada persona de la lista de contactos no es una opción. Y, si eres al menos un poco parecido a mí, harás todo lo posible para evitar trabajo extra. Afortunadamente, ¡Terrible Pun of the Day puede invitar a todos tus amigos por sí mismo! Solo necesitas darle acceso a la lista de correos electrónicos de tus contactos: el sitio se encargará de enviarles las invitaciones (¡OAuth manda!).
«¡Todos aman los juegos de palabras! — ¿Ya iniciaste sesión? — ¿Quieres darle acceso al sitio Terrible Pun of the Day a la lista de contactos? — ¡Gracias! ¡Ahora enviaremos recordatorios a todos los que conoces todos los días por los tiempos de los tiempos! ¡Eres el mejor amigo!»
- Elige tu servicio de correo electrónico.
- Si es necesario, dirígete al sitio del correo e inicia sesión en tu cuenta.
- Permite que el sitio Terrible Pun of the Day acceda a tus contactos.
- Regresa al sitio Terrible Pun of the Day.
En caso de que cambies de opinión, las aplicaciones que utilizan OAuth también ofrecen una forma de revocar el acceso. Si decides que ya no deseas compartir contactos con Terrible Pun of the Day, puedes ir al sitio del correo y eliminar el sitio de juegos de palabras de la lista de aplicaciones autorizadas.
Flujo de OAuth
Acabamos de pasar por lo que comúnmente se llama flujo [flow] OAuth. En nuestro ejemplo, este flujo se compone de pasos visibles, así como de varios pasos invisibles, en los cuales los dos servicios acuerdan un intercambio seguro de información. En el ejemplo anterior con Terrible Pun of the Day, se utiliza el flujo OAuth 2.0 más común, conocido como flujo «con código de autorización». [«authorization code» flow].
Antes de profundizar en los detalles del funcionamiento de OAuth, hablemos del significado de algunos términos:
- Propietario de Recursos:
¡Eres tú! Eres dueño de tus credenciales, de tus datos y controlas todas las acciones que pueden llevarse a cabo con tus cuentas. - Cliente:
Una aplicación (por ejemplo, el servicio Terrible Pun of the Day) que desea acceder o realizar ciertas acciones en nombre de Propietario de Recursosél. - Servidor de autorización:
Una aplicación que conoce Propietario de Recursosél y en la que Propietario de Recursosél ya tiene una cuenta. - Servidor de recursos:
Interfaz de programación de aplicaciones (API) o servicio que Cliente desea utilizar en nombre de Propietario de Recursosél. - URI de redirección:
El enlace al que Servidor de autorización redirigirá Propietario de Recursosél después de otorgar el permiso Clientea él. A veces se le llama 'URL de retorno' ('Callback URL'). - Tipo de respuesta:
El tipo de información que espera recibir Cliente. El más común Tipo de respuestade ellos es el código, es decir, Cliente calculando obtener Código de autorización. - Ámbito:
Una descripción detallada de los permisos requeridos Clientepor él, como el acceso a datos o la realización de ciertas acciones. - Consentimiento:
Servidor de autorización toma Ámbitos, solicitados Clientepor él, y pregunta a Propietario de Recursosél si está dispuesto a otorgar Clientelos correspondientes permisos. - Client ID:
Este ID se usa para identificar Clienteél en Servidor de autorizaciónél. - Secreto del cliente:
Es una contraseña que solo conoce Clienteél y Servidor de autorizaciónél. Les permite intercambiar información de manera confidencial. - Código de autorización:
Un código temporal con un período de validez breve que Cliente ofrece Servidor de autorizaciónél obtiene a cambio de Token de acceso. - Token de acceso:
Una clave que el cliente usará para comunicarse con Servidor de recursosél. Una especie de insignia o tarjeta clave que proporciona Clientea él permisos para solicitar datos o realizar acciones en Servidor de recursossu nombre en él.
Nota: a veces, el Servidor de Autorización y el Servidor de Recursos son el mismo servidor. Sin embargo, en algunos casos, pueden ser servidores diferentes, incluso sin pertenecer a la misma organización. Por ejemplo, el Servidor de Autorización podría ser un servicio de terceros en el que confía el Servidor de Recursos.
Ahora que hemos revisado los conceptos básicos de OAuth 2.0, volvamos a nuestro ejemplo y examinemos en detalle qué sucede en el flujo de OAuth.
- Usted, Propietario de Recursos, desea otorgar al servicio Terrible Pun of the Day (Clienteél) acceso a sus contactos para que pueda enviar invitaciones a todos sus amigos.
- Cliente redirige el navegador a la página Servidor de autorizaciónde él e incluye en la solicitud Client ID, URI de redirección, Tipo de respuesta uno o varios Ámbitos (permisos) que necesita.
- Servidor de autorización verifica su identidad, solicitando su nombre de usuario y contraseña si es necesario.
- Servidor de autorización muestra un formulario Consentimiento (de confirmación) con una lista de todos los Ámbitos, solicitados Clientepor él. Usted acepta o rechaza.
- Servidor de autorización le redirige al sitio web Clientede él, utilizando URI de redirección junto con Código de autorización (código de autorización).
- Cliente se comunica directamente con Servidor de autorizaciónél (sin pasar por el navegador de Propietario de Recursosél) y envía de forma segura Client ID, Secreto del cliente y Código de autorización.
- Servidor de autorización verifica los datos y responde con Token de acceso‘un (token de acceso).
- Ahora Cliente puede usar Token de acceso para enviar una solicitud a Servidor de recursos con el objetivo de obtener una lista de contactos.
Client ID y Secret
Mucho antes de que autorizara a Terrible Pun of the Day a acceder a los contactos, el Cliente y el Servidor de Autorización establecieron una relación de trabajo. El Servidor de Autorización generó el Client ID y el Client Secret (a veces se les llama App ID y App Secret) y se los envió al Cliente para futuras interacciones en el marco de OAuth.
«— ¡Hola! ¡Me gustaría trabajar contigo! — ¡No hay problema! ¡Aquí están tu Client ID y Secret!»
El nombre sugiere que el Client Secret debe mantenerse en secreto, de modo que solo lo conozcan el Cliente y el Servidor de Autorización. De hecho, con su ayuda, el Servidor de Autorización confirma la autenticidad del Cliente.
Pero eso no es todo... ¡Por favor, denle la bienvenida a OpenID Connect!
OAuth 2.0 fue diseñado solo 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 información sobre el inicio de sesión y el perfil del usuario que ha iniciado sesión. La organización de la sesión de inicio de sesión se denomina a menudo autenticación [authentication], y la información sobre el usuario que ha iniciado sesión (es decir, sobre Propietario de Recursos‘él), — datos personales [identity]. Si el Servidor de Autorización admite OIDC, a veces se le llama proveedor de identidad [identity provider], ya que proporciona Cliente‘a información sobre Propietario de Recursosél.
OpenID Connect permite implementar escenarios en los que se puede utilizar un solo inicio de sesión en múltiples aplicaciones; este enfoque también se conoce como inicio de sesión único (SSO). Por ejemplo, una aplicación puede admitir integración SSO con redes sociales como Facebook o Twitter, permitiendo a los usuarios utilizar la cuenta que ya tienen y que prefieren usar.
El flujo de OpenID Connect es similar al de OAuth. La única diferencia es que en la solicitud inicial el scope específico utilizado es openid, — y Cliente al final recibe como Token de acceso, como ID Token.
Al igual que en el flujo de OAuth, Token de acceso en OpenID Connect — es un valor que no es comprensible Cliente‘para él. Desde la perspectiva de Cliente‘é Token de acceso representa una cadena de caracteres que se transmite con cada solicitud a Servidor de recursos‘él, y él determina si el token es válido. ID Token representa algo completamente diferente.
ID Token es un JWT
ID Token — es una cadena de caracteres formateada de una manera especial, conocida como JSON Web Token o JWT (a veces los tokens JWT se pronuncian como «jots»)Para los observadores externos, el JWT puede parecer un galimatías confuso, sin embargo, Cliente se puede extraer diversa información del JWT, como el ID, el nombre de usuario, el tiempo de inicio de sesión y la fecha de expiración, ID Tokenla existencia de intentos de manipulación en el JWT. Los datos dentro del ID Tokense denominan reclamaciones [claims].
En el caso de OIDC, también existe un método estándar a través del cual Cliente se puede solicitar información adicional sobre la identidad [identity] desde Servidor de autorización, como una dirección de correo electrónico, utilizando Token de acceso.
Más información sobre OAuth y OIDC
Así que hemos revisado brevemente los principios de funcionamiento de OAuth y OIDC. ¿Listo para profundizar? Aquí tienes recursos adicionales que te ayudarán a aprender más sobre OAuth 2.0 y OpenID Connect:
Como siempre, no dudes en comentar. Para estar al tanto de nuestras últimas novedades, suscríbete a y ¡la compañía Okta para desarrolladores!
P.D. del traductor
También puedes leer en nuestro blog:
- «»;
- «»;
- «»;
- «».
Fuente: habr.com
