Client Credentials Flow

El tipo de otorgamiento de credenciales del cliente proporciona a la aplicación una forma de acceder a su propia cuenta.
Si una aplicación desea actualizar, leer o crear información en su cuenta puede hacerlo a través de la API.
Este flujo representa el caso en el que la aplicación pertenece al usuario, por lo que no hay necesidad de que éste se autentique ni ayude de forma alguna al servidor de autenticación a decidir
si el acceso para esa aplicación está garantizado.

¿Cómo funciona?

El siguiente es un diagrama simplificado del flujo Client Credentials con la explicación correspondiente de cada paso.

1 - La aplicación solicita llevar adelante una acción sobre sus datos protegidos en el resource server

El frontend de la aplicación solicita llevar adelante una acción sobre sus recursos.
Para eso necesita un token de acceso.

2 - Solicitud de un token de acceso

El backend  pasa a gestionar el pedido de un token de acceso ya que es quien conoce las credenciales correspondientes de la aplicación.
Solicita un token de acceso al Auth server efectuando la siguiente petición.

Ejemplo:

POST /oauth/token HTTP/1.1
Host: {{base_url}}
Content-Type: application/json
Content-Length: 141

{
    "grant_type": "client_credentials",
    "client_id": "{{client_id}}",
    "client_secret": "{{client_secret}}"
    "scope": "api_orders_post"
}

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 “client_credentials”.

• 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.

• scope
  Es el alcance que quiere obtener la aplicación sobre los recursos protegidos del usuario.
  Acepta un "*" o "api_orders_post" como se ve en el ejemplo.

3 - Respuesta con access token.

El servidor de autenticación comprueba que las credenciales enviadas por la aplicación en la solicitud son correctas y emite un access token.

Ejemplo:

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

{
"token_type":"Bearer",
"expires_in":1625231197,
"access_token":"xxxxxxxxxxxxxxxxxxx"
}

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.

4 - Petición con token de acceso

La aplicación efectúa una petición al resource server para llevar adelante alguna acción sobre sus recursos enviando el token de acceso en la cabecera.

Ejemplo:

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

5 - Respuesta del Resource server.

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

6 - 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 estén 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.