امنیتِ میکروسرویس: OAuth2/OIDC، JWT و RBAC/ABACMicroservice Security: OAuth2/OIDC, JWT & RBAC/ABAC

When you break a monolith into dozens of microservices, security breaks too. In the monolith you had one HttpSession, one front door, and behind it everything lived "inside the house" and trusted each other. In the microservice world that "trusted interior" assumption dies: each service is a separate process on a network where every packet can be sniffed or forged. This chapter is the full map of service-to-service security — from "who are you?" to "are you allowed to do this?" — with real Spring code and today's policy engines.

Our goal is to go from zero to senior judgment: not just flipping on a resource-server filter, but knowing why alg=none is a fatal hole, why a JWT can't truly be revoked, when to reach for ABAC and when for ReBAC, and how to hold a secret so that tomorrow's Git leak doesn't cost the team its head.

1) Authentication vs Authorization — two completely separate questions

That split is the heart of everything. Authentication answers "who are you?" and proves identity. Authorization answers "what are you allowed to do?" and applies permissions on top of that identity. The two happen at different layers, and the single biggest mistake junior teams make is fusing them at one point.

2) OAuth2 and OIDC — the delegated-access framework

Before any code, understand this: OAuth2 is not an authentication protocol at all; it's a framework for delegated authorization. It lets an application access a resource on your behalf without handing that application your password.

The OAuth2 roles

• Resource Owner: the data owner — usually a human user.
• Client: the app that wants to access the resource on the user's behalf (an SPA, or another service).
• Authorization Server (AS): verifies identity and issues tokens (Keycloak, Auth0, Okta, Spring Authorization Server).
• Resource Server (RS): the API that holds the data and validates tokens (your microservice).

The Authorization Code + PKCE flow

This is today's standard flow for user-facing apps (web, mobile, SPA). PKCE (Proof Key for Code Exchange, pronounced "pixy") adds a protection layer that neutralizes the "authorization-code interception" attack. In OAuth 2.1, PKCE is mandatory for all clients — not just mobile.

The mechanism is simple: the client generates a random code_verifier, sends its SHA-256 hash (code_challenge) in the first request, and at the end, during the code exchange, sends the raw code_verifier. The server re-computes the hash and compares. Even if an attacker steals the code, it's useless without the verifier.

Sequence diagram of the Authorization Code + PKCE flow / نمودار ترتیبی جریان Authorization Code + PKCE:

sequenceDiagram
    participant U as User (Browser)
    participant C as Client App
    participant AS as Authorization Server
    participant RS as Resource Server (API)
    C->>C: create code_verifier + code_challenge (S256)
    U->>C: click "Login"
    C->>AS: /authorize?code_challenge=...&scope=openid orders.read
    AS->>U: login + consent page
    U->>AS: authenticate (password / MFA)
    AS->>C: redirect back with authorization code
    C->>AS: /token (code + code_verifier)
    AS->>AS: verify hash(code_verifier) == code_challenge
    AS->>C: access_token (+ id_token + refresh_token)
    C->>RS: GET /orders  (Authorization: Bearer access_token)
    RS->>RS: validate JWT signature, iss, aud, exp
    RS->>C: 200 OK (data)

The Client Credentials flow — for machine-to-machine

When there's no user in the loop — say inventory service calling pricing service — there's no user to log in. Here the Client Credentials grant is used: the service itself obtains a token with its client_id and client_secret (or better, a private_key_jwt).

// A ServiceClient obtaining a token via client_credentials and calling another service
// Spring Security 6.5 — OAuth2 Client (servlet)
@Configuration
public class M2mClientConfig {

  @Bean
  OAuth2AuthorizedClientManager authorizedClientManager(
      ClientRegistrationRepository clients,
      OAuth2AuthorizedClientRepository authorizedClients) {
    OAuth2AuthorizedClientProvider provider =
        OAuth2AuthorizedClientProviderBuilder.builder()
            .clientCredentials()   // grant type = client_credentials
            .build();
    DefaultOAuth2AuthorizedClientManager manager =
        new DefaultOAuth2AuthorizedClientManager(clients, authorizedClients);
    manager.setAuthorizedClientProvider(provider);
    return manager;
  }
}

