OAuth 2.0 es un framework de autorización estándar de la industria que permite a una aplicación cliente obtener acceso delegado y limitado a los recursos de un usuario (Resource Owner) alojados en un servidor de recursos (Resource Server), a través de un servidor de autorización (Authorization Server). No es un protocolo de autenticación, sino de autorización. Define varios 'grant types' (flujos de autorización) como 'Authorization Code', 'Implicit', 'Resource Owner Password Credentials' y 'Client Credentials', cada uno adecuado para diferentes escenarios de cliente y seguridad. El proceso generalmente implica que el cliente redirija al usuario al Authorization Server para que este apruebe el acceso, tras lo cual el cliente recibe un 'access token' que puede usar para interactuar con el Resource Server en nombre del usuario.
En el mundo real, OAuth 2.0 es omnipresente. Es la base de la funcionalidad 'Login with Google', 'Login with Facebook' o 'Sign in with Apple' que vemos en innumerables aplicaciones web y móviles. Servicios como GitHub, Twitter, Spotify y Salesforce lo utilizan para permitir que aplicaciones de terceros accedan a los datos de los usuarios (por ejemplo, listar repositorios, publicar tweets, gestionar playlists) sin que el usuario tenga que compartir sus credenciales directamente con la aplicación de terceros. También es fundamental en arquitecturas de microservicios para la autorización entre servicios, donde un servicio puede actuar como cliente para acceder a recursos de otro servicio.
Para un arquitecto, OAuth 2.0 es crucial para diseñar sistemas seguros y escalables que interactúen con terceros o que necesiten delegar acceso de forma granular. La elección del 'grant type' adecuado es una decisión de diseño crítica que impacta directamente la seguridad y la experiencia del usuario; por ejemplo, el 'Authorization Code Grant' con PKCE es preferido para clientes públicos (SPA, móviles) sobre el 'Implicit Grant' por sus mayores garantías de seguridad. Entender los roles (Resource Owner, Client, Authorization Server, Resource Server) y los flujos de tokens (access tokens, refresh tokens) es vital para implementar una autorización robusta, gestionar la revocación de tokens y proteger contra ataques como la suplantación de identidad o la fuga de tokens. Además, la integración con OpenID Connect (OIDC) extiende OAuth 2.0 para la autenticación, proporcionando una capa de identidad sobre el framework de autorización.