Fundamentos de OAuth 2.0 y OIDC para autenticación y autorización [Parte 1 de 3].

Promotores y arquitectos simplemente no se pueden crear aplicaciones modernas sin toparse con problemas de autorización y autenticación.

OAuth 2.0 es un estándar de la industria para la "autorización delegada", que es la capacidad de proporcionar a una aplicación o cliente acceso a datos o funciones ofrecidos por otra aplicación o servicio. OAuth 2.0 se centra en la autorización y no es prescriptivo sobre la autenticación. OpenID Connect (OIDC) añade una capa de autenticación basada en estándares sobre OAuth 2.0.

Para ponerlo en contexto, Couchbase Sync Gateway admite varias formas de autenticación de clientes. Clientes podrían ser clientes de Couchbase Lite que sincronizan datos con la puerta de enlace de sincronización a través de Internet mediante un websocket basado en protocolo de réplicao pueden ser aplicaciones frontales web o móviles que acceden a la puerta de enlace de sincronización a través de la aplicación punto final REST público. Uno de los mecanismos de autenticación de clientes más populares de Couchbase Sync Gateway es OIDC.

En este post, vamos a cubrir los fundamentos de OAuth 2.0 y OIDC para la autenticación y autorización. Voy a discutir dos flujos comunes, a saber, la Flujo implícito y el Flujo de códigos de autorización. Una comprensión básica de los flujos debería proporcionarle los antecedentes suficientes para entender cómo utilizar la autenticación basada en OIDC en el contexto de la autenticación de clientes de Sync Gateway. En una próxima entrada del blog hablaremos de ello, así que permanezca atento.

Para entender OIDC, primero tenemos que entender OAuth 2.0. Esto se debe a que, como marco de autenticación, OIDC se basa en OAuth 2.0. Esto se debe a que, como marco de autenticación, OIDC se basa en OAuth 2.0.

Introducción a OAuth 2.0

OAuth 2.0 es una norma del sector para la autorización delegada, y hay una serie de Proveedores OAuth en el mercado.

Pensemos, por ejemplo, en el botón "Iniciar sesión con Facebook" que utilizan varias aplicaciones web y móviles. Para ello se utiliza OAuth 2.0.

He aquí una simplificado de lo que ocurre entre bastidores. A continuación describo lo que se denomina el Flujo de códigos de autorización. También existe la alternativa "Flujo implícito", que es más frecuente cuando se utiliza en el contexto de OIDC.

Requisitos previos

En primer lugar, la aplicación/cliente debe registrarse en el servidor de autorización. El proceso de registro da lugar a la generación de un client_id y un secreto_cliente que debe configurarse en la aplicación/cliente que solicita la autenticación.

• • Cuando el usuario (a.k.a., "Propietario de recursos" en lenguaje OAuth 2.0) hace clic en el botón Iniciar sesión con Facebook en su aplicación favorita, la aplicación envía un Solicitud de autorización a la URL de inicio de sesión del servidor de autorización. En nuestro ejemplo, el servidor de autorización es Facebook. La solicitud de autorización incluye una serie de parámetros. En aras de la brevedad, no voy a incluir la lista completa de parámetros que se pueden encontrar en RFC6749. Como mínimo, la solicitud debe incluir los siguientes parámetros:
    • client_id que identifica de forma exclusiva la aplicación ante el servidor de autorización
    • tipo_respuesta que debe especificarse como código indicando que el cliente espera un Código de Autorización
    • solicitud_uri que especifica la URL a la que el Servidor de Autorización debe redirigir el control tras la autenticación.
  • El servidor de autorización (Facebook) pide al usuario que introduzca su nombre de usuario y contraseña y (opcionalmente) que responda a una serie de preguntas de seguridad necesarias para autenticar al usuario.
  • Una vez autenticado, al usuario se le presenta (opcionalmente) un "formulario de consentimiento de recursos" en el que se enumera el conjunto de recursos de Facebook (como el perfil público del usuario) a los que la aplicación quiere acceder.
    • El conjunto de recursos presentados en el formulario de consentimiento se especifica mediante un alcance en la solicitud de autorización inicial al servidor de autorización.
  • Una vez que el usuario autoriza el acceso a los recursos solicitados, se le redirige de nuevo a la aplicación con un código de autorización.
    • La URL a la que el Servidor de Autorización redirige al usuario se especifica mediante la directiva redirect_uri que también se incluye en la solicitud de autorización inicial.
  • A continuación, la aplicación/cliente intercambia el código de autorización con el Servidor de Autorización para obtener un código de acceso (o ficha de actualización), pasando el client_id y secreto_cliente como parte de la solicitud.
  • A continuación, la aplicación puede acceder a los recursos solicitados en Facebook utilizando el token de acceso.

