Cosas importantes que necesitas saber sobre OAuth

Oauth es algo que todo desarrollador debe saber sobre. Si está haciendo una aplicación independiente o una aplicación de terceros que se integra con algún otro servicio HTTP, debe saber cómo funciona OAuth para proporcionar a sus usuarios un servicio fácil de usar y bien integrado.

La idea es permitir a las aplicaciones del cliente un acceso limitado a la información del usuario sin compartir credenciales o contraseña de los usuarios. OAuth Framework es responsable de los intercambios que se requieren antes de que una aplicación obtenga su información.

Supongamos que desea registrarse en Dev.a (que es un gran lugar para que los desarrolladores intercambien ideas) le permiten registrarse usando su cuenta de GitHub. ¿Cómo pasa eso?? ¿Cómo sabrían que es dueño de la cuenta Github, con la que se está registrando con?

Más importante aún, ¿cómo se asegura de que Dev.no está sobrepasando sus límites cuando se trata de su información almacenada con GitHub?

Participantes de OAuth

Nos quedaremos con el ejemplo del complemento GitHub del editor Atom que permite a los desarrolladores empujar el código a GitHub directamente usando la interfaz Atom. La razón de esto como ejemplo es porque Github no esconde los detalles detrás de la escena y puedes ver qué está pasando debajo del capó.

Antes de entrar en las minucias del trabajo de Oauth. Establezcamos el escenario al reconocer a todos los participantes en el intercambio:

1. Propietario o usuario de recursos: Este usuario es aquel cuya información de la cuenta debe acceder (leer y/o escribir) para que funcione con una aplicación.
2. Cliente: Esta es la aplicación que busca su permiso para acceder a su información desde un servicio diferente. En nuestro ejemplo, Atom Editor es el cliente.
3. Recurso: El recurso es su información real en los servidores en una ubicación remota. Se puede acceder a esto a través de una API si se les otorga el cliente los permisos apropiados.
4. Servidor de autorización: También interfacido con a través de una API. El proveedor de servicios mantiene este servidor (GitHub en nuestro ejemplo). Tanto el servidor de autorización como el servidor de recursos se denominan API porque son administrados por una entidad, en este caso GitHub, y se exponen como API para el desarrollador del cliente.

Registro OAuth

El proceso comienza cuando se está desarrollando la aplicación del cliente. Puede ir al proveedor de recursos y registrarse con el portal de su desarrollador o la sección API del sitio web. También deberá proporcionar una URL de devolución de llamada donde el usuario se redirigiría después de aceptar o rechazar para dar a la aplicación los permisos necesarios.

Por ejemplo, si va a GitHub → Configuración → Configuración del desarrollador y haga clic en "Registre una nueva solicitud". Esto le proporcionaría un Identificación del cliente que se puede hacer público y un Secreto del cliente que, la organización del desarrollador debe mantener ... bueno un secreto.

Después de que se le proporcione la identificación del cliente y el secreto, el desarrollador, usted debe Manténgalos seguros, ya que el servidor de autorización no volverá a mostrar. Lo mismo ocurre con cualquier otro tokens que se arroje (más en fichas más tarde).

Oauth 2 flujo de trabajo

Ha registrado su solicitud. Se ha desarrollado y probado y ahora los usuarios están listos para usarlo. Un nuevo usuario al registrarse con su servicio se mostraría la opción de "Iniciar sesión con GitHub". este es el primer paso.

Paso 1: Solicitud de autorización

La solicitud de autorización es la parte en la que se abre una nueva ventana (o un mensaje similar) con la página web de recursos y les pide a los usuarios que inicien sesión. Si ya ha iniciado sesión, en ese dispositivo, entonces se omite este paso y GitHub simplemente le pregunta si desea dar acceso a la aplicación Atom Client Client. Esto es mucho más transparente en el caso de Atom porque le piden que vaya manualmente al sitio web de Github y les otorgue el permiso.

Al visitar la URL, se le pide el permiso.

Observe la URL que muestra que esta es una página web segura (HTTPS) por GitHub.Cª. Ahora usted, el usuario, puede estar seguro de que está interactuando directamente con GitHub. Atom simplemente está esperando, bastante apartado.

A diferencia de Atom, la mayoría de las aplicaciones de clientes cargan automáticamente la página de inicio de sesión o permisos. Si bien esto es muy conveniente, también se puede usar mal, si la aplicación del cliente decide abrir un enlace de phishing. Para evitar esto, siempre debe verificar la URL a la que se le redirige y asegurarse de que sea una URL correcta y esté utilizando el Protocolo HTTPS.

Paso 2: Obtener la subvención de autorización

Para notificar al cliente Atom, se le otorga un token (una subvención de autorización) que luego se presenta al cliente Atom.

Una vez que el usuario hace esto, el trabajo del usuario está hecho. (De hecho, un usuario típico ni siquiera tiene conocimiento del intercambio de la subvención de autorización. El ejemplo de Github fue elegido para mostrar que esto es lo que sucede).

Paso 3: Obtener el token de acceso

La subvención de autorización aún no es la entidad que le da al cliente acceso a la información del usuario. Que se obtiene usando algo llamado token de acceso. Que la aplicación del cliente intentará obtener en este paso.

Para hacer esto, el cliente ahora tendrá que proporcionar la subvención de autorización al servidor de autorización junto con una prueba de su propia identidad. La identidad se verifica utilizando la identificación del cliente y el secreto del cliente que se le dieron a la aplicación del cliente anteriormente.

La verificación de identidad se realiza para garantizar que el usuario no sea engañado para usar una aplicación nefastada que pretende ser una aplicación legítima. Por ejemplo, si alguien decide nombrar a su ejecutable como átomo con el mismo nombre, logotipo y funcionalidad, el usuario podría ser engañado para dar acceso a un cliente que puede hacer mal uso de su información. Pueden husmear o incluso actuar sin tu consentimiento. El servidor de autorización asegura que el cliente sea de hecho lo que parece a sus usuarios.

Una vez que se verifica la identidad y se acepta la subvención de autorización, el servidor de autorización arroja un token a la aplicación del cliente. Piense en el token como una combinación de nombre de usuario y contraseña que se puede dar al servidor de recursos para acceder a un recurso protegido particular que el propietario de los recursos le permitió acceder.

Finalmente, utilizando este token, la aplicación ahora puede obtener acceso a la información del usuario requerida y otros recursos del servidor de recursos.

Observe cómo en todo el intercambio completo el nombre de usuario y la contraseña reales donde nunca se comparten con el cliente? Esa es la belleza de Oauth. En lugar de dar nombre de usuario y contraseñas que otorgarían a la aplicación todo el acceso al recurso, utiliza tokens en su lugar. Y un token solo puede obtener un acceso limitado al recurso.

Revocación de permisos

Supongamos que pierde acceso a su dispositivo que tenía la aplicación de cliente autorizada en él. Puede iniciar sesión en GitHub e ir a Configuración → Aplicaciones → Aplicaciones autorizadas de OAuth para revocar la subvención de autorización y el token de acceso. Haré lo mismo, ya que, en las capturas de pantalla anteriores, la subvención de autorización se mostró públicamente.

Ahora que tienes una vista de ojo de pájaro de cómo oauth 2.Puede leer más sobre las subvenciones de autorización y otros detalles más finos del protocolo y cómo se realizan las llamadas API aquí.