Identity and Access

Identity management and access control in distributed architectures: authentication, authorization, JWT, OAuth2, and models like RBAC.

Why identity is the first pillar of security

In any distributed system, the first question that must be answered on every request is: who are you and what can you do? Without solid identity and access management, the rest of the security measures lose their meaning.

Identity is not just “login and password.” It’s a complete system that covers how credentials are verified, how permissions are represented, how access decisions propagate between services, and how they get revoked when necessary.

Authentication vs authorization

These two concepts are frequently confused, but they are distinct responsibilities:

Authentication (AuthN)

Answers the question: who are you?

• Verifies the identity of the user or service
• Relies on credentials: password, token, certificate, biometrics
• Produces an identity artifact (typically a token)
• Happens once at the start of the session (or when the token is renewed)

Authorization (AuthZ)

Answers the question: what can you do?

• Verifies the permissions of the authenticated user
• Relies on roles, permissions, policies, or attributes
• Is evaluated on every operation that requires access
• Can be as simple as a role or as complex as attribute-based policies

Usuario → [Autenticación] → "Eres Juan, rol: editor"
Juan → [Autorización] → "¿Puede Juan editar este recurso?" → Sí/No

JSON Web Tokens (JWT)

JWT is the most widely used standard for representing identity claims in distributed architectures.

Structure of a JWT

A JWT has three parts separated by dots:

header.payload.signature

{
  "header": {
    "alg": "RS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "user-456",
    "email": "maria@ejemplo.com",
    "role": "admin",
    "permissions": ["read:users", "write:users", "read:orders"],
    "iat": 1705312200,
    "exp": 1705314000,
    "iss": "auth-service",
    "aud": "api-gateway"
  }
}

Important claims

Advantages of JWT in microservices

• Stateless: each service can verify the token without querying a central database
• Propagation: the token travels in the Authorization header between services
• Self-contained: it includes all the information needed to make access decisions

Risks and mitigations

• Stolen token: use short expiration times (15–30 minutes)
• Stale claims: the token may carry permissions that have already been revoked; use refresh tokens and revocation lists
• Excessive size: avoid including unnecessary data in the payload

OAuth 2.0

OAuth 2.0 is an authorization framework that allows third-party applications to access resources on behalf of a user, without exposing their credentials.

Main flows

Authorization Code (with PKCE)

The most secure flow, recommended for web and mobile applications:

sequenceDiagram
    participant U as Usuario
    participant App as Aplicación
    participant AS as Authorization Server
    participant API as Resource Server

    U->>App: Clic en "Iniciar sesión"
    App->>AS: Redirect a /authorize (+ code_challenge)
    AS->>U: Muestra pantalla de login
    U->>AS: Ingresa credenciales
    AS->>App: Redirect con authorization code
    App->>AS: POST /token (code + code_verifier)
    AS-->>App: Access token + refresh token
    App->>API: Request con access token
    API-->>App: Datos protegidos

Client Credentials

For service-to-service communication, with no user involved:

Servicio A → POST /token (client_id + client_secret) → Access token
Servicio A → Request a Servicio B con access token

When to use OAuth 2.0

• Integration with external identity providers (Google, GitHub, Azure AD)
• Applications that need to access APIs on behalf of the user
• Scenarios where explicit user consent is required

Access control models

RBAC — Role-Based Access Control

The most common model. Permissions are assigned to roles, and roles are assigned to users.

Usuario → Rol → Permisos

Ejemplo:
  María → admin → [crear_usuario, eliminar_usuario, ver_reportes]
  Juan  → editor → [editar_contenido, ver_reportes]
  Ana   → viewer → [ver_reportes]

Advantages: easy to understand, easy to audit, sufficient for most applications.

Limitations: doesn’t handle conditional permissions well (“can edit only their own resources”).

ABAC — Attribute-Based Access Control

Permissions are evaluated based on attributes of the user, the resource, and the context:

Política: "Un usuario puede editar un documento SI:
  - usuario.departamento == documento.departamento
  - Y documento.estado != 'publicado'
  - Y hora_actual está dentro del horario laboral"

Advantages: extremely flexible, handles complex cases.

Limitations: harder to implement, audit, and debug.

Practical recommendation

Start with RBAC. Only move to ABAC if you have conditional access requirements that RBAC can’t solve. Many systems combine both: RBAC for the base structure and ABAC rules for specific cases.

Identity propagation between services

In a microservices architecture, identity must propagate from service to service:

Frontend → API Gateway → BFF → Servicio A → Servicio B
           [verifica]   [propaga JWT]  [propaga JWT]

Propagation strategies

1. Token passthrough: the same user JWT is passed between services. Simple, but the token may carry more permissions than needed.

2. Token exchange: each service requests a new token with reduced scope for the next service. More secure but more complex.

3. Service mesh with mTLS: the service’s identity is verified at the network level, while the user’s identity travels in the JWT. This combines both layers.

Best practices

• Centralize authentication in a dedicated service (Auth Service or Identity Provider)
• Use short-lived tokens with refresh tokens
• Don’t store tokens in localStorage — use httpOnly cookies or memory
• Implement token revocation for cases of compromise
• Log all authentication events for auditing
• Always use HTTPS — never transmit credentials in plain text
• Apply the principle of least privilege: each service and user only has the permissions it needs

Summary

Identity and access management is the foundation on which all of a system’s security is built. JWT provides a stateless mechanism for propagating identity between services, OAuth 2.0 standardizes authorization flows, and models like RBAC and ABAC define how access decisions are made. The key is to design these mechanisms from the start, not bolt them on as an afterthought.