Nota perev. : Esta gran publicación de blog de Okta explica cómo funciona OAuth y OIDC (OpenID Connect). Este conocimiento será útil para desarrolladores, administradores de sistemas e incluso "usuarios comunes" 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 proporcionó 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.
"Proporcione su cuenta bancaria". “Prometemos que todo estará bien con la contraseña y el dinero. ¡Eso es sinceramente honesto! ”* Ji, ji *Horror! Nadie debería exigir a un 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 este servicio mantendrá los datos seguros y no recopilará más información personal de la necesaria. Puede parecer salvaje, ¡pero algunas aplicaciones aún usan esta práctica!
Hoy existe un único estándar que permite que un servicio use de manera segura los datos de otro. Desafortunadamente, tales estándares usan mucha jerga y términos, lo que complica su comprensión. El propósito de este material es explicar cómo funcionan con ilustraciones simples (¿Crees que mis dibujos se asemejan a un bebé? Bueno, ¡está bien!).
Por cierto, esta guía también está disponible en formato de video:
Damas y caballeros, conozcan: OAuth 2.0
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. La secuencia de pasos para emitir un permiso
(permiso ) a menudo se denomina
autorización o incluso
autorización delegada . Al usar este estándar, permite que una aplicación lea datos o use las funciones de otra aplicación en su nombre sin decirle su contraseña. Clase!
Como ejemplo, imagine que descubrió un sitio llamado "
Juego de palabras terrible del día" y decidió registrarse en él para recibir juegos de palabras todos los días en forma de mensajes de texto en el teléfono. Realmente te gustó el sitio y decidiste compartirlo con todos tus amigos. Después de todo, juegos de palabras terribles como todos, ¿verdad?
"Juego de palabras fallido del día: ¿Has oído hablar de un hombre 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, - aprox. Traducción)Está claro que escribir a cada persona desde la lista de contactos no es una opción. Y, si eres un poco como yo, harás cualquier cosa para evitar un trabajo innecesario. ¡Afortunadamente, Terrible Pun of the Day puede invitar a todos tus amigos por su cuenta! Para hacer esto, solo necesita darle acceso al correo electrónico de contactos: ¡el sitio mismo les enviará invitaciones (unidades OAuth)!
"¡A todos les encantan los juegos de palabras!" - ¿Ya has iniciado sesión? - ¿Quieres compartir el sitio web Terrible Pun of the Day con tu lista de contactos? - gracias! ¡Ahora, todos los días enviaremos recordatorios a todos sus conocidos hasta el final de los tiempos! ¡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 al juego de palabras Terrible of the Day para acceder a tus contactos.
- Regrese al sitio web Terrible Pun of the Day.
En caso de que cambie de opinión, las aplicaciones que usan OAuth también proporcionan una forma de revocar el acceso. Habiendo decidido que ya no desea compartir contactos con Terrible Pun of the Day, puede ir al sitio de correo y eliminar el sitio con juegos de palabras de la lista de aplicaciones autorizadas.
OAuth Stream
Acabamos de pasar por lo que comúnmente se llama la
corriente OAuth
[flujo] . 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 del juego de palabras Terrible Pun del día usa el flujo OAuth 2.0 más común, conocido como
flujo de “código de autorización” .
Antes de profundizar en los detalles de OAuth, hablemos sobre el significado de algunos términos:
- Propietario del recurso :
Este eres tu! Usted posee sus credenciales, sus datos y administra todas las acciones que se pueden realizar con sus cuentas. - Cliente :
Una aplicación (por ejemplo, el servicio del juego de palabras Terrible of the Day) que quiere acceder o realizar ciertas acciones en nombre del propietario del recurso . - Servidor de Autorización :
Una aplicación que conoce al propietario del recurso y en la que el propietario del recurso ya tiene una cuenta. - Servidor de recursos :
Una interfaz de programación de aplicaciones (API) o servicio que un Cliente quiere usar en nombre del Propietario de Recursos . - Redireccionar URI :
El enlace en el que el Servidor de autorización redirige al Propietario del recurso a "después de otorgar el permiso del Cliente ". A veces se le llama URL de devolución de llamada. - Tipo de respuesta :
El tipo de información que el Cliente espera recibir. El tipo de respuesta más común es el código, es decir, el Cliente espera recibir un Código de autorización . - Alcance :
Esta es una descripción detallada de los permisos que el Cliente necesita, como acceder a los datos o realizar ciertas acciones. - Consentimiento
El servidor de autorización toma los ámbitos solicitados por el cliente y le pregunta al propietario del recurso si está listo para otorgarle los permisos apropiados. - ID del cliente :
Esta identificación se utiliza para identificar al cliente en el servidor de autorización . - Secreto del cliente :
Esta es una contraseña que solo conocen el Cliente y el Servidor de Autorizaciones . Les permite intercambiar información confidencialmente. - Código de autorización
Un código temporal a corto plazo que el Cliente proporciona al Servidor de autorización a cambio de un Token de acceso . - Token de acceso :
La clave que usará el cliente para comunicarse con el servidor de recursos . Esta es una tarjeta de identificación o clave que le da al Cliente permiso para solicitar datos o realizar acciones en el Servidor de recursos en su nombre.
Nota : a veces el Servidor de autorización y el Servidor de recursos son el mismo servidor. Sin embargo, en algunos casos, estos pueden ser servidores diferentes, que ni siquiera pertenecen a la misma organización. Por ejemplo, un servidor de autorización puede ser un servicio de terceros en el que el servidor de recursos confía.
Ahora que nos hemos familiarizado con los conceptos básicos de OAuth 2.0, volvamos a nuestro ejemplo y echemos un vistazo más de cerca a lo que sucede en la secuencia de OAuth.
- Usted, propietario del recurso , desea dar acceso a sus contactos al juego de palabras Terrible del día ( cliente ) para que pueda enviar invitaciones a todos sus amigos.
- El cliente redirige el navegador a la página del Servidor de autorización e incluye el ID del cliente , el URI de redireccionamiento , el Tipo de respuesta y uno o más Ámbitos (permisos) que necesita en la solicitud.
- El Servidor de autorización lo comprueba, si es necesario, solicitando un nombre de usuario y contraseña.
- El servidor de autorización muestra un formulario de consentimiento con una lista de todos los ámbitos solicitados por el cliente . Usted acepta o rechaza
- El servidor de autorización lo redirige al sitio del cliente utilizando el URI de redireccionamiento junto con el código de autorización .
- El cliente se comunica directamente con el servidor de autorización (sin pasar por el navegador del propietario del recurso ) y envía de manera segura la identificación del cliente , el secreto del cliente y el código de autorización .
- El servidor de autorización valida los datos y responde con un token de acceso .
- El cliente ahora puede usar el token de acceso para enviar una solicitud al servidor de recursos para obtener una lista de contactos.
ID de cliente y secreto
Mucho antes de permitir que Terrible Pun of the Day acceda a sus contactos, el Cliente y el Servidor de autorización establecieron 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 y
secreto de la aplicación ) y los envió al cliente para una mayor interacción dentro de OAuth.
"Hola! ¡Me gustaría trabajar contigo! - Sí, no hay duda! ¡Aquí tienes tu ID de cliente y tu secreto! "El nombre sugiere que el secreto del cliente debe mantenerse en secreto para que solo el cliente y el servidor de autorización lo sepan. De hecho, es con su ayuda que el Servidor de Autorizaciones confirma la verdad del Cliente.
Pero eso no es todo ... ¡Bienvenido a OpenID Connect!
OAuth 2.0 está diseñado solo para
autorización , para proporcionar acceso a datos y características de una aplicación a otra.
OpenID Connect (OIDC) es una capa delgada sobre OAuth 2.0 que agrega información sobre el nombre de usuario y el perfil del usuario que inició sesión en la cuenta. La organización de la sesión de inicio de sesión a menudo se denomina
autenticación , y la información sobre el usuario que inició sesión (es decir, sobre el
Propietario del
recurso ) se denomina
identidad . Si el Servidor de autorización admite OIDC, a veces se lo denomina
proveedor de identidad porque proporciona al
Cliente información sobre el
Propietario del recurso .
OpenID Connect le permite implementar escenarios cuando se puede usar un inicio de sesión único en muchas aplicaciones; este enfoque también se conoce como
inicio de sesión único (SSO). 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 que prefieren usar.
El flujo de OpenID Connect se ve igual que con OAuth. La única diferencia es que en la solicitud inicial, el alcance específico utilizado es
openid , y el
Cliente finalmente recibe tanto el
token de acceso como el token de identificación .
Al igual que en la secuencia OAuth, el
token de acceso en OpenID Connect es un valor que el
Cliente no entiende. Desde el punto de vista del
cliente , el
token de acceso representa una determinada cadena de caracteres que se transmite junto con cada solicitud al
servidor de recursos , que determina si el token es válido.
ID Token es completamente diferente.
ID Token es un JWT
ID Token es una cadena de caracteres especialmente formateada conocida como JSON Web Token o JWT
(a veces los tokens JWT se pronuncian "jots") . Para los extraños, el JWT puede parecer un abracadabra incomprensible, sin embargo, el
Cliente puede extraer información diversa del JWT, como ID, nombre de usuario, tiempo de inicio de sesión de la cuenta, fecha de vencimiento del
token de identificación e intentos de intervenir en el JWT. Los datos dentro de la
ID del
token se llaman
reclamo .
En el caso de OIDC, también existe una forma estándar en la que el
Cliente puede solicitar información adicional sobre la
identidad del
Servidor de Autorización , por ejemplo, una dirección de correo electrónico utilizando
Token de Acceso .
Obtenga más información sobre OAuth y OIDC.
Entonces, revisamos brevemente cómo funcionan OAuth y OIDC. Listo para cavar más profundo? Aquí hay recursos adicionales para ayudarlo a aprender más sobre OAuth 2.0 y OpenID Connect:
Como de costumbre, siéntase libre de comentar. Para estar al tanto de nuestras últimas innovaciones, suscríbase a Okta para
Twitter y
YouTube para desarrolladores.
PD del traductor
Lea también en nuestro blog: