La primera imagen muestra cómo un usuario con su dispositivo, a través de una aplicación móvil (por ejemplo, un cliente de correo electrónico) de una empresa desconocida, desea consultar los correos electrónicos (Resources) de, por ejemplo, un servidor de Google (Resource Server). Para llevar a cabo la operación, el usuario debe introducir dentro de la aplicación móvil sus credenciales de Google. Sin embargo, todo esto conlleva ciertos riesgos, ya que a) el cliente de correo electrónico puede guardar la contraseña y b) la aplicación puede usar la contraseña para, por ejemplo, acceder a otros servicios de Google.
OAuth (Open Authorization) es un protocolo abierto que permite una autorización de API estandarizada y segura para aplicaciones de escritorio, web y móviles.
Un usuario final (user o Resource Owner) puede, con ayuda de este protocolo, permitir que una aplicación (Client o Third-Party) acceda a sus datos (autorización), los cuales son proporcionados por otro servicio (Resource Server), sin revelar al Client detalles confidenciales de sus credenciales (autenticación). De este modo, el usuario final puede encargar a terceros que consuman un servicio en su nombre. Típicamente se evita la transmisión de contraseñas a terceros. [wikipedia]
Antes de que el dispositivo pueda realizar cualquier solicitud al servidor OAuth, primero debe registrarse. Tras el registro, el dispositivo recibe en el endpoint /auth un código de autorización. Para ello, el dispositivo debe enviar, entre otros, su Client-ID (que utilizó durante el registro) al servidor OAuth. Ejemplo: https://server.com/auth?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=email&state=1234zyx
| https://server.com/auth | Endpoint de autenticación del servidor |
|---|---|
| response_type=code | Especifica que la aplicación desea recibir un código de autenticación (grant). |
| client_id | ID del dispositivo que se utilizó para el registro en el servidor OAuth. |
| redirect_url | A esta página se redirigirá al usuario tras la autenticación exitosa. |
| scope | Aquí el dispositivo indica a qué recursos, p.ej. correos electrónicos, quiere acceder. |
Antes de emitir el código de autorización, el servidor OAuth se pone en contacto con el propietario de los archivos o correos electrónicos. Para asegurarse de que se trata de la persona correcta, éste debe autenticarse primero introduciendo sus credenciales. Para ello, se le redirige a una página de inicio de sesión.
Una vez comprobado que se trata de la persona correcta, el propietario recibe una lista de todos los recursos a los que el Client desea acceder, por ejemplo, correos electrónicos. El propietario debe confirmar esta solicitud.
Sólo ahora el servidor OAuth genera el código de autorización (NO un token), que envía al Client. Este código representa al propietario y la autorización de acceso a los correos electrónicos. El código de autorización sólo es válido durante unos minutos.
Ahora el Client puede llamar al endpoint /token, autenticarse primero y enviar el código de autorización previamente recibido al servidor OAuth.
A continuación se validan las credenciales del cliente y el
código de autorización. Si ambas informaciones son correctas, se genera un ‘Access Token’ y se envía al Client. La aplicación de correo electrónico es responsable del almacenamiento seguro del token.
A continuación el Client solicita los correos electrónicos al ‘Resource Server’. Sin embargo, el servidor debe primero asegurarse de que, durante ese tiempo, el cliente sigue autorizado para consultar los correos electrónicos.
Por ello, el ‘Resource Server’ pregunta al ‘OAuth Server’ si el token sigue siendo válido.
A continuación, se informa al ‘Resource Server’ sobre el estado de la validación.
Y sólo en este punto se transfieren los correos electrónicos al Client.
Licencia de la imagen:
“Designed by Freepik”
“Designed by macrovector / Freepik”
“Designed by rawpixel.com / Freepik”