Seguridad

Cómo controla la API quién entra y a qué. Entenderlo ayuda a configurar bien los accesos y a diagnosticar los 401 y 403.

Autenticación: login y token#

La aplicación se identifica con usuario y contraseña en /api/login y recibe un token temporal. Ese token:

• dura lo que indique el tiempo de sesión del usuario,
• viaja en la cabecera Authorization: Bearer <token> en cada llamada posterior.

El token va ligado a la aplicación#

Cada token queda vinculado al User-Agent que hizo el login (el User-Agent es el texto con el que la aplicación se identifica al llamar). Si la aplicación cambia su User-Agent, el token deja de ser válido. Sirve para evitar que un token obtenido por una aplicación se reutilice desde otra.

Cada usuario, su propia firma#

No hay una clave global: cada usuario tiene su propia clave interna con la que se firma su token. Revocar o cambiar un usuario no afecta a los demás.

Autorización: tener token no es tener acceso#

El token solo dice quién eres. Cada llamada se comprueba además contra los permisos del usuario: deben coincidir el método, el tipo de extremo y el nombre del extremo (y el dispatcher, en las operaciones custom). Si no hay un permiso que case, la API responde 403. Se gestionan en Usuarios y permisos.

Revocar el acceso#

• Modificar el perfil de un usuario invalida todos sus tokens anteriores: es la forma de cortar el acceso de inmediato. Después, las aplicaciones deben volver a hacer login.
• Además, todo token caduca solo al superar el tiempo de sesión.

Buenas prácticas#

• Un User-Agent propio y estable por aplicación.
• Un tiempo de sesión ajustado a la necesidad (ni eterno, ni tan corto que moleste).
• Para SQL, un usuario de base de datos dedicado y con permisos mínimos (ver Instalación y puesta en marcha).