What Is OAuth?

Crear nuevas cuentas para todos los diferentes sitios web siempre ha sido problemático. La mayoría de ellas son trabajos redundantes, ya que todas contienen la misma información del usuario, como el nombre y el número de teléfono.

"¿Es posible permitir que una aplicación acceda a mis datos sin necesariamente darle mi contraseña?"

OAuth es un estándar que intenta resolver este problema al proporcionar autorización centralizada.

OAuth, que significa "Autorización Abierta", es un estándar abierto para la delegación de acceso. Te permite (a los propietarios de recursos) compartir información entre aplicaciones y sitios web sin exponer tus contraseñas. Es ampliamente utilizado, y probablemente uses servicios de OAuth a diario. Por ejemplo, para iniciar sesión en GeeksforGeek, puedes optar por iniciar sesión usando tu cuenta de Google. Al hacerlo, autorizas a GeeksforGeek a acceder a parte de la información en tu cuenta de Google, como el nombre de usuario, la foto de perfil, etc.

Historia de OAuth

El protocolo OAuth 1.0 se publicó como RFC 5849, una solicitud de comentarios informativa, en abril de 2010.

El protocolo OAuth 2.0 se publicó como RFC 6749, y el uso de tokens portadores de OAuth 2.0 se publicó como RFC 6750, en octubre de 2012.

Aunque se construyó sobre la experiencia de implementación de OAuth 1.0, OAuth 2.0 es una reescritura completa de OAuth 1.0 desde cero, compartiendo solo objetivos generales y la experiencia general del usuario. OAuth 2.0 no es compatible con versiones anteriores de OAuth 1.0.

Cómo funciona OAuth 2.0

En el protocolo OAuth, en lugar de usar el nombre de usuario y la contraseña del propietario del recurso para acceder a recursos protegidos, el cliente usa un token de acceso. El cliente obtiene el token de acceso de un servidor de autorización tras la aprobación del propietario del recurso. Para que el propietario del recurso otorgue autorización al cliente, primero debe autenticarse en la aplicación. Y dado que la autenticación solo ocurrió entre el propietario del recurso y la aplicación, el cliente de terceros no puede conocer ninguna información privada del propietario del recurso.

Podemos ver que implementar el protocolo OAuth simplificará significativamente el proceso de autenticación del cliente de terceros. Todo lo que necesita hacer es obtener la autorización del usuario, solicitar el token de acceso, usarlo y obtener la información del usuario (recurso protegido). No requerirá que los nuevos usuarios registren cuentas ni expongan sus credenciales, reduciendo así la superficie de ataque y aumentando la seguridad de la red.

Vale la pena señalar que OAuth no es autenticación. El "Auth" aquí es autorización. El usuario no inicia sesión en la aplicación. Solo autoriza a la aplicación de terceros a obtener parte de su información.

Proceso de Autorización de OAuth

Roles

OAuth define cuatro roles:

Cliente - La aplicación que desea acceder a tus datos (propietario del recurso) y hacer solicitudes de recursos protegidos en nombre del propietario del recurso y con su autorización.

Propietario del recurso - Un usuario que posee los datos en el servidor de recursos, desea usar el servicio del cliente y tiene una cuenta en el servidor de autorización. Por ejemplo, yo soy el propietario del recurso de mi perfil de Facebook, y quiero usar el servicio de GeeksforGeeks.

Servidor de autorización - El motor principal de OAuth. Emite tokens de acceso al cliente después de autenticar con éxito al propietario del recurso y obtener la autorización.

Servidor de recursos - El servidor que almacena los datos que el cliente desea, capaz de aceptar y responder a solicitudes de recursos protegidos usando tokens de acceso.

Flujo del Protocolo OAuth

Paso A: La aplicación de terceros solicita autorización al usuario.

Paso B: La aplicación de terceros recibe una concesión de autorización, que es una credencial que representa la autorización del propietario del recurso.

Paso C: La aplicación de terceros solicita un token de acceso usando la concesión de autorización.

Paso D: El servidor de autorización autentica al cliente y valida la concesión de autorización; si es válida, emite un token de acceso a la aplicación de terceros.