¿Le ha quedado claro? No se preocupe, volveremos a tratar este tema en el contexto de OIDC.

¿Qué es OpenID Connect (OIDC)?

El objetivo principal de OAuth 2.0 es autorización delegada. En otras palabras, como hemos visto antes, el objetivo principal de OAuth 2.0 es conceder a una aplicación acceso a datos que pertenecen a otra aplicación.

OAuth 2.0 no se centra en la autenticación y, como tal, cualquier implementación de autenticación que utilice OAuth 2.0 no es estándar. Ahí es donde entra OpenID Connect (OIDC). OIDC añade una capa de autenticación basada en estándares sobre OAuth 2.0.

El Servidor de Autorización en los flujos OAuth 2.0 asume ahora el papel de Servidor de identidad (o Proveedor de OIDC). El protocolo subyacente es casi idéntico a OAuth 2.0, salvo que el Servidor de Identidad entrega un Ficha de identidad (token de identidad) a la aplicación solicitante. El token de identidad es una forma estándar de codificar las afirmaciones sobre la autenticación del usuario. Hablaremos más sobre los tokens de identidad más adelante.

Describiré aquí dos flujos OIDC populares: Flujo Implícito y Flujo de Código de Autorización.

Requisitos previos

Para ambos flujos, la aplicación/cliente debe registrarse en el servidor de autorización. El proceso de registro da lugar a la generación de un client_id y un secreto_cliente que debe configurarse en la aplicación/cliente que solicita la autenticación.

Flujo implícito OIDC

La OIDC Flujo implícito es el más simple de los dos y se recomienda para su uso en Couchbase Lite autenticación de cliente con Sync Gateway que vamos a hablar más en mi próxima entrada del blog.

Una vez más, utilizaremos Iniciar sesión con Facebook como ejemplo para ilustrar el flujo.

• • Cuando el usuario hace clic en el botón Iniciar sesión con Facebook en su aplicación favorita, la aplicación envía una solicitud de autenticación a la URL de inicio de sesión del servidor de autorización o servidor de identidad. En nuestro ejemplo, el servidor de autorización es Facebook.
    • La solicitud de autenticación incluye una serie de parámetros. Por brevedad, no incluyo la lista completa de todos los parámetros que en la especificación OIDC. Como mínimo, la solicitud debe incluir los siguientes parámetros:
      • client_id que identifica de forma exclusiva la aplicación ante el servidor de autorización
      • tipo_respuesta que debe especificarse como id_token indicando que el cliente espera un ID Token.
      • alcance que debe contienen el openid además de una lista opcional de recursos a los que la aplicación solicita acceso
      • solicitud_uri que especifica la URL a la que la Autorización debe redirigir el control tras la autenticación.
  • A continuación, el servidor de identidad (Facebook) pide al usuario que introduzca su nombre de usuario y contraseña y (opcionalmente) que responda a una serie de preguntas de seguridad necesarias para autenticar al usuario.
  • Una vez autenticado, al usuario se le presenta (opcionalmente) un "formulario de consentimiento de recursos" en el que se enumera el conjunto de recursos de Facebook (como el perfil público del usuario) a los que la aplicación quiere acceder.
    • El conjunto de recursos presentados en el formulario de consentimiento se especifica a través de la opción alcance que se incluyó en la solicitud de autenticación inicial al servidor de autorización.
  • Una vez que el usuario autoriza el acceso a los recursos solicitados, se le redirige de nuevo a la aplicación con un icono Ficha de identidad y, opcionalmente, un código de acceso
    • La URL a la que el Servidor de Autenticación redirige al usuario se especifica mediante la directiva redirect_uri que también se incluye en la solicitud de autenticación inicial.
  • A continuación, la aplicación valida el token de identidad con arreglo a los criterios especificados en el campo Especificación OIDC y recupera la identidad del usuario autenticado.