spring:
  security:
    oauth2:
      client:
        registration:
          pricing-client:
            provider: keycloak
            client-id: inventory-svc
            client-secret: ${INVENTORY_CLIENT_SECRET}   # from Vault, not a file!
            authorization-grant-type: client_credentials
            scope: pricing.read
        provider:
          keycloak:
            issuer-uri: https://auth.example.com/realms/prod

3) JWT — structure, validation, and pitfalls

JWT (JSON Web Token, pronounced "jot") is a self-contained token: everything needed to validate it lives inside it, with no database lookup per request. That is exactly what makes JWT attractive for stateless microservices.

Structure: three dot-separated parts

A JWT is three Base64URL parts separated by .: header.payload.signature.

eyJhbGciOiJSUzI1NiIsImtpZCI6ImsxIn0   ← Header  {"alg":"RS256","kid":"k1"}
.eyJzdWIiOiJhbGljZSIsImlzcyI6Imh0dHBz...   ← Payload {"sub":"alice","iss":"...","exp":...}
.NHVaYe26MbtOYhSKkoKYdFVomg4i8ZJd8_-R...   ← Signature

• Header: the signing algorithm (alg) and key id (kid).
• Payload: the claims. Standard ones: iss (issuer), sub (subject/user), aud (audience), exp (expiry), iat (issued at), nbf (not before), jti (unique token id).
• Signature: the cryptographic signature over the first two parts.

Validation in Spring — the resource server

In Spring, turning a microservice into a resource server is almost frictionless. You add the dependency and provide the issuer-uri; Spring fetches the public keys from the issuer's JWKS (JSON Web Key Set) endpoint itself.

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://auth.example.com/realms/prod
          # Spring auto-discovers JWKS via {issuer}/.well-known/openid-configuration

@Configuration
@EnableWebSecurity
@EnableMethodSecurity   // enables @PreAuthorize (prePostEnabled defaults to true)
public class ResourceServerConfig {

  @Bean
  SecurityFilterChain api(HttpSecurity http) throws Exception {
    http
      .authorizeHttpRequests(auth -> auth
        .requestMatchers("/actuator/health").permitAll()
        .requestMatchers(HttpMethod.GET, "/api/orders/**").hasAuthority("SCOPE_orders.read")
        .requestMatchers(HttpMethod.POST, "/api/orders/**").hasAuthority("SCOPE_orders.write")
        .anyRequest().authenticated())
      .oauth2ResourceServer(oauth2 -> oauth2
        .jwt(jwt -> jwt.jwtAuthenticationConverter(jwtAuthConverter())))
      // Stateless microservice: no session, no session-based CSRF
      .sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
      .csrf(csrf -> csrf.disable());
    return http.build();
  }
}

But the defaults are not enough. By default Spring checks exp, nbf, and iss, but it does not check aud (audience) unless you add it. This is a real security trap: if you don't check audience, a token issued for service A is accepted by service B too (token substitution).

// Add a custom validator for the audience
@Bean
JwtDecoder jwtDecoder(@Value("${spring.security.oauth2.resourceserver.jwt.issuer-uri}") String issuer) {
  NimbusJwtDecoder decoder = NimbusJwtDecoder.withIssuerLocation(issuer).build();

  OAuth2TokenValidator<Jwt> withIssuer = JwtValidators.createDefaultWithIssuer(issuer);
  OAuth2TokenValidator<Jwt> audienceValidator = new JwtClaimValidator<List<String>>(
      "aud", aud -> aud != null && aud.contains("orders-api"));

  decoder.setJwtValidator(new DelegatingOAuth2TokenValidator<>(withIssuer, audienceValidator));
  return decoder;
}

Role mapping is also on you. Keycloak puts roles under realm_access.roles, not in scope. You need a converter:

