{"id":960,"date":"2025-09-10T08:50:25","date_gmt":"2025-09-10T08:50:25","guid":{"rendered":"https:\/\/www.rajeshkumar.xyz\/blog\/?p=960"},"modified":"2025-09-10T08:51:23","modified_gmt":"2025-09-10T08:51:23","slug":"jwt-oidc-the-plain-english-guide-from-fundamentals-to-advanced","status":"publish","type":"post","link":"https:\/\/www.rajeshkumar.xyz\/blog\/jwt-oidc-the-plain-english-guide-from-fundamentals-to-advanced\/","title":{"rendered":"JWT & OIDC \u2014 The Plain-English Guide (from Fundamentals to Advanced)"},"content":{"rendered":"\n
\"\"\/<\/figure>\n\n\n\n
\n\n\n\n

\ud83e\udde9 JWT vs OIDC \u2014 Separate but Together<\/h1>\n\n\n\n

1. JWT (JSON Web Token)<\/strong><\/h2>\n\n\n\n
    \n
  • What it is<\/strong>: A token format (just a container for claims).<\/li>\n\n\n\n
  • What it looks like<\/strong>: header.payload.signature<\/code><\/li>\n\n\n\n
  • Who uses it<\/strong>: Both humans and<\/em> services.<\/li>\n\n\n\n
  • What it carries<\/strong>: Facts like:\n
      \n
    • sub<\/code> \u2192 who the token is about<\/li>\n\n\n\n
    • aud<\/code> \u2192 who the token is for<\/li>\n\n\n\n
    • exp<\/code> \u2192 when it expires<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

      \ud83d\udc49 JWT is like a passport card<\/strong> \u2014 it holds information and a signature that proves authenticity.<\/p>\n\n\n\n

      \n\n\n\n

      2. OIDC (OpenID Connect)<\/strong><\/h2>\n\n\n\n
        \n
      • What it is<\/strong>: A protocol (set of rules) built on top of OAuth2.<\/li>\n\n\n\n
      • Purpose<\/strong>: To let apps log users in and know who they are<\/em>.<\/li>\n\n\n\n
      • What it gives you<\/strong>:\n
          \n
        • ID Token<\/strong> \u2192 usually a JWT<\/strong> that says \u201cThis user is Alice, verified by Google\/Okta\/etc.\u201d<\/li>\n\n\n\n
        • Access Token<\/strong> \u2192 used to call APIs (sometimes also a JWT).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

          \ud83d\udc49 OIDC is like the border control process<\/strong> \u2014 the steps (passport check, stamps) that result in you getting that passport card (JWT)<\/strong> to travel with.<\/p>\n\n\n\n

          \n\n\n\n

          3. How they fit together<\/strong><\/h2>\n\n\n\n
            \n
          • JWT = the format<\/strong><\/li>\n\n\n\n
          • OIDC = the login protocol<\/strong> that issues JWTs<\/li>\n<\/ul>\n\n\n\n

            So:<\/p>\n\n\n\n

              \n
            • A user logs in via OIDC<\/strong>.<\/li>\n\n\n\n
            • The IdP (e.g., Google, Okta, Cognito) hands back an ID Token<\/strong>, which is a JWT<\/strong>.<\/li>\n\n\n\n
            • Your app or API validates the JWT.<\/li>\n<\/ul>\n\n\n\n
              \n\n\n\n

              4. Use cases side by side<\/strong><\/h2>\n\n\n\n
              Situation<\/th>What you use<\/th>Example<\/th><\/tr><\/thead>
              Human login<\/td>OIDC \u2192 issues JWT (ID Token)<\/strong><\/td>User signs in with Google \u2192 app gets ID Token JWT<\/td><\/tr>
              Service calling service<\/td>JWT directly (OAuth2 Client Credentials)<\/strong><\/td>Microservice A calls Microservice B using JWT access token<\/td><\/tr>
              API Gateway<\/td>Validates JWTs<\/strong> (from OIDC or service flows)<\/td>AWS API Gateway checks JWT from Cognito or Firebase<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              \n\n\n\n

              5. \ud83d\udd11 Key takeaway<\/h2>\n\n\n\n
                \n
              • JWT is a token format.<\/strong><\/li>\n\n\n\n
              • OIDC is a login protocol.<\/strong><\/li>\n\n\n\n
              • OIDC tokens are JWTs.<\/strong><\/li>\n\n\n\n
              • For users<\/strong> \u2192 OIDC (login flow) \u2192 JWTs.<\/li>\n\n\n\n
              • For services<\/strong> \u2192 JWTs (via OAuth2 or workload identity).<\/li>\n<\/ul>\n\n\n\n

                So yes \u2014 separate<\/strong> (format vs protocol), but always together<\/strong> in practice.<\/p>\n\n\n\n

                \n\n\n\n

                <\/p>\n\n\n\n

                <\/p>\n\n\n\n

                JWT & OIDC \u2014 The Plain-English Guide (from Fundamentals to Advanced)<\/h1>\n\n\n\n

                0) The 1-minute mental model<\/h2>\n\n\n\n
                  \n
                • JWT<\/strong> = a sealed card<\/strong> (digitally signed) that carries facts (\u201cwho\/what\/when\/permissions\u201d). Anyone with the issuer\u2019s public key<\/strong> can check it hasn\u2019t been altered.<\/li>\n\n\n\n
                • OIDC<\/strong> (OpenID Connect) = a login recipe for humans<\/strong> built on OAuth2. It tells apps how to log people in<\/strong> (redirects, consent) and returns an ID Token (a JWT)<\/strong> that says who the user is<\/em>.<\/li>\n\n\n\n
                • Access Token<\/strong> (often a JWT) = a permit<\/strong> you show to an API to prove what you\u2019re allowed to do.<\/li>\n\n\n\n
                • Refresh Token<\/strong> = a backstage pass<\/strong> the app uses to quietly get new access tokens without asking the user to log in again.<\/li>\n<\/ul>\n\n\n\n
                  \n\n\n\n

                  1) What is JWT?<\/h2>\n\n\n\n

                  A compact, URL-safe token format<\/strong>: header.payload.signature<\/code>.<\/p>\n\n\n\n

                    \n
                  • Header<\/strong>: the signing algorithm (e.g., RS256).<\/li>\n\n\n\n
                  • Payload<\/strong>: claims like sub<\/code> (subject\/user), aud<\/code> (audience), exp<\/code> (expiry).<\/li>\n\n\n\n
                  • Signature<\/strong>: proves the token was issued by the trusted issuer and not modified.<\/li>\n<\/ul>\n\n\n\n

                    Key property:<\/strong> self-contained. You can validate it offline<\/strong> using the issuer\u2019s public key (published via JWKS<\/strong> URL).<\/p>\n\n\n\n

                    \n\n\n\n

                    2) What is OIDC?<\/h2>\n\n\n\n

                    A standard way to log users in<\/strong> (web\/mobile) using OAuth2. It defines:<\/p>\n\n\n\n

                      \n
                    • ID Token (JWT)<\/strong> \u2192 proves who the user is<\/em> (identity).<\/li>\n\n\n\n
                    • UserInfo endpoint<\/strong> \u2192 optional place to fetch profile data.<\/li>\n\n\n\n
                    • Discovery document<\/strong> \u2192 where the app finds all endpoints & keys.<\/li>\n<\/ul>\n\n\n\n

                      OIDC \u2248 login flows; JWT \u2248 the token format OIDC uses for identity.<\/strong><\/p>\n\n\n\n

                      \n\n\n\n

                      3) Why do we need them?<\/h2>\n\n\n\n
                        \n
                      • Single Sign-On<\/strong> across apps, teams and even companies.<\/li>\n\n\n\n
                      • Zero shared secrets<\/strong> between every service\u2014verify tokens with public keys.<\/li>\n\n\n\n
                      • Stateless performance<\/strong>\u2014no per-request DB lookup needed to validate tokens.<\/li>\n\n\n\n
                      • Portable and interoperable<\/strong>\u2014works across clouds and languages.<\/li>\n<\/ul>\n\n\n\n
                        \n\n\n\n

                        4) Common use-cases<\/h2>\n\n\n\n

                        Human users (OIDC)<\/h3>\n\n\n\n
                          \n
                        • \u201cLogin with Google\/Okta\/Azure AD\/Keycloak\/Cognito.\u201d<\/li>\n\n\n\n
                        • Multi-app SSO (one login, many apps).<\/li>\n\n\n\n
                        • MFA, passwordless, social login.<\/li>\n<\/ul>\n\n\n\n

                          Service \u2194 Service (JWT)<\/h3>\n\n\n\n
                            \n
                          • One microservice calling another with a short-lived JWT<\/strong> (often from OAuth2 Client Credentials<\/strong>).<\/li>\n\n\n\n
                          • Jobs, webhooks, backends calling APIs without a human user.<\/li>\n<\/ul>\n\n\n\n

                            Mixed<\/h3>\n\n\n\n
                              \n
                            • User logs in (OIDC) \u2192 frontend calls your API with an access token (JWT)<\/strong>.<\/li>\n\n\n\n
                            • Backend calls downstream services using its own service JWT<\/strong>.<\/li>\n<\/ul>\n\n\n\n
                              \n\n\n\n

                              5) How they work (step by step)<\/h2>\n\n\n\n

                              A) OIDC \u201cAuthorization Code + PKCE\u201d (recommended for web\/SPAs\/mobile)<\/h3>\n\n\n\n
                                \n
                              1. User opens your app<\/strong> \u2192 \u201cSign in\u201d.<\/li>\n\n\n\n
                              2. App redirects<\/strong> the user to the Identity Provider (IdP)<\/strong> (e.g., Google\/Okta\/Keycloak\/Cognito\/Firebase).<\/li>\n\n\n\n
                              3. User authenticates (password, MFA, passkey).<\/li>\n\n\n\n
                              4. IdP redirects back<\/strong> with a code<\/strong>.<\/li>\n\n\n\n
                              5. Your app (or backend) exchanges the code<\/strong> at the IdP\u2019s Token Endpoint<\/strong> \u2192 gets:\n
                                  \n
                                • ID Token (JWT)<\/strong> = who the user is.<\/li>\n\n\n\n
                                • Access Token<\/strong> (often JWT) = what they can do.<\/li>\n\n\n\n
                                • Refresh Token<\/strong> (optional) for silent renewals.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                • App calls your APIs with the access token<\/strong> in Authorization: Bearer <token><\/code>.<\/li>\n\n\n\n
                                • APIs validate the token<\/strong> (issuer, audience, signature, expiry) and proceed.<\/li>\n<\/ol>\n\n\n\n
                                  \n

                                  PKCE<\/strong>: protects SPAs\/mobile apps by proving the app that started the login is the app finishing it.<\/p>\n<\/blockquote>\n\n\n\n

                                  B) Service-to-Service (OAuth2 Client Credentials)<\/h3>\n\n\n\n
                                    \n
                                  1. Service A<\/strong> asks the IdP\/Authorization Server for a token using its client id\/secret<\/strong> (or mTLS).<\/li>\n\n\n\n
                                  2. IdP issues a short-lived access token (JWT)<\/strong> with claims like aud<\/code>=ServiceB, scopes\/roles.<\/li>\n\n\n\n
                                  3. Service A calls Service B with Authorization: Bearer \u2026<\/code>.<\/li>\n\n\n\n
                                  4. Service B validates: signature<\/strong>, issuer<\/strong>, audience<\/strong>, exp<\/strong> (and optionally scope\/role<\/strong> claims).<\/li>\n<\/ol>\n\n\n\n

                                    C) Token validation (what every API should check)<\/h3>\n\n\n\n
                                      \n
                                    • Signature<\/strong>: verify with the issuer\u2019s JWKS<\/strong> public key.<\/li>\n\n\n\n
                                    • Issuer (iss<\/code>)<\/strong>: matches the IdP you trust.<\/li>\n\n\n\n
                                    • Audience (aud<\/code>)<\/strong>: matches your API<\/strong>.<\/li>\n\n\n\n
                                    • Expiry (exp<\/code>)<\/strong> and not before (nbf<\/code>)<\/strong>.<\/li>\n\n\n\n
                                    • Subject (sub<\/code>)<\/strong> present; optionally scope\/roles<\/strong> to authorize actions.<\/li>\n<\/ul>\n\n\n\n
                                      \n\n\n\n

                                      6) Advanced (without the jargon)<\/h2>\n\n\n\n
                                        \n
                                      • Scopes vs Roles vs Claims<\/strong>\n
                                          \n
                                        • Scopes<\/em> = what actions are allowed (e.g., read:orders<\/code>).<\/li>\n\n\n\n
                                        • Roles<\/em> = grouped permissions (e.g., admin<\/code>, editor<\/code>).<\/li>\n\n\n\n
                                        • Claims<\/em> = facts inside the token (email, org, roles, tenant).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                        • Key types<\/strong>\n
                                            \n
                                          • HS256<\/strong> (shared secret) \u2192 simple but you must protect the secret on every<\/strong> verifier.<\/li>\n\n\n\n
                                          • RS256\/ES256<\/strong> (public\/private keys) \u2192 issuer keeps private key<\/strong>, everyone else only needs public key<\/strong> (safer & common).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                          • Key rotation<\/strong>\n
                                              \n
                                            • IdP exposes JWKS<\/strong>. Your gateways\/servers should cache<\/strong> keys and auto-refresh<\/strong> (handle kid<\/code> changes seamlessly).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                            • Refresh tokens<\/strong>\n
                                                \n
                                              • Keep them server-side<\/strong> or in HTTP-only<\/strong> secure cookies (not localStorage).<\/li>\n\n\n\n
                                              • Rotate on use; revoke on breach.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                              • Opaque vs JWT access tokens<\/strong>\n
                                                  \n
                                                • Opaque<\/strong>: must call the issuer\u2019s introspection endpoint<\/strong> each time.<\/li>\n\n\n\n
                                                • JWT<\/strong>: validate offline; faster, but revocation is trickier.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                • Proof-of-Possession (DPoP\/mTLS)<\/strong>\n
                                                    \n
                                                  • Binds the token to a specific client key or TLS certificate \u2192 blocks token theft\/replay.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                  • Token exchange \/ impersonation<\/strong>\n
                                                      \n
                                                    • Trade one token for another (e.g., user token \u2192 service token limited to one API).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                    • Logout<\/strong>\n
                                                        \n
                                                      • Front-channel<\/strong> (browser) or back-channel<\/strong> (server-to-server) logout, plus session cookies invalidation and refresh token revocation.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                                                        \n\n\n\n

                                                        7) Limitations & gotchas (and how to avoid them)<\/h2>\n\n\n\n
                                                          \n
                                                        • Revocation is hard with JWT<\/strong>
                                                          Use short lifetimes<\/strong> (e.g., 5\u201315 min) + refresh tokens<\/strong>. Revoke refresh tokens on logout\/compromise.<\/li>\n\n\n\n
                                                        • Too many claims = big tokens<\/strong>
                                                          Keep tokens lean; fetch extra data from your user\/profile API when needed.<\/li>\n\n\n\n
                                                        • Audience\/issuer mismatches<\/strong>
                                                          Many 401s boil down to wrong aud<\/code> or iss<\/code>. Double-check both.<\/li>\n\n\n\n
                                                        • Clock skew<\/strong>
                                                          Allow 1\u20132 minutes skew on iat\/nbf\/exp<\/code>.<\/li>\n\n\n\n
                                                        • Storing tokens in the browser<\/strong>
                                                          Prefer HTTP-only secure cookies<\/strong> over localStorage (defense against XSS).<\/li>\n\n\n\n
                                                        • \u201calg: none\u201d \/ weak algorithms<\/strong>
                                                          Only accept expected algorithms (e.g., RS256). Never allow none<\/code>.<\/li>\n<\/ul>\n\n\n\n
                                                          \n\n\n\n

                                                          8) Where they fit in AWS, Google Cloud, Azure<\/h2>\n\n\n\n

                                                          AWS (Amazon)<\/h3>\n\n\n\n
                                                            \n
                                                          • Issuers \/ IdPs<\/strong>\n
                                                              \n
                                                            • Amazon Cognito User Pools<\/strong> (OIDC & OAuth2; issues ID\/Access\/Refresh tokens as JWTs).<\/li>\n\n\n\n
                                                            • IAM OIDC\/Federation<\/strong> (workload identity, GitHub Actions, IRSA for EKS).<\/li>\n\n\n\n
                                                            • External IdPs: Okta, Auth0, Keycloak, Google<\/strong> (federated to Cognito or directly to ALB\/API GW).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                            • Validators \/ Enforcement<\/strong>\n
                                                                \n
                                                              • API Gateway (HTTP API)<\/strong> \u2192 JWT Authorizer<\/strong> (validates issuer\/jwks\/audience).<\/li>\n\n\n\n
                                                              • Application Load Balancer<\/strong> \u2192 authenticate-oidc<\/strong> action (runs the OIDC login flow) with Cognito\/Okta\/Keycloak\/Google<\/strong> (note: not Firebase as an OIDC provider for ALB).<\/li>\n\n\n\n
                                                              • EKS<\/strong>: NGINX\/Kong\/Envoy\/Istio gateways can validate JWTs; IRSA<\/strong> uses OIDC to map pods to IAM roles.<\/li>\n\n\n\n
                                                              • CloudFront<\/strong>: integrates with Cognito\/custom auth at the edge (via Lambda@Edge).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

                                                                Google Cloud<\/h3>\n\n\n\n
                                                                  \n
                                                                • Issuers \/ IdPs<\/strong>\n
                                                                    \n
                                                                  • Identity Platform \/ Firebase Auth<\/strong> (OIDC\/OAuth2; issues ID tokens as JWTs).<\/li>\n\n\n\n
                                                                  • Google Workspace\/Cloud Identity<\/strong> for enterprise SSO.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                  • Validators \/ Enforcement<\/strong>\n
                                                                      \n
                                                                    • API Gateway<\/strong> \/ Cloud Endpoints<\/strong> \u2192 JWT\/OIDC validation in the gateway config.<\/li>\n\n\n\n
                                                                    • Cloud Run<\/strong>: private services trust Google-signed ID tokens<\/strong> (IAM); put Gateway in front to validate external JWT\/OIDC.<\/li>\n\n\n\n
                                                                    • IAP (Identity-Aware Proxy)<\/strong> for web access control.<\/li>\n\n\n\n
                                                                    • Load balancers<\/strong> + Cloud Armor<\/strong> (policy\/WAF) in front of Gateways\/Backends.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

                                                                      Microsoft Azure<\/h3>\n\n\n\n
                                                                        \n
                                                                      • Issuers \/ IdPs<\/strong>\n
                                                                          \n
                                                                        • Microsoft Entra ID (formerly Azure AD)<\/strong> and Entra ID B2C<\/strong> (OIDC\/OAuth2).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                        • Validators \/ Enforcement<\/strong>\n
                                                                            \n
                                                                          • API Management (APIM)<\/strong> \u2192 validate JWT (issuer\/jwks\/audience), add policies.<\/li>\n\n\n\n
                                                                          • App Service Authentication (\u201cEasyAuth\u201d)<\/strong> \u2192 offload OIDC login to Entra\/others.<\/li>\n\n\n\n
                                                                          • AKS<\/strong>: NGINX\/Kong\/Envoy\/Istio for JWT validation; Workload Identity<\/strong> uses OIDC to map pods to Azure managed identities.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                                                                            \n\n\n\n

                                                                            9) Quick recipes you can reuse<\/h2>\n\n\n\n

                                                                            \u2705 Human login (web\/app) \u2014 safest baseline<\/h3>\n\n\n\n
                                                                              \n
                                                                            • OIDC Authorization Code + PKCE<\/strong><\/li>\n\n\n\n
                                                                            • IDP: Cognito \/ Entra ID \/ Identity Platform (Firebase Auth) \/ Okta \/ Auth0 \/ Keycloak<\/li>\n\n\n\n
                                                                            • Store<\/strong> access\/refresh tokens in HTTP-only secure cookies<\/strong><\/li>\n\n\n\n
                                                                            • Rotate<\/strong> refresh tokens; short access token TTL (5\u201315 min)<\/li>\n<\/ul>\n\n\n\n

                                                                              \u2705 Service \u2192 Service<\/h3>\n\n\n\n
                                                                                \n
                                                                              • OAuth2 Client Credentials<\/strong> (mTLS if possible)<\/li>\n\n\n\n
                                                                              • Short TTL (5\u201310 min), audience-scoped to the target service<\/li>\n\n\n\n
                                                                              • Validate on the API: signature, iss<\/code>, aud<\/code>, exp<\/code>, scopes\/roles<\/li>\n<\/ul>\n\n\n\n

                                                                                \u2705 Ingress\/Gateway enforcement<\/h3>\n\n\n\n
                                                                                  \n
                                                                                • AWS: API Gateway JWT Authorizer<\/strong> or ALB OIDC<\/strong> (with Cognito\/Okta\/etc.)<\/li>\n\n\n\n
                                                                                • GCP: API Gateway<\/strong> (JWT\/OIDC) \u2192 Cloud Run (private)<\/li>\n\n\n\n
                                                                                • Azure: APIM<\/strong> JWT policy or EasyAuth<\/strong><\/li>\n<\/ul>\n\n\n\n
                                                                                  \n\n\n\n

                                                                                  10) Security checklist (copy\/paste)<\/h2>\n\n\n\n
                                                                                    \n
                                                                                  • Access tokens expire \u2264 15 minutes; refresh tokens rotate.<\/li>\n\n\n\n
                                                                                  • Validate signature, iss, aud, exp\/nbf<\/strong> on every API call.<\/li>\n\n\n\n
                                                                                  • Accept only<\/strong> the algorithms you expect (e.g., RS256).<\/li>\n\n\n\n
                                                                                  • Enforce least privilege<\/strong> with scopes\/roles.<\/li>\n\n\n\n
                                                                                  • Use PKCE<\/strong> for SPAs\/mobile.<\/li>\n\n\n\n
                                                                                  • Use HTTP-only secure cookies<\/strong> for tokens on the web.<\/li>\n\n\n\n
                                                                                  • Implement logout<\/strong> (revoke refresh tokens, clear cookies, end IdP session).<\/li>\n\n\n\n
                                                                                  • Monitor JWKS fetch\/rotation; handle kid<\/code><\/strong> changes.<\/li>\n\n\n\n
                                                                                  • Add WAF\/rate limits<\/strong> at your gateway\/load balancer.<\/li>\n\n\n\n
                                                                                  • Log token ID (jti<\/code>)<\/strong>, sub<\/code>, aud<\/code> (no sensitive data) for audits.<\/li>\n<\/ul>\n\n\n\n
                                                                                    \n\n\n\n

                                                                                    11) FAQ (super short)<\/h2>\n\n\n\n

                                                                                    Is JWT only for machines and OIDC only for humans?<\/strong><\/p>\n\n\n\n

                                                                                      \n
                                                                                    • JWT is a format<\/strong> used by both. OIDC is a login protocol<\/strong> for humans that uses JWT<\/strong> (ID Token).<\/li>\n<\/ul>\n\n\n\n

                                                                                      Do I need OIDC for service-to-service?<\/strong><\/p>\n\n\n\n

                                                                                        \n
                                                                                      • Usually no<\/strong>. Use OAuth2 Client Credentials<\/strong> (returns a JWT access token).<\/li>\n<\/ul>\n\n\n\n

                                                                                        Can I revoke a JWT immediately?<\/strong><\/p>\n\n\n\n

                                                                                          \n
                                                                                        • Not cleanly. Use short lifetimes<\/strong> + refresh token revocation<\/strong>. For high-risk actions, re-check with the IdP or use introspection.<\/li>\n<\/ul>\n\n\n\n

                                                                                          What\u2019s the difference between an ID Token and an Access Token?<\/strong><\/p>\n\n\n\n

                                                                                            \n
                                                                                          • ID Token<\/strong>: identity of the user (for your client).<\/li>\n\n\n\n
                                                                                          • Access Token<\/strong>: permission for an API (what can be done).<\/li>\n<\/ul>\n\n\n\n
                                                                                            \n\n\n\n

                                                                                            12) Your migration hint (EKS front door options)<\/h2>\n\n\n\n
                                                                                              \n
                                                                                            • Mirror GCP approach<\/strong>: AWS API Gateway (HTTP API) JWT Authorizer<\/strong> validating Firebase\/Auth0\/Okta\/Keycloak \u2192 VPC Link \u2192 EKS.<\/li>\n\n\n\n
                                                                                            • All inside EKS<\/strong>: ALB Ingress \u2192 in-cluster gateway (NGINX\/Kong\/Envoy) validates JWT<\/strong>.<\/li>\n\n\n\n
                                                                                            • ALB runs login<\/strong>: use Cognito\/Okta\/Keycloak\/Google<\/strong> for ALB OIDC<\/strong> (Firebase doesn\u2019t act as ALB\u2019s OIDC IdP).<\/li>\n<\/ul>\n\n\n\n
                                                                                              \n\n\n\n

                                                                                              let\u2019s expand that simple table into detailed workflows<\/strong> so you can see exactly what happens at each hop, for Human login (OIDC)<\/strong>, Service-to-Service (JWT)<\/strong>, and API Gateway validating JWTs<\/strong>.<\/p>\n\n\n\n

                                                                                              \n\n\n\n

                                                                                              \ud83d\udd04 Detailed Workflows<\/h1>\n\n\n\n
                                                                                              \n\n\n\n

                                                                                              1. \ud83d\udc64 Human Login (OIDC \u2192 issues JWT ID Token)<\/h2>\n\n\n\n

                                                                                              Actors<\/strong>: User, Application (frontend + backend), Identity Provider (Google, Okta, Cognito, Firebase, etc.), API<\/p>\n\n\n\n

                                                                                              Step-by-step<\/h3>\n\n\n\n
                                                                                                \n
                                                                                              1. User opens app<\/strong>\n
                                                                                                  \n
                                                                                                • User clicks “Sign in”.<\/li>\n\n\n\n
                                                                                                • App redirects them to the IdP (OIDC provider).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                • IdP Login Page<\/strong>\n
                                                                                                    \n
                                                                                                  • User enters username\/password, MFA, or social login.<\/li>\n\n\n\n
                                                                                                  • IdP authenticates them.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                  • Authorization Code issued<\/strong>\n
                                                                                                      \n
                                                                                                    • After login, IdP redirects back to app with a code<\/strong> (short-lived, single use).<\/li>\n\n\n\n
                                                                                                    • This avoids exposing tokens in browser URL.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                    • App exchanges code for tokens<\/strong>\n
                                                                                                        \n
                                                                                                      • App\/backend calls IdP Token Endpoint<\/strong> with:\n
                                                                                                          \n
                                                                                                        • The code<\/li>\n\n\n\n
                                                                                                        • Client ID\/secret<\/li>\n\n\n\n
                                                                                                        • PKCE verifier (for extra security in mobile\/SPAs)<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                        • IdP responds with:\n
                                                                                                            \n
                                                                                                          • ID Token (JWT)<\/strong> \u2192 \u201cUser is Alice\u201d<\/li>\n\n\n\n
                                                                                                          • Access Token (JWT\/opaque)<\/strong> \u2192 \u201cAlice can call API X\u201d<\/li>\n\n\n\n
                                                                                                          • Refresh Token<\/strong> (optional).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                          • App calls API with Access Token<\/strong>\n
                                                                                                              \n
                                                                                                            • Authorization: Bearer <access_token><\/code>.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                            • API validates Access Token<\/strong>\n
                                                                                                                \n
                                                                                                              • Check signature (using IdP\u2019s JWKS keys).<\/li>\n\n\n\n
                                                                                                              • Check claims (iss<\/code>, aud<\/code>, exp<\/code>).<\/li>\n\n\n\n
                                                                                                              • Enforce scopes\/roles.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                              • API returns response<\/strong>\n
                                                                                                                  \n
                                                                                                                • If valid, API serves data \u2192 app \u2192 user.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n

                                                                                                                  \u2705 Key JWT role here<\/strong>: OIDC issues an ID Token (JWT)<\/strong> for identity, and an Access Token<\/strong> (often JWT) for authorization.<\/p>\n\n\n\n

                                                                                                                  \n\n\n\n

                                                                                                                  2. \ud83d\udd17 Service-to-Service (JWT directly, OAuth2 Client Credentials)<\/h2>\n\n\n\n

                                                                                                                  Actors<\/strong>: Service A (caller), Service B (target API), Identity Provider \/ Authorization Server<\/p>\n\n\n\n

                                                                                                                  Step-by-step<\/h3>\n\n\n\n
                                                                                                                    \n
                                                                                                                  1. Service A needs to call Service B<\/strong>\n
                                                                                                                      \n
                                                                                                                    • Example: Payment service \u2192 Order service.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                                    • Service A requests token<\/strong>\n
                                                                                                                        \n
                                                                                                                      • Calls IdP\u2019s Token Endpoint with:\n
                                                                                                                          \n
                                                                                                                        • client_id<\/code>, client_secret<\/code> (or mTLS certificate).<\/li>\n\n\n\n
                                                                                                                        • Grant type: client_credentials<\/code>.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                                        • IdP issues Access Token (JWT)<\/strong>\n
                                                                                                                            \n
                                                                                                                          • Payload includes:\n
                                                                                                                              \n
                                                                                                                            • iss<\/code> (issuer = IdP)<\/li>\n\n\n\n
                                                                                                                            • aud<\/code> (audience = Service B)<\/li>\n\n\n\n
                                                                                                                            • sub<\/code> (subject = Service A)<\/li>\n\n\n\n
                                                                                                                            • exp<\/code> (expiry, e.g., 5 mins)<\/li>\n\n\n\n
                                                                                                                            • scope<\/code> (permissions like orders:read<\/code>).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                                            • Service A calls Service B<\/strong>\n
                                                                                                                                \n
                                                                                                                              • HTTP request with Authorization: Bearer <access_token><\/code>.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                                              • Service B validates token<\/strong>\n
                                                                                                                                  \n
                                                                                                                                • Retrieves IdP\u2019s JWKS keys.<\/li>\n\n\n\n
                                                                                                                                • Verifies signature, expiry, audience = Service B.<\/li>\n\n\n\n
                                                                                                                                • Enforces scopes (only allowed actions).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                                                • Service B responds<\/strong>\n
                                                                                                                                    \n
                                                                                                                                  • Request succeeds if valid.<\/li>\n\n\n\n
                                                                                                                                  • Otherwise returns 401 Unauthorized<\/code>.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n

                                                                                                                                    \u2705 Key JWT role here<\/strong>: The JWT itself is the service identity<\/em>. No human involved.<\/p>\n\n\n\n

                                                                                                                                    \n\n\n\n

                                                                                                                                    3. \ud83c\udf10 API Gateway validates JWT (edge enforcement)<\/h2>\n\n\n\n

                                                                                                                                    Actors<\/strong>: Client (user or service), API Gateway (AWS API Gateway \/ GCP API Gateway \/ Azure APIM \/ NGINX\/Kong), Backend service<\/p>\n\n\n\n

                                                                                                                                    Step-by-step<\/h3>\n\n\n\n
                                                                                                                                      \n
                                                                                                                                    1. Client sends request<\/strong>\n
                                                                                                                                        \n
                                                                                                                                      • Attaches Authorization: Bearer <token><\/code> (could be user OIDC token or service JWT).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                                                      • Gateway receives request<\/strong>\n
                                                                                                                                          \n
                                                                                                                                        • Gateway is configured with issuer<\/strong> and JWKS URI<\/strong>.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                                                        • Gateway validates JWT<\/strong>\n
                                                                                                                                            \n
                                                                                                                                          • Check signature<\/strong> against IdP\u2019s public keys.<\/li>\n\n\n\n
                                                                                                                                          • Check issuer<\/strong> matches trusted IdP.<\/li>\n\n\n\n
                                                                                                                                          • Check audience<\/strong> claim matches the API.<\/li>\n\n\n\n
                                                                                                                                          • Check expiry<\/strong>.<\/li>\n\n\n\n
                                                                                                                                          • Optionally check scopes\/roles<\/strong>.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                                                          • If valid<\/strong> \u2192 forward request to backend.\n
                                                                                                                                              \n
                                                                                                                                            • Adds headers (like X-User-Id<\/code>, X-Scopes<\/code>) if configured.<\/li>\n\n\n\n
                                                                                                                                            • Backend trusts Gateway because it knows only validated requests get through.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                                                                                                            • If invalid<\/strong> \u2192 reject at Gateway.\n
                                                                                                                                                \n
                                                                                                                                              • Return 401 Unauthorized<\/code> (or 403 Forbidden<\/code>).<\/li>\n\n\n\n
                                                                                                                                              • Backend never sees bad traffic.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n

                                                                                                                                                \u2705 Key JWT role here<\/strong>: Gateway uses JWT to decide at the edge<\/strong> whether traffic should even hit the backend.<\/p>\n\n\n\n

                                                                                                                                                \n\n\n\n

                                                                                                                                                \ud83d\udcca Connected View (How they all tie together)<\/h1>\n\n\n
                                                                                                                                                (1) Human Login (OIDC)\nUser -> OIDC Provider -> ID Token (JWT) + Access Token -> API Gateway -> API\n\n(2) Service-to-Service (JWT)\nService A -> IdP (OAuth2 Client Credentials) -> Access Token (JWT) -> Service B\n\n(3) API Gateway (Validator)\nAny Client -> API Gateway -> JWT Validation -> Backend Service\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                                                \n\n\n\n
                                                                                                                                                \ud83d\udd11 Takeaway<\/h1>\n\n\n\n
                                                                                                                                                  \n
                                                                                                                                                • JWT = the envelope<\/strong> (claims + signature).<\/li>\n\n\n\n
                                                                                                                                                • OIDC = the login flow<\/strong> (for humans) that issues JWTs.<\/li>\n\n\n\n
                                                                                                                                                • Service-to-service<\/strong> uses JWTs directly (no OIDC flow needed).<\/li>\n\n\n\n
                                                                                                                                                • Gateways<\/strong> act as bouncers<\/strong>, validating JWTs before APIs are touched.<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                  \n\n\n\n
                                                                                                                                                  <\/p>\n","protected":false},"excerpt":{"rendered":"
                                                                                                                                                  \ud83e\udde9 JWT vs OIDC \u2014 Separate but Together 1. JWT (JSON Web Token) \ud83d\udc49 JWT is like a passport card […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-960","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts\/960","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/comments?post=960"}],"version-history":[{"count":2,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts\/960\/revisions"}],"predecessor-version":[{"id":963,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/posts\/960\/revisions\/963"}],"wp:attachment":[{"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/media?parent=960"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/categories?post=960"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rajeshkumar.xyz\/blog\/wp-json\/wp\/v2\/tags?post=960"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}