EN esta tarea veremos los conceptos clave para entender OAuth, específicamente OAuth 2.0. Para hacer los conceptos más fáciles de entender, los explicaremos mediante un ejemplo: usar la app de móvil de una cafetería para pedir y pagar un café.
Resource Owner
El dueño del recurso es la persona o sistema que controla cierta información y puede autorizar a la aplicación a acceder a dicha información en su nombre. Este concepto es fundamental, ya que se centra en el contenido del usuario y su control. Por ejemplo, eres el dueño del recurso siendo un cliente de la cafetería, ya que puedes controlar la información de tu cuenta y darle permiso a la app para acceder a tus datos.
Client
El cliente puede ser una app móvil o una aplicación web del lado del servidor. Actúa como intermediario, pidiendo acceso a recursos y realizando las acciones que el dueño del recurso le permite. Por ejemplo, la aplicación web o móvil de la cafetería es el cliente. El cual necesita tu autorización para acceder a los detalles de tu cuenta, incluyendo la información de pago.
Servidor de Autorización
El servidor de autorización es responsable de emitir tokens de acceso al cliente después de haber autentificado exitosamente al dueño del recurso y haber obtenido su autorización. El servidor de autorización juega un papel crucial en el proceso OAuth asegurándose de que el cliente recibe el permiso sólo después de que se realice un consentimiento y autorización de usuario legítimos. Por ejemplo, el sistema de backend de la cafetería que maneja la autentificación y autorización es el servidor de autorización. Verifica tus credenciales y le da permiso (si son correctas) a la app para que acceda a tu cuenta.
Servidor de Recursos
El servidor que hostea los recursos protegidos puede aceptar y responder a las peticiones hacia estos recursos usando tokens. Este servidor se asegura de que sólo clientes autentificados y autorizados puedan acceder o manipular la información del dueño del recurso. Por ejemplo, sería la base de datos de la cafetería que guarda tu información de cuenta, historial de compra y detalles de pago. Responde a peticiones de la aplicación permitiéndole recuperar y modificar tu información.
Authorization Grant
El cliente usa una credencial representando la autorización del dueño del recurso para obtener un token de acceso. Los tipos primarios de permiso son: Authorization Code, Implicit, Resource Owner Password Credentials y Client Credentials. Por ejemplo, cuando inicias sesión en la app de la cafetería, se te da un permiso de autorización. La aplicación usa este permiso para darte un token de acceso desde el servidor de autorización.
Refresh Token
Una credencial que el cliente puede usar para obtener un nuevo token de acceso sin requerir que el dueño del recurso se re-autentifique. Los tokens de refresco, suelen tener un gran tiempo de vida y ofrecen una forma de mantener las sesiones del usuario sin interrupciones frecuentes de login. Por ejemplo, cuando tu token de acceso vence, la aplicación web usa el token de refresco para obtener un nuevo token de acceso para que no tengas que volver a loguearte.
Redirect URI
La URI a la que el servidor de autorización redirigirá al user-agent del dueño del recurso después de la aceptación o denegación de la autorización. Comprueba si el cliente para el que se ha pedido la respuesta es correcto. Por ejemplo, después de interactuar con la app de la cafetería e iniciar sesión, serás redirigido al servidor de autorización por la página de la app, conocida como URI de redirección para confirmar que has iniciado sesión exitosamente.
Scope
Scopes son un mecanismo para limitar los accesos de una aplicación a la cuenta de un usuario. Permiten al cliente especificar el nivel de acceso necesitado y al servidor de autorización informar al usuario sobre los niveles de acceso que la aplicación pide. El alcance (scope) ayuda a reforzar el concepto de los menos privilegios posibles. Por ejemplo, la app de la cafetería puede pedir diferentes scopes, como acceso a tu historial de compra e información de pago. Como dueño del recurso, puedes ver qué información pide la app y dar o denegar dichos permisos.
State Parameter
Un parámetro opcional mantiene el estado entre el cliente u el servidor de autorización. Puede ayudar a prevenir ataques CSRF asegurando que la respuesta coincide con la petición del cliente. El parameter state es una parte crucial de securizar el flujo OAuth. Por ejemplo, cuando inicias el proceso de login, la app de la cafetería manda un parameter state al servidor de autorización. Este parámetro ayuda a asegurar que la respuesta que recibes está vinculada a tu petición original, protegiendo contra cierto tipo de ataques.
Token & Authorization Endpoint
El endpoint del servidor de autorización es donde el cliente intercambia el permiso de autorización (o refresh token) por un token de acceso. Por el contrario, el endpoint de autorización es donde el dueño del recurso se autentifica y autoriza al cliente para acceder a recursos protegidos.