Paso E: La aplicación de terceros usa el token de acceso para solicitar los recursos protegidos del servidor de recursos.

Paso F: El servidor de recursos valida el token de acceso y sirve la solicitud si es válida.

Código de Autorización y Token de Acceso

Hay cuatro tipos de concesión de autorización para obtener tokens de acceso de los servidores de autorización. Solo hablaremos del método de Código de Autorización aquí, ya que es el más seguro y común.

Paso A: La aplicación de terceros permite al usuario elegir un método de autorización, como GitHub, y luego redirige al usuario al servidor de autorización con parámetros como client_id y redirect_uri.

Ejemplo de solicitud:

    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

Paso B: El usuario inicia sesión y autoriza.

Paso C: El servidor de autorización redirige al usuario de vuelta al backend de la aplicación de terceros según el redirect_uri, proporcionando el código de autorización.

Ejemplo de respuesta:

     HTTP/1.1 302 Found
     Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
               &state=xyz

Paso D: La aplicación de terceros usa el código de autorización para intercambiarlo por el token de acceso del servidor de autorización.

Ejemplo de solicitud:

     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Paso E: El servidor de autorización valida y devuelve el token de acceso.

Ejemplo de respuesta del servidor de autorización:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

Un Ejemplo Concreto

Bob quiere imprimir de manera bonita sus pedidos de Amazon usando un software llamado Rabbit.

Propietario del recurso -> Bob

Cliente (aplicación de terceros) -> Software Rabbit

Servidor de autorización -> Servidor de autorización de Amazon

Servidor de recursos -> Bases de datos de Amazon para almacenar información de pedidos

Recursos protegidos -> Información de pedidos de Bob en Amazon

¿Por qué se deben obtener el Código de Autorización y el Token de Acceso por separado?

El código de autorización y el token de acceso se obtienen por separado para garantizar medidas de seguridad.

En el protocolo OAuth2, el código de autorización es un código temporal que el cliente intercambiará por un token de acceso. El código se obtiene del servidor de autorización, donde el usuario (propietario del recurso) tiene la oportunidad de ver qué información solicita el cliente y aprobar o denegar la solicitud.

Una vez que el usuario inicia sesión y autoriza con éxito, es redirigido de vuelta a la aplicación con un código de autorización temporal en la URL.

Este código de autorización generalmente es válido por diez minutos y solo una vez. El corto período de validez reduce el riesgo de filtrar información del usuario si es robado. En contraste, el período de validez de access_token es relativamente largo, generalmente de 1 a 2 horas. Si se filtra, puede representar un mayor peligro para la seguridad de los datos del usuario.

Además, para intercambiar por un token de acceso, el cliente necesitará proporcionar client ID y client secret además del código de autorización. El servidor de autorización necesita estos parámetros para autenticar al cliente y verificar que el que solicita el token de acceso es confiable. Si el código de autorización se filtra desafortunadamente, pero el hacker no tiene el client ID y client secret, aún no podrá obtener el código de acceso. Incluso si de alguna manera tiene el client ID y client secret, aún necesitará competir con el servidor del cliente, porque el código de autorización es de un solo uso. Este mecanismo aumenta significativamente la dificultad de posibles ataques. Si omitimos el paso de obtener el código de autorización y devolvemos el token de acceso directamente, el atacante podría usar el token de acceso para robar fácilmente la información del usuario.

OIDC (OpenID Connect)

¿Cuál es el propósito de usar OAuth para la autorización? Es obtener todo tipo de información sobre el usuario. ¿Por qué no podemos estandarizar la salida para que las aplicaciones de terceros puedan usarla directamente?

OIDC hace esta estandarización.

¿Cómo lo hace OIDC? En pocas palabras, devuelve un id_token adicional en formato JWT que contiene la información básica del usuario junto con el access token. Las aplicaciones de terceros pueden obtener la información del usuario verificando el algoritmo de firma y validando la firma en el id_token con una clave pública.

