OAuth: una rápida visión general

OAuth es, con diferencia, el protocolo de autorización más utilizado en las aplicaciones web. Si formas parte de este mundo de las integraciones, es prácticamente imposible no haber tratado con él. Por eso he decidido crear este contenido y compartir parte de la inmersión que he realizado en los últimos meses. 

¿Qué es OAuth?

Es un protocolo de autorización donde, de manera simple y estandarizada, permite que el cliente (aplicaciones) acceda a un recurso protegido en nombre del usuario. Es un marco de seguridad que describe cómo otorgar acceso a los datos del usuario en una aplicación, a través del protocolo HTTP.

Roles

Estos son los roles que tendrá cada entidad durante un flujo de autorización. Los principales son:

• Resource Owner: Entidad capaz de autorizar el acceso a un recurso protegido. Si es una persona, se le puede llamar usuario final.
• Resource Server: Servidor que aloja los recursos protegidos. Por ejemplo, una API.
• Authorization Server: OAuth Server es el servidor que proporciona acceso a un recurso protegido en nombre del usuario. Aquí es donde se validan los flujos y se generan los tokens.
• Client: Aplicación que quiere acceder a los recursos privados del propietario del recurso.

Grant Types

Estos son los flujos de autorización utilizados para autorizar a un cliente a acceder a los recursos privados del servidor de recursos en nombre del resource owner. En OAuth 2.0 se contemplan 4 tipos de concesión:

• Client Credentials;
• Authorization Code;
• Implicit Flow;
• Password Grant.

Bearer Tokens

Es un tipo de token de acceso. Es una cadena opaca, es decir, sin información autocontenida. Se puede pasar a través del encabezado en una solicitud HTTP (forma más común). Si se usa el método POST, se puede pasar en el cuerpo de la solicitud, o si se usa el método GET en la cadena de consulta. Ex token: c0ce7f40-e12b-393e-bb7c-5ad1fc3c9841.

JWT

Los tokens web JSON no son solo un tipo de token de acceso, también son una cadena. Sin embargo, se diferencia del bearer token en que contiene información independiente y debe estar firmado y cifrado. Es un token transparente. Está estructurado en 3 partes. Encabezado, que informa el algoritmo de encriptación utilizado y el tipo de token. El payload, que es el propio dato, donde se pasa información relevante y nunca sensible (reclamos), y el tail, que es donde se verifica y firma. Vea el ejemplo a continuación:

OAuth 2.1

OAuth 2.0 es de 2012 (RFC 6749), y muchas cosas han cambiado desde entonces. Popularización de javascript, varios tipos de ataques, inyecciones y formas de interceptación y mucho más. Por lo tanto, se necesitaban algunos cambios y es por eso que existe el proyecto OAuth 2.1 (RFC pendiente al momento de la publicación). Los principales cambios son:

• Flujo de código de autorización con PKCE(RFC 7636)
• Interrupción de flujos Implicit y Password
• No pasar el token en la cadena de consulta (solo en el encabezado o cuerpo de un POST)

Entonces, formulando, los tipos de concesión de OAuth 2.1 son Client Credentials y Authorization Code + PKCE. Y el token (ya sea opaco o transparente) lo pasa solo a través del encabezado o en el cuerpo de una solicitud POST:

En la segunda parte veremos cómo funciona el flujo Client Credentials y Authorization Code + PKCE, qué flujo se recomienda usar para cierto tipo de aplicación y más.  

¡Gracias por leer y hasta pronto!

‍