Autenticación

La API usa Amazon Cognito como proveedor de identidad. El API Gateway valida el JWT con un Cognito authorizer antes de invocar la Lambda: si el token falta, es inválido o expiró, la respuesta es un 401 que ni siquiera llega al código de la aplicación.

Flujo

1. Registro — POST /register crea el usuario en Cognito y su perfil en DynamoDB.
2. Login — POST /login con email y password devuelve los tokens:

{
  "message": "Login successful",
  "tokens": {
    "idToken": "eyJraWQi...",
    "accessToken": "eyJraWQi...",
    "refreshToken": "eyJjdHki...",
    "expiresIn": 3600
  },
  "user": { "id": "uuid", "email": "usuario@ejemplo.com" }
}

3. Cada request autenticado manda el token en el header Authorization:

Authorization: Bearer <idToken>

¿idToken o accessToken?

El authorizer de API Gateway está configurado con identity_source = Authorization contra el user pool: acepta el idToken (que además trae los claims de perfil). El frontend (lade-app) guarda el token en localStorage bajo la key token.

4. Expiración — los tokens duran expiresIn segundos (3600 por defecto). Con token expirado la API responde 401 con {"error": "Token Expired", ...}; el cliente debe renovar sesión (re-login o refresh token).

Endpoints públicos (sin auth)

Endpoint	Por qué
GET /ping	Health check
POST /register	Aún no existe el usuario
POST /login	Es el que emite el token
POST /billing/webhook	Lo llama Stripe; se valida con la firma Stripe-Signature, no con JWT

Todo lo demás requiere Authorization: Bearer <token>.

Identidad dentro de la Lambda

Las lambdas obtienen el usuario del contexto que inyecta el authorizer — el sub del JWT es el userId:

user_id = event['requestContext']['authorizer']['claims']['sub']

Nunca se confía en un userId mandado por el cliente para identificar al llamador.

Pool de conductores (app móvil)

Existe un segundo user pool de Cognito exclusivo para conductores, con su propio authorizer (lade-{env}-api-cognito-drivers-authorizer). Los endpoints de la app de conductores validan contra ese pool — un token del pool principal no funciona ahí, y viceversa.

Autorización por rol (dentro del equipo)

Pasar el authorizer solo prueba quién eres. Cada Lambda valida después qué puedes hacer según tu membresía y rol en el equipo (OWNER, ADMIN, USER) — ver Multi-tenancy. Si no eres miembro del equipo del recurso: 403.