Autorización entre servicios a través de OAuth 2.0

OAuth es un protocolo de autorización que permite que un servicio de terceros acceda a recursos seguros, en nombre del propietario del recurso. La autorización es diferente de la autenticación, ya que la autenticación es el proceso de verificar quién es el usuario, mientras que la autorización es el proceso de verificar a qué tiene acceso. Por lo tanto, OAuth es estándar para permitir que los servicios intenten acceder entre sí en nombre del usuario.

OAuth proporciona acceso delegado. Este concepto se puede explicar usando el ejemplo de Valet Key. En muchos hoteles, los clientes pueden entregar las llaves de su automóvil al valet para que estacione el automóvil en su nombre. Para evitar robos, algunos autos vienen con llave de valet que tiene acceso reducido. En este ejemplo, el servicio de valet necesita acceso al servicio de automóvil, para lo cual el cliente solo proporciona el subconjunto requerido de servicios, a través de la clave de valet. Esto representa el acceso delegado.

Figura: Inicie sesión a través de Google, Facebook, que utiliza OAuth para autorizar el servicio de terceros para acceder a los datos del usuario.

OAuth es, por lo tanto, un estándar abierto para la delegación de acceso, que se usa comúnmente como una forma en que los usuarios de Internet otorgan a los sitios web o aplicaciones acceso a su información en otros sitios web, pero sin darles las contraseñas.

Elementos de OAuth:
para describir los elementos involucrados en OAuth, elegimos un escenario de muestra en el que se puede emplear OAuth. Considere que los clientes de un servicio de impresión de fotografías en línea requieren una función que permita al servicio de impresión obtener directamente las fotos de los usuarios de su cuenta de Google Fotos. Para implementar dicha función, el enfoque trivial implicaría que el servicio de impresión solicite las credenciales de inicio de sesión del usuario para su cuenta de Google. Obviamente, este enfoque es muy inseguro, ya que los usuarios no pueden confiar en el servicio de impresión para acceder a toda su cuenta de Google. Aquí es donde entra OAuth.

La terminología utilizada para describir a los participantes/elementos en un sistema OAuth es:

  1. Recurso:
    representa los datos a los que accederá el servicio de terceros. En nuestro ejemplo, las fotos del usuario representan un recurso.
  2. Propietario
    del recurso: el propietario del recurso es el propietario real del recurso. Para nuestro escenario, el propietario original de las fotos es el propietario del recurso.
  3. Cliente:
    el cliente representa un servicio de terceros que requiere acceso al recurso en nombre del propietario del recurso. En nuestro ejemplo, el Servicio de impresión de fotografías es el Cliente.
  4. Servidor de recursos:
    representa el servidor en el que el recurso se almacena de forma segura. En nuestro ejemplo, las fotos están alojadas en Google Server, que actúa como servidor de recursos.
  5. Servidor de autorización (servidor de autenticación):
    para implementar el protocolo OAuth, la entidad propietaria del servidor de recursos, es decir, Google, debe proporcionar un servidor adicional, ya que Google aloja el recurso y tiene la responsabilidad de la seguridad.

En lugar de proporcionar la funcionalidad del servidor de autenticación en el propio servidor de recursos, se utiliza un servidor separado para aliviar la sobrecarga innecesaria en el servidor de recursos.

Flujo de proceso de OAuth:

El proceso de OAuth procede de la siguiente manera:

  1. El propietario del recurso solicita el servicio del cliente, en nuestro caso, la impresión de fotografías.
  2. El cliente se pone en contacto con AuthServer para solicitar un recurso, es decir, fotos en los servidores de Google. El servidor de autenticación envía un aviso al propietario del recurso preguntando sobre la solicitud que recibió del cliente en forma de ventana de inicio de sesión de Google.
  3. El usuario confirma los servicios solicitados por el cliente y otorga autorización al servidor de autenticación en nombre del cliente. Esto proporciona acceso delegado al Cliente.
  4. El servidor de autenticación recibe una solicitud de autorización del propietario del recurso.
  5. En la autenticación y confirmación del propietario del recurso, el servidor de autenticación envía al cliente un token de acceso que le permite acceder a los recursos requeridos alojados en el servidor de recursos.
  6. El cliente proporciona el token de acceso al servidor de recursos.
  7. En la validación del token de acceso , el recurso se proporciona al cliente.
  8. Finalmente, el usuario puede acceder a los servicios del Cliente que pueden acceder a los recursos protegidos en nombre del usuario.

El flujo detallado anteriormente se conoce como flujo implícito . En algunos flujos de OAuth, en lugar de proporcionar directamente al cliente un token de acceso, el servidor de autenticación puede proporcionar al cliente un token de autorización intermediario . Para acceder al recurso, el cliente primero debe proporcionar el token de autorización al servidor de autenticación y solicitar un token de acceso. Este flujo de OAuth se conoce como flujo de código de autorización.

El inconveniente de proporcionar directamente el token de acceso (flujo implícito) es que el token de acceso puede ser utilizado por partes no autorizadas. El flujo de código de autorización es más seguro ya que el mecanismo de intercambio de tokens de acceso se puede proteger mediante el token de autorización.

El flujo implícito es más adecuado para tokens de acceso de corta duración que se usan con aplicaciones de JavaScript.

Publicación traducida automáticamente

Artículo escrito por tabmir y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *