Refresh token Flow

Con el fin de que no siempre se estén transmitiendo los mismos datos (algunos de ellos sensibles), otro de los flujos que se nos proponen es el de Refresh Token.
Para ello necesitaremos haber obtenido un Access Token acompañado de un refresh_token.
Este campo solo es parte de la respuesta de en el flow de Authorization Code.

Así, usando este campo, después de que el token anterior haya caducado, podremos obtener otro token nuevo.
Eso sí, un refresh_token también. De esta forma no podremos generar un nuevo Access token acompañado nuevamente de un refresh token.

¿Cómo funciona?

El siguiente es un diagrama del flujo Refresh token flow el cual parte de un escenario en el cual
el backend ya tiene en su dominio un access token expirado y un un refresh token conseguido en un paso anterior, entonces los que vemos
es lo siguiente.

1 - La aplicación solicita llevar adelante una acción

Desde el frontend de la aplicación se solicita a su backend llevar adelante una acción sobre recursos protegidos.

2 - Petición del backend al Resource server con token expirado.

El backend intenta hacer una petición al resource server con un access token expirado.

Ejemplo:

GET /api/example HTTP/1.1
Host: http://resource-server.com
Authorization: Bearer {{access_token}}

3 - Respuesta del Resource server.

El Resource server intenta validar el access_token y arroja como resultado que el access_token esta expirado. 

Ejemplo:

GET http://resource-server.com/api/example HTTP/1.1
Authorization: Bearer {{access_token}}
HTTP/1.1 401 Unauthorized
Content-Type: application/json
Content-Length: 104

{
"error":"expired_token",
    "response":{
        "code":401,
        "title":"",
        "message":"expired_token",
        "terminalCode":""
    }
}

4 - Cambio de refresh token por un nuevo access token.

    El backend  gestiona un nuevo access token utilizando las credenciales de aplicación mas el refresh token.

Ejemplo:

POST /oauth/token HTTP/1.1
Host: {{base_url}}
Content-Type: application/json
Content-Length: 160
{
    "grant_type": "refresh_token",
    "client_id": "{{client_id}}",
    "client_secret": "{{client_secret}}",
    "refresh_token":"{{refresh_token}}"
}

Donde:

• base_url
  Consultar en la sección Ambientes/Auth Server

• grant_type
  Hace referencia al tipo de flow o concesión que se va a utilizar para obtener un token.
  Debe ser “refresh_token”.

• client_id
  Es el identificador único y público de la aplicación.

• client_secret
  Es la clave secreta de la aplicación relacionada al identificador público de la misma.

• refresh_token
  El refresh token es usado para generar un nuevo access token.

5 - Respuesta con token de acceso mediante el code.

El auth server valida las credenciales de la aplicación junto con el refresh token.
De ser correcta la información responde con un nuevo access token y refresh token.

Ejemplo:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 1335

{
"token_type":"Bearer",
"expires_in":1625152988,
"access_token":"xxxxxxxxxxxxx",
"refresh_token":"xxxxxxxxxxxxx"
}

Donde:

• token_type
  Es el formato del access_token.

• expires_in
  Es el tiempo que el access_token tendrá vigencia para su uso hasta quedar expirado.

• access_token
  Es un JWT que se usa para autorizar las peticiones a la API del resource server.

• refresh_token
  Es un token que sirve para conseguir un nuevo access_token cuando el mismo haya expirado.

6 - Solicitud de acceso a recursos protegidos mediante access token.

La aplicación realiza una acción en el resource server sobre recursos protegidos utilizando el access token.

Ejemplo de petición con access token:

GET /api/example HTTP/1.1
Host: http://resource-server.com
Authorization: Bearer {{access_token}}

7 - Respuesta del resource server a la aplicación.

El resource server responde con el status code correspondiente.
Si es el caso también tendrá información en body referida a la acción que se llevó adelante o el recurso consultado.

8 - Presentación de información.

La aplicación resuelve la petición presentando la información correspondiente.

Aclaraciones importantes.

• Bajo ningún punto se recomienda que credenciales de aplicación y tokens de acceso esten alojados del lado del cliente el cual sea de acceso público.
• Tanto las credenciales de aplicación como los tokens deben estar alojados en un backend server side siendo este el único responsable de tener conocimiento sobre este tipo de información.
• Todas las peticiones al Auth server y al Resource server deben ser siempre host to host.