JwtAuthenticationConverter jwtAuthConverter() {
  JwtAuthenticationConverter conv = new JwtAuthenticationConverter();
  conv.setJwtGrantedAuthoritiesConverter(jwt -> {
    // take scopes (Spring default prefix: SCOPE_)
    var scopes = new JwtGrantedAuthoritiesConverter().convert(jwt);
    // plus Keycloak realm roles with a ROLE_ prefix
    Map<String, Object> realm = jwt.getClaim("realm_access");
    if (realm != null && realm.get("roles") instanceof Collection<?> roles) {
      roles.forEach(r -> scopes.add(new SimpleGrantedAuthority("ROLE_" + r)));
    }
    return scopes;
  });
  return conv;
}

Expiry, rotation, and revocation — the hardest part

JWT's self-contained nature has another sharp edge: revocation is nearly impossible. Once issued, a token is valid until its exp, even if you block the user or they change their password. The server doesn't check the database; it just looks at the signature and exp.

If you truly need instant revocation (e.g. "cut this user off right now"), you have three options:

1. jti denylist: keep revoked tokens' jti in Redis with a TTL equal to exp. Every resource server checks before accepting. Cost: one lookup per request — you're no longer fully stateless.
2. token versioning: keep a version number on the user profile and put it in the claim; on block, bump the version.
3. key rotation: on a wide breach, rotate the signing key so all old tokens die at once.

4) Token propagation and edge auth — from gateway to service depth

Now the question: where does the token enter the system, and how does it travel between services? The common pattern is authenticating at the edge (the API gateway), and then token propagation into the depths.

Edge authentication and token propagation topology / توپولوژی احراز لبه و انتشار توکن:

flowchart LR
    Client -->|Bearer JWT| GW[API Gateway]
    GW -->|validate + TokenRelay| OrderSvc[Order Service]
    OrderSvc -->|Bearer JWT propagated| PaymentSvc[Payment Service]
    OrderSvc -->|Bearer JWT propagated| InventorySvc[Inventory Service]
    GW -. JWKS .-> AS[(Authorization Server)]
    OrderSvc -. JWKS .-> AS
    PaymentSvc -. JWKS .-> AS

Token relay in Spring Cloud Gateway

When the gateway itself authenticates the user with oauth2Login() (say for a classic web app), the TokenRelay filter automatically forwards the user's access token downstream:

spring:
  cloud:
    gateway:
      default-filters:
        - TokenRelay=      # forwards the access token to all routes
      routes:
        - id: orders
          uri: lb://order-service
          predicates:
            - Path=/api/orders/**

mTLS and service-mesh identity

So far we've talked about authenticating the user. But how do services trust each other? Here mTLS (Mutual TLS) enters: in ordinary TLS only the server presents a certificate, but in mTLS both sides present certificates. So the payment service not only talks encrypted, but cryptographically proves "I really am payment."

Managing certificates by hand for hundreds of services is a nightmare. Here service mesh (Istio, Linkerd) and the SPIFFE/SPIRE standard come in:

• SPIFFE (Secure Production Identity Framework For Everyone): a standard that gives each workload a structured identity in the form of a URI like spiffe://prod.example.com/ns/payments/sa/payment-svc. This identity doesn't depend on IP or hostname, but on the workload itself.
• SPIRE: the runtime implementation of SPIFFE that issues these identities as short-lived X.509 certificates (called SVID, SPIFFE Verifiable Identity Document) and rotates them automatically.
• Istio ships SPIFFE-compliant identity natively: Istiod's internal CA issues X.509-SVIDs and establishes mTLS between all services transparently (with no application code change). mTLS overhead is typically just 1–2 milliseconds.

5) RBAC vs ABAC vs ReBAC — the heart of authorization

Now the deepest part: how do we decide a user may perform an action? Three big models exist, and the wrong choice builds years of technical debt.

RBAC — Role-Based Access Control

RBAC is the simplest: you give the user roles (ADMIN, EDITOR, VIEWER), and each role gets permissions. The decision is: "does the user have a role that allows this action?"

ABAC — Attribute-Based Access Control

ABAC decides based on attributes: the user's attribute (department=finance), the resource's attribute (owner=alice, classification=secret), and the environment's attribute (time, ip, device). The decision is a function of these attributes: "allow if user.department == resource.department and it's business hours."

ReBAC — Relationship-Based Access Control

ReBAC makes the decision based on a graph of relationships: "alice can edit this document, because she's an editor of the folder the document lives in." This is the model Google Zanzibar introduced, powering Drive, Calendar, and YouTube. Data is stored as relationship tuples: document:budget#editor@user:alice.

Comparison table:

Method security in Spring — @PreAuthorize

Spring Security supports @EnableMethodSecurity (which since Spring Security 6 replaces the old @EnableGlobalMethodSecurity, with prePostEnabled defaulting to true). With @PreAuthorize you can write both RBAC and simple ABAC using SpEL:

@Service
public class DocumentService {

  // Simple RBAC: ADMIN role only
  @PreAuthorize("hasRole('ADMIN')")
  public void deleteAll() { /* ... */ }

  // scope-based (from the JWT)
  @PreAuthorize("hasAuthority('SCOPE_documents.write')")
  public Document create(DocumentDto dto) { /* ... */ }

  // ABAC: the user must own the document (checking a resource attribute)
  @PreAuthorize("#doc.owner == authentication.name")
  public Document update(Document doc) { /* ... */ }

  // Combining role and attribute
  @PreAuthorize("hasRole('EDITOR') and #doc.department == authentication.principal.claims['department']")
  public Document edit(Document doc) { /* ... */ }

  // @PostAuthorize: filter the output after execution (careful: the method ran!)
  @PostAuthorize("returnObject.owner == authentication.name")
  public Document findById(Long id) { /* ... */ }
}

