Security Tokens in System Architecture

Security Tokens & Identity Orchestration As systems transition from monoliths to microservices, traditional session-based authentication often fails to scale. In distributed environments, we require federated identity —where identity is verified in one location and trusted by many independent services. 1. The Standard: JWT (JSON Web Token) A JWT is an open standard ( RFC 7519 ) for creating access tokens that assert a number of claims between two parties. It is the backbone of stateless authentication. Anatomy of a JWT A JWT consists of three base64-url encoded parts separated by dots ( . ): Header: Defines the token type (JWT) and the signing algorithm (e.g., HMAC SHA256). Payload: Contains the "claims"—the actual user data (e.g., user_id , permissions , exp for expiration). Signature: Created by hashing the Header and Payload with a Secret Key known only to the server. Important: JWTs are encoded, not encrypted . Never put sensitive PII (like passwords or social security numbers) inside the payload, as anyone who intercepts the token can decode the payload base64 string. 2. The Framework: OAuth2 OAuth2 is an authorization framework that enables an application to obtain limited access to user accounts on an HTTP service (e.g., "Login with Google" or "Allow App X to read your GitHub repositories"). The Core Concept: Delegated Access OAuth2 allows a user to grant an application (the Client ) permission to access resources hosted by another service (the Resource Server ) without ever sharing their actual username or password with that application. Key OAuth2 Roles Resource Owner: The user who owns the data. Client: The application requesting access. Authorization Server: The server that validates the user and issues the Access Token (e.g., Google or Auth0). Access Token: The "key" that the client uses to talk to the Resource Server. 3. The Identity Layer: OpenID Connect (OIDC) While OAuth2 is for Authorization (what you can do), OpenID Connect (OIDC) is an identity layer built on top of OAuth2 for Authentication (who you are). The OIDC Difference OIDC adds an ID Token to the standard OAuth2 flow. While the OAuth2 Access Token is for API access, the OIDC ID Token is a JWT containing specific profile information about the user (name, email, profile picture) formatted in a standardized way. OAuth2: "Here is a token that lets you access my photos." OIDC: "Here is a token that proves I am John Doe, and here is my email address." 4. Permission Logic: RBAC (Role-Based Access Control) RBAC is the standard methodology for managing enterprise-level permissions. Instead of assigning permissions to every individual user, you assign permissions to Roles , and then assign users to those roles. The Structural Hierarchy Permissions: Granular actions (e.g., read:report , delete:node , write:log ). Roles: Bundles of permissions (e.g., ADMIN has all permissions; EDITOR has read and write ; VIEWER has only read ). Users: The entities assigned one or more roles. Production Tip: Always define permissions at the Action level , not the Role level. A role is just a container; the system logic should only ever check if a user possesses the required Action permission, making it easy to swap roles without rewriting core business logic. Security Tokens & Access Framework Reference Matrix Protocol / Vector Primary Operational Focus Primary Security Function Production Data Payload JWT Stateless Identity Assertion Ensures payload integrity via cryptographic signature. Claims (User ID, Expiry, Roles). OAuth2 Delegated Authorization Grants scoped resource access without password sharing. Access Tokens (the "key"). OIDC Identity Authentication Proves user identity with standardized profile claims. ID Tokens (User metadata). RBAC Resource Permission Logic Manages access based on functional enterprise roles. Role-to-Permission mapping.