Module 2 of 8

Auth Vocabulary: SSO, SAML, OIDC, JWT, JWKS, and Tokens

Learn the words first so the architecture stops feeling mysterious.

85 minutes1 exercisesFree

Start here

Learning objectives

  • Define SSO, SAML, OIDC, OAuth 2.0, JWT, JWKS, access tokens, and service tokens
  • Explain the difference between authentication and authorization
  • Understand why issuer, audience, expiry, signature, and scopes matter
  • Know which standards are used for humans and which are used for services
Auth Vocabulary: SSO, SAML, OIDC, JWT, JWKS, and Tokens A central Envoy edge checks identity before traffic reaches product services. Identity browser or service Token enforcement point Keys IdP or policy service when needed Policy Kubernetes app Authenticate once, validate every request, authorize before forwarding.

Authentication vs Authorization

Authentication answers: who are you? Authorization answers: what are you allowed to do? A user can be correctly authenticated and still be denied access to a product, tenant, or action.

Human Login Standards

TermBeginner definitionWhere it appears
SSOOne login session used across multiple products.Google account across Gmail and YouTube; company IdP across internal apps.
OIDCOpenID Connect; a login layer on top of OAuth 2.0 that gives applications identity information.Modern web and mobile login.
SAMLAn older but widely used enterprise SSO standard using signed XML assertions.Enterprise SaaS and corporate identity providers.

Token Terms

TermMeaningCommon mistake
JWTA signed JSON token containing claims such as subject, issuer, audience, expiry, and scopes.Trusting the JSON without verifying the signature and issuer.
JWKSA JSON Web Key Set; public keys used to verify JWT signatures.Not caching keys or not handling key rotation.
Access tokenA token a client presents to call an API.Using it as a long-lived password.
Service tokenA machine identity token used by one service to call another.Sharing one token across many services.
Federated credentialA temporary credential issued because a trusted identity was exchanged for cloud or data-platform access.Giving broad static credentials when short-lived scoped credentials would be safer.

Claims That Matter

For production JWT validation, the minimum checks are signature, issuer, audience, expiry, and intended use. The sub claim names the subject. The iss claim names the issuer. The aud claim tells which application or API the token was meant for. The exp claim limits token lifetime.

Where Envoy Fits

Envoy can validate JWTs locally with JWKS through the JWT authn filter. Envoy can also call an external authorization service through the ext_authz filter. Full SAML and OIDC login flows usually involve an identity provider and an auth service; Envoy should be treated as the enforcement point, not the complete identity provider.

Real world

Where this shows up

  • A Kubernetes platform with many internal products that should share one login and one enforcement layer
  • Developer portals, data tools, admin consoles, APIs, and service-to-service calls protected at the edge
  • Migration from product-specific auth logic to centralized policy checks without rewriting every product first

Production notes

Keep these close

  • Always document accepted issuers and audiences per route
  • Use short token lifetimes and key rotation instead of long-lived shared secrets
  • Keep token claims small; large tokens increase request size and can leak unnecessary data

Common mistakes

What usually breaks

  • Treating any JWT as trusted because it is base64-looking text
  • Accepting tokens minted for another audience
  • Using one service token for many unrelated workloads

Security risks

Threats to watch

  • Missing audience validation can let a token for one product call another product
  • Long-lived tokens are difficult to revoke after leakage
  • Broad federated credentials can turn a small web bug into a data-platform incident

Tradeoffs

Design choices you should be able to defend

JWT validation at Envoy

Pros

  • Fast local checks after JWKS cache is warm
  • Consistent issuer and audience checks
  • Products receive trusted identity context

Cons

  • Complex per-resource authorization still needs product or auth-service logic
  • Bad JWKS or issuer config can block traffic

Opaque token introspection on every request

Pros

  • Central revocation is easier
  • Token contents are not exposed to clients

Cons

  • Adds network call latency
  • Auth service availability becomes more critical

Think like an engineer

Questions to answer before shipping

  • Which identity is making the request: a human, a service, or a federated cloud principal?
  • Which check belongs at Envoy, and which check must remain inside the product domain model?
  • What happens when the identity provider, JWKS endpoint, or auth service is slow or unavailable?

Key terms

Vocabulary used in this module

OIDC

OpenID Connect, a standard login layer for identifying users.

SAML

Security Assertion Markup Language, an enterprise SSO standard using signed assertions.

JWT

JSON Web Token, a signed token carrying claims.

JWKS

JSON Web Key Set, the public keys used to verify JWT signatures.

Exercises

Practice inside the lesson

35-45 minutesBeginner

Build the Auth Glossary

Create a one-page glossary that a beginner teammate can use during design review.

  1. Write one-line definitions for SSO, SAML, OIDC, JWT, JWKS, access token, service token, and federated credential
  2. Add one example product request for each token type
  3. Mark which terms belong to human login and which belong to service calls
  4. Write one sentence explaining why authentication is not the same as authorization

Recap

Key takeaways

  • Authentication proves identity; authorization decides permissions
  • OIDC and SAML are login standards; JWT and JWKS are token validation building blocks
  • Envoy can validate tokens and enforce policy, but an IdP or auth service owns login protocol details

Related resources

Keep learning across CodersSecret