Policy engines — when SpEL isn't enough

When authz rules become complex, frequently changing, or shared across services (perhaps multiple languages), pull them out of the code and hand them to a policy engine. This is Policy as Code.

OPA (Open Policy Agent) is a general-purpose CNCF policy engine where you write policies in the Rego language. It usually runs as a sidecar beside each service; the service sends a JSON context and OPA returns allow/deny.

# policy: authz.rego  — a simple ABAC/ReBAC rule
package httpapi.authz

default allow := false

# admins get everything
allow if {
    input.user.roles[_] == "admin"
}

# a user can read their own document
allow if {
    input.method == "GET"
    input.resource.owner == input.user.id
}

# finance members during business hours can view finance reports (ABAC)
allow if {
    input.resource.type == "finance_report"
    input.user.department == "finance"
    input.time.hour >= 8
    input.time.hour < 18
}

Cedar (from AWS, 2023) is a purpose-built authorization policy language that supports RBAC, ABAC, and ReBAC together and focuses on analyzability and speed; AWS benchmarks report it tens of times faster than Rego in access scenarios. Unlike Rego, which is general-purpose, Cedar is deliberately scoped to authz so that policies can be formally analyzed.

// A Cedar policy — ReBAC + RBAC
permit(
  principal,
  action == Action::"editDocument",
  resource
)
when {
  resource.owner == principal ||
  principal in resource.editors        // relationship: member of the resource's editors
};

Zanzibar / OpenFGA / SpiceDB are for pure ReBAC at large scale. You define a model with relationships and store data as tuples, then ask a "check" query that traverses the graph.

Zanzibar-style ReBAC relationship graph / گراف روابط ReBAC به سبک Zanzibar:

flowchart TD
    U[user:alice] -->|member| G[group:engineering]
    G -->|editor| F[folder:specs]
    F -->|parent| D[document:api-design]
    U -->|viewer| D2[document:roadmap]
    Q{{"Check: can alice edit document:api-design?"}}
    Q -.follows.-> U
    Q -.->|yes: member→editor→parent| D

# OpenFGA model (conceptual) — relationships and their inheritance
# type document
#   relations
#     define parent: [folder]
#     define editor: [user, group#member] or editor from parent
#     define viewer: [user] or editor

6) The RBAC data model and token denylist — dual-dialect SQL

A lot of RBAC lives in the relational database: user, role, permission, and the join table. Since both Oracle and PostgreSQL are common in projects, I'll show the dialect differences separately.

The base RBAC schema (identical in both, with data-type differences):

