El OAuth 2.0 es un protocolo estándar de autorización que permite que aplicaciones accedan de modo limitado a la cuenta de un usuario en un servicio Web (HTTP), como la Web API Valuekeep CMMS.
El protocolo delega la autenticación del usuario al servicio que detiene la cuenta del usuario y autoriza el acceso de aplicaciones externas a esta cuenta del usuario. El protocolo ofrece flujos de autorización para aplicaciones Web, aplicaciones de escritorio y aplicaciones mobile.
A continuación, se describe el funcionamiento básico del protocolo en la perspectiva del desarrollador de una aplicación.
El protocolo define 4 roles (perfiles):
1. Resource owner: es el usuario que autoriza el acceso de la aplicación a su cuenta. Este acceso es limitado al ámbito de la autorización concedida por el usuario.
2. Client: es la aplicación que desea acceder a la cuenta del usuario.
3. Resource server: corresponde al servidor que aloja las cuentas del usuario.
4. Authorization server: es el servidor que comprueba la identidad del usuario y asigna tokens de autorización al cliente (la aplicación).
Del punto de vista del desarrollador de una aplicación, la Web API que desea consumir cumple el perfil de resource server y el de authorization server. Por ello, suele combinarse los dos perfiles y llamarle Service (servicio) o simplemente API.
Típicamente el flujo de autorización de una aplicación externa sigue los siguientes pasos:
1. La aplicación pide autorización para acceder a los recursos del usuario.
2. Si el usuario ya ha autorizado la solicitud, la aplicación recibe un authorization grant.
3. La aplicación pide al authorization server un access token, presentando la identidad del usuario y el authorization grant.
4. Si la identidad de la aplicación está autenticada y el authorization grant es válido, el authorization server asignará un access token a la aplicación y el flujo de autorización es finalizado.
5. La aplicación pide un recurso específico al resource server y presenta el access token que obtuve anteriormente.
6. Si el access token es válido, el resource server devolverá el recurso pedido a la aplicación.
7. En realidad, el flujo real de autenticación depende del tipo de authorization grant usado, sin embargo, este es el flujo conceptual normal del OAuth. A continuación, se discuten los diversos authorization grants disponibles.
El tipo de grant usado depende del método de autorización que la aplicación desea usar y, por supuesto, de los métodos soportados por la Web API. Para trabajar con la Web API del Valuekeep CMMS deben usar el método de autorización Client Credentials.
Cuando un access token expira, su uso para realizar solicitudes a la API resultará en el error “Invalid Token Error”. En este momento, si un refresh token se ha incluido al generar el access token, puede ser usado para hacer un nuevo token de acceso al servidor.
Ejemplo de una solicitud de ese tipo: