La autorización abierta, comúnmente conocida como OAuth, es un protocolo estándar que proporciona a las aplicaciones la capacidad de «acceso designado seguro».

A través de OAuth, las aplicaciones pueden acceder a los recursos en nombre de un usuario, sin necesidad de compartir las credenciales de usuario, a diferencia de otros métodos de autenticación como MEJORES SMS por Proveedores de servicios OTP.

Entender OAuth en términos sencillos

Para entender OAuth en términos más sencillos, imagina un escenario en el que quieres permitir que un sitio web de terceros, como ESPN, acceda a tu perfil de Facebook o publique actualizaciones en tu cronología. Normalmente, tendrías que proporcionarle a ESPN tu contraseña de Facebook.

Pero con OAuth, ESPN puede acceder a tu perfil sin que tengas que compartir tu contraseña. Esto minimiza drásticamente el riesgo de que tu contraseña quede expuesta en caso de que se produzca una violación de seguridad por parte de ESPN.

Este es un ejemplo de un mundo sin OAuth: -

Una mirada más cercana a OAuth

OAuth es esencialmente un protocolo de autorización, no un protocolo de autenticación. Proporciona tokens de autorización para demostrar la identidad entre los consumidores y los proveedores de servicios. OAuth facilita que una aplicación interactúe con otra en tu nombre, sin tener que compartir tu contraseña.

La evolución de OAuth

OAuth se lanzó como estándar abierto en 2010, bajo la RFC 5849, y rápidamente obtuvo una adopción generalizada. Dos años más tarde, se sometió a una importante revisión y OAuth 2.0 se publicó en 2012 como RFC 6749. A pesar de las críticas, OAuth 2.0 tuvo un uso aún más generalizado, y empresas importantes como Amazon, Facebook, Instagram, LinkedIn, Microsoft, Netflix y PayPal se unieron a la lista de adoptantes.

El funcionamiento interno de OAuth

OAuth funciona según el principio de los roles, que son componentes fundamentales de un sistema OAuth. Entre estas funciones se incluyen las siguientes:

1. Propietario del recurso: Este es el usuario o el sistema que posee los recursos protegidos y puede conceder acceso a estos recursos. ‍
2. Cliente: Este es el sistema que necesita acceder a los recursos protegidos. Para acceder a estos recursos, el cliente debe poseer el token de acceso apropiado. ‍
3. Servidor de autorización: Este servidor gestiona las solicitudes de tokens de acceso del cliente y las emite una vez que el propietario del recurso realiza correctamente la autenticación y el consentimiento. ‍
4. Servidor de recursos: Este servidor protege los recursos del usuario y recibe solicitudes de acceso del cliente. Acepta y valida un token de acceso del cliente y, a continuación, devuelve los recursos apropiados.

El concepto de ámbitos en OAuth

Los ámbitos son una parte integral de OAuth. Se utilizan para especificar el motivo por el que se puede conceder el acceso a los recursos. Los valores de alcance aceptables y los recursos con los que se relacionan dependen del servidor de recursos.

Tokens de acceso y código de autorización de OAuth 2.0

En OAuth 2.0, el servidor de autorización puede devolver un código de autorización en lugar de devolver directamente un token de acceso después de que el propietario del recurso haya autorizado el acceso.

A continuación, este código se cambia por un token de acceso. Para mayor seguridad, el servidor de autorización también puede emitir un token de actualización con el token de acceso.

¿Cómo funciona OAuth?

En el nivel más básico, antes OAuth 2.0 se puede utilizar, el Cliente debe adquirir sus propias credenciales, un ID de cliente, y secreto del cliente, desde el servidor de autorización. Esto es para identificarse y autenticarse al solicitar un token de acceso.

OAuth frente a OpenID

OAuth y OpenID a menudo se intercambian, pero tienen diferentes propósitos. Mientras que OAuth se basa en la autorización, OpenID se basa en la autenticación. OpenID verifica la identidad del usuario, mientras que OAuth proporciona una autorización delegada segura, de terceros, como agente de usuario.

OAuth frente a SAML

El lenguaje de marcado para aserciones de seguridad (SAML) es otra tecnología que se compara con frecuencia con OAuth. El SAML describe un marco que permite a un equipo realizar tanto la autenticación como la autorización en nombre de uno o más equipos. OAuth, por otro lado, requiere una capa adicional, como OpenID Connect, para realizar la autenticación.

OAuth 2.0

OAuth 2.0 es un rediseño completo de OAuth 1.0, ya que las dos versiones son incompatibles. OAuth 2.0 es más rápido y fácil de implementar. Proporciona seis flujos para diferentes tipos de aplicaciones y requisitos y permite firmar secretos a través de HTTPS.

¿Es seguro OAuth?

Si bien OAuth es ampliamente aceptado y utilizado, no está exento de vulnerabilidades. Una de las principales críticas a OAuth 2.0 es que el estándar intencionadamente no define ni admite directamente el cifrado, la firma, la verificación de clientes o la vinculación de canales.

Depende de los implementadores para usar un protocolo de protección externo como Transport Layer Security (TLS) para proporcionar esas funciones.

Algunas alternativas a OAuth son MEJORES SMS y otros métodos como los que se consideran futuro de la autenticación.

Conclusión

A pesar de sus limitaciones, OAuth ha supuesto un punto de inflexión al facilitar el acceso sin problemas a múltiples aplicaciones mediante un único conjunto de credenciales. Ha allanado el camino para una autorización delegada segura, dirigida por terceros y mediante agentes de usuario, lo que facilita a los usuarios la interacción con múltiples aplicaciones web. A medida que el panorama digital siga evolucionando, no cabe duda de que OAuth seguirá desempeñando un papel fundamental en la forma en que accedemos a las aplicaciones web e interactuamos con ellas.