-- PostgreSQL
CREATE TABLE app_user (
    id          BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    username    VARCHAR(100) NOT NULL UNIQUE,
    enabled     BOOLEAN      NOT NULL DEFAULT TRUE,
    created_at  TIMESTAMPTZ  NOT NULL DEFAULT now()
);
CREATE TABLE app_role (
    id    BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name  VARCHAR(64) NOT NULL UNIQUE      -- e.g. ADMIN, EDITOR
);
CREATE TABLE user_role (
    user_id BIGINT NOT NULL REFERENCES app_user(id),
    role_id BIGINT NOT NULL REFERENCES app_role(id),
    PRIMARY KEY (user_id, role_id)
);

-- Oracle (19c/23ai)
CREATE TABLE app_user (
    id          NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    username    VARCHAR2(100) NOT NULL UNIQUE,
    enabled     NUMBER(1)     DEFAULT 1 NOT NULL,   -- Oracle: native BOOLEAN only arrived in 23ai
    created_at  TIMESTAMP WITH TIME ZONE DEFAULT SYSTIMESTAMP NOT NULL
);
CREATE TABLE app_role (
    id    NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name  VARCHAR2(64) NOT NULL UNIQUE
);
CREATE TABLE user_role (
    user_id NUMBER NOT NULL REFERENCES app_user(id),
    role_id NUMBER NOT NULL REFERENCES app_role(id),
    PRIMARY KEY (user_id, role_id)
);

Querying a user's roles with string aggregation — here the dialect really differs:

-- PostgreSQL: STRING_AGG
SELECT u.username, STRING_AGG(r.name, ',' ORDER BY r.name) AS roles
FROM app_user u
JOIN user_role ur ON ur.user_id = u.id
JOIN app_role  r  ON r.id = ur.role_id
WHERE u.username = 'alice'
GROUP BY u.username;

-- Oracle: LISTAGG
SELECT u.username,
       LISTAGG(r.name, ',') WITHIN GROUP (ORDER BY r.name) AS roles
FROM app_user u
JOIN user_role ur ON ur.user_id = u.id
JOIN app_role  r  ON r.id = ur.role_id
WHERE u.username = 'alice'
GROUP BY u.username;

A jti denylist table (token revocation) — with an upsert that differs completely between dialects:

-- PostgreSQL: INSERT ... ON CONFLICT
INSERT INTO revoked_token (jti, revoked_at, expires_at)
VALUES ('a1b2c3', now(), now() + INTERVAL '15 minutes')
ON CONFLICT (jti) DO NOTHING;

-- Oracle: MERGE
MERGE INTO revoked_token t
USING (SELECT 'a1b2c3' AS jti FROM dual) s
   ON (t.jti = s.jti)
WHEN NOT MATCHED THEN
  INSERT (jti, revoked_at, expires_at)
  VALUES ('a1b2c3', SYSTIMESTAMP, SYSTIMESTAMP + INTERVAL '15' MINUTE);

7) Secrets management — Vault, Sealed Secrets, and safe patterns

Tokens, keys, client secrets, database passwords — all secrets. The biggest beginner security mistake is hard-coding a secret in code or committing it to Git. A secret that once entered Git history is there forever (even if you delete it later).

HashiCorp Vault is the industry's de-facto standard. Two key capabilities:

• Static secrets (KV): stores passwords encrypted and serves them with fine-grained access control and an audit trail.
• Dynamic secrets: this is the golden point — Vault can generate a short-lived database credential on the fly that expires by itself. The application never has a static database password; each time it gets a temporary, few-minute credential. If it leaks, it dies on its own.

# Spring Cloud Vault — secrets are injected as a property source
# bootstrap/application.yml
spring:
  cloud:
    vault:
      uri: https://vault.example.com:8200
      authentication: KUBERNETES       # authenticates with the pod's ServiceAccount, no static password
      kubernetes:
        role: order-service
      kv:
        enabled: true
        backend: secret
        default-context: order-service

// After injection, the secret is available like any ordinary property:
@Value("${db.password}")   // came from Vault, not a file
private String dbPassword;

In the Kubernetes world several patterns compete:

Wrap-up