Además, OIDC proporciona el punto final UserInfo. Los servicios de terceros pueden usar el token de acceso para acceder a este punto final y obtener información adicional sobre el usuario.

Otra característica de OIDC es el Inicio de Sesión Único (SSO) y el Cierre de Sesión Único (SLO). SSO mejora la usabilidad al permitir que el usuario tenga sesiones autenticadas con diferentes clientes sin tener que proporcionar credenciales cada vez. Siempre que el usuario inicie sesión con éxito en una aplicación, no necesitará ingresar la contraseña nuevamente cuando inicie sesión en otras aplicaciones.

SLO mejora la seguridad al garantizar que no queden sesiones activas de una sesión SSO después de que el usuario inicie un cierre de sesión único. Los usuarios solo necesitan cerrar sesión una vez y todas las sesiones se terminan, evitando que sean secuestradas o mal utilizadas.

Vale la pena señalar que OIDC no está estandarizando un método de autenticación específico, como contraseñas o reconocimiento facial. En cambio, especifica cómo delegar la autenticación a un proveedor de autenticación centralizado, qué obtenemos después de la autenticación - id token, cómo se verifica este token - formato JWT, y qué información del usuario contiene este id token. Por lo tanto, las aplicaciones de terceros ya no necesitan reinventar la rueda.

Soporte de APISIX para OAuth/OIDC

Apache APISIX es una puerta de enlace API de código abierto nativa de la nube. Es una puerta de enlace API dinámica, en tiempo real y de alto rendimiento, y puedes usarla para manejar el tráfico tradicional norte-sur, así como el tráfico este-oeste entre servicios. También se puede usar como un controlador de entrada de k8s.

Dado que APISIX es una puerta de enlace API que actúa como un proxy para múltiples servidores de aplicaciones aguas arriba, es más natural colocar la autorización centralizada y la autenticación en la puerta de enlace API.

El plugin OpenID Connect (OIDC) de APISIX soporta el protocolo OpenID Connect. Los usuarios pueden usar este plugin para conectar APISIX con muchos proveedores de identidad (IdP), como Okta, Keycloak, Ory Hydra, Authing, etc., y desplegarlo como una puerta de enlace de autenticación centralizada. OIDC es un superconjunto de OAuth, por lo que este plugin también soporta OAuth.

Diagrama de despliegue:

Ejemplo de Configuración: Integrar Keycloak para Autenticación con Apache APISIX

Configurar Keycloak

Código de ejemplo

curl -XPUT 127.0.0.1:9080/apisix/admin/routes/1 -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -d '{
    "uri":"/anything/*",
    "plugins": {
        "openid-connect": {
            "client_id": "myclient",
            "client_secret": "e91CKZQwhxyDqpkP0YFUJBxiXJ0ikJhq",
            "discovery": "http://127.0.0.1:8080/realms/myrealm/.well-known/openid-configuration",
            "scope": "openid profile",
            "bearer_only": false,
            "realm": "myrealm",
            "redirect_uri": "http://127.0.0.1:9080/anything/callback",
            "logout_path": "/anything/logout"
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "httpbin.org:80":1
        }
    }
}'

Cuando visites http://127.0.0.1:9080/anything/test después de crear la API con éxito, serás dirigido a la página de inicio de sesión de Keycloak porque no has iniciado sesión:

Ingresa myuser como nombre de usuario y mypassword como contraseña, y serás dirigido a la siguiente página.

Visita http://127.0.0.1:9080/anything/logout para cerrar sesión:

Resumen

En resumen, el estándar OAuth es una solución popular tanto para aplicaciones como para usuarios. Proporciona conveniencia y seguridad al permitir que los usuarios utilicen servicios en múltiples plataformas sin compartir sus credenciales. Apache APISIX es una puerta de enlace API popular que soporta la integración de varios proveedores de identidad (Keycloak, Ory Hydra, Okta, Auth0, etc.) para proteger tus APIs.

Lee más sesiones:

• OIDC en Apache APISIX
• Usar Keycloak con la Puerta de Enlace API para Proteger APIs
• APISIX se integra con Ory Hydra
• Plugin openid-connect de APISIX