Flujo de códigos de autorización OIDC

La OIDC Flujo de códigos de autorización es muy similar al flujo de código de autorización de OAuth 2.0 descrito anteriormente.

Una vez más, utilizaremos Iniciar sesión con Facebook como ejemplo para ilustrar el flujo.

• • Cuando el usuario hace clic en el botón Iniciar sesión con Facebook en su aplicación favorita, la aplicación envía una solicitud de autenticación a la URL de inicio de sesión del servidor de autorización o del servidor de identidad. En nuestro ejemplo, el servidor de autorización es Facebook.
    • La solicitud de autenticación incluye una serie de parámetros. En aras de la brevedad, no voy a incluir la lista completa de todos los parámetros que se pueden encontrar en Especificación OIDC. Como mínimo, la solicitud debe incluir los siguientes parámetros:
      • client_id que identifica de forma exclusiva la aplicación ante el servidor de autorización
      • tipo_respuesta que debe especificarse como código indicando que el cliente espera un Código de Autorización.
      • alcance que debe contienen el openid además de una lista opcional de recursos a los que la aplicación solicita acceso
      • solicitud_uri que especifica la URL a la que la Autorización debe redirigir el control tras la autenticación.
  • A continuación, el servidor de identidad (Facebook) pide al usuario que introduzca su nombre de usuario y contraseña y (opcionalmente) que responda a una serie de preguntas de seguridad necesarias para autenticar al usuario.
  • Una vez autenticado, al usuario se le presenta (opcionalmente) un "formulario de consentimiento de recursos" en el que se enumera el conjunto de recursos de Facebook (como el perfil público del usuario) a los que la aplicación quiere acceder.
    • El conjunto de recursos presentados en el formulario de consentimiento se especifica a través de la opción alcance que también se incluye en la solicitud de autenticación inicial al servidor de autorización.
  • Una vez que el usuario autoriza el acceso a los recursos solicitados, se le redirige de nuevo a la aplicación con un icono Código de autorización
    • La URL a la que el Servidor de Autorización redirige al usuario se especifica mediante la directiva redirect_uri que también se incluye en la solicitud de autorización inicial.
  • A continuación, la aplicación/cliente intercambia el código de autorización con el Servidor de Autorización para obtener un Ficha de identidad y un Access Token opaco, pasando el client_id y secreto_cliente como parte de la solicitud.
  • A continuación, la aplicación valida el token de identidad con arreglo a los criterios especificados en el campo Especificación OIDC y recupera la identidad del usuario autenticado.

Token web JSON (JWT)

Un elemento clave de OIDC es el token de identidad, que es un token de seguridad que codifica las demandas de autenticación sobre un usuario en un formato estándar denominado Token web JSON (JWT). El JWT está firmado digitalmente.

Una "claim" es una afirmación sobre el usuario. Este es un ejemplo de un JWT con un conjunto típico de afirmaciones.

• • sub es el usuario al que se refiere el JWT
  • iss es el emisor del JWT que también firma el JWT
  • aud es el destinatario de la ficha
  • iat es la marca de tiempo emitida
  • exp es la fecha de expiración
  • amr se refiere al método de autenticación utilizado para emitir tokens

Más recursos

jwt.io es muy útil para decodificar y verificar un JWT.

En Parque infantil OIDC y OAuth de Okta es un gran recurso para probar los flujos sin llegar a implementarlos.

El futuro

En este post describimos los fundamentos de OpenID Connect (OIDC) y los flujos de OAuth 2.0. En el post de la próxima semana, hablaremos de la autenticación basada en OIDC en el contexto de la autenticación de clientes de Sync Gateway. Permanezca atento.

Si tiene alguna pregunta o sugerencia, deje un comentario a continuación o envíeme un correo electrónico. priya.rajagopal@couchbase.com. En Foros de Couchbase son otro buen lugar al que dirigirse con preguntas.
 

Póngase al día con el resto de entradas de esta serie sobre autenticación y autorización: