Introduction to
OpenID Connect

Foundations

• Why OIDC exists — authentication ≠ authorisation
• 2014 → 2025 history; OIDC vs OpenID 2.0 vs SAML
• Roles & terminology — RP, OP, End-User
• The relationship to OAuth 2.0

Authentication vs authorisation

• Authentication — proves who someone is. ("This is Alice.")
• Authorisation — decides what they can do. ("Alice may read invoices.")
• OAuth 2.0 = authorisation only. OIDC = authentication on top.
• Your app needs both — and they are not interchangeable.

A vanilla OAuth 2.0 request

GET /authorize?
  response_type=code&
  client_id=app123&
  scope=invoices:read&
  redirect_uri=https://app/cb&
  state=...&code_challenge=...&code_challenge_method=S256

# Token response
{ "access_token": "eyJ...",
  "token_type":   "Bearer",
  "expires_in":   3600 }

Decoded header + payload

# Header
{
  "alg": "RS256",
  "kid": "abc123",
  "typ": "JWT"
}

# Payload — required claims
{
  "iss": "https://accounts.google.com",
  "sub": "1098765432109876543210",
  "aud": ".apps.googleusercontent.com",
  "iat": 1714000000,
  "exp": 1714003600,
  "nonce": "abc123"
}

Cryptographic checks

1. Parse header; refuse alg=none
2. Refuse HS256 if you only have a public key (alg-confusion CVE-2015-9235 family)
3. Look up key by kid in the OP's cached JWKS
4. Verify the signature with that key
5. If kid not found, refresh JWKS once and retry

A real example

$ curl https://accounts.google.com/.well-known/openid-configuration

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint":
      "https://accounts.google.com/o/oauth2/v2/auth",
  "token_endpoint":
      "https://oauth2.googleapis.com/token",
  "userinfo_endpoint":
      "https://openidconnect.googleapis.com/v1/userinfo",
  "revocation_endpoint":
      "https://oauth2.googleapis.com/revoke",
  "jwks_uri":
      "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported":   ["code","token","id_token", ...],
  "subject_types_supported":    ["public"],
  "id_token_signing_alg_values_supported": ["RS256"],
  "scopes_supported":           ["openid","email","profile"],
  "claims_supported":           ["aud","email", ... ]
}

A JWKS document

{
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "alg": "RS256",
      "kid": "1f7d…",
      "n":   "vK… (modulus, base64url)",
      "e":   "AQAB"
    },
    {
      "kty": "EC",
      "use": "sig",
      "alg": "ES256",
      "kid": "5b9c…",
      "crv": "P-256",
      "x":   "…", "y": "…"
    }
  ]
}

OIDC standard scopes

Sequence

1. RP POSTs to /bc-authorize with a login_hint identifying the user
2. OP returns an auth_req_id and a polling/notify mode
3. OP pushes a notification to the user's phone
4. User approves
5. RP polls /token with the auth_req_id (or receives a webhook)
6. OP returns ID token + access token

The shift

• Classic OIDC: OP is Google/Microsoft, the RP trusts them
• SIOPv2: OP is the user's wallet (Apple Wallet, Google Wallet, EU Digital Identity Wallet), the RP trusts the credentials inside
• Public-key cryptography on the device, not server-side accounts
• Built on OAuth + OIDC + Verifiable Credentials Data Model (W3C)

The model

• Every entity (RP, OP, intermediate, trust anchor) publishes an Entity Configuration at /.well-known/openid-federation
• Each Entity Configuration is a signed JWT
• It points up at one or more "superior" entities (its parents in the tree)
• A "trust chain" from RP up to a Trust Anchor proves "this RP belongs to the federation"

FAPI 2.0 mandates

• PAR — Pushed Authorisation Requests (RFC 9126)
• PKCE — always
• Sender-constrained tokens — DPoP (RFC 9449) or mTLS (RFC 8705)
• private_key_jwt or mTLS for client auth
• Strong algorithms only — RS256/PS256/ES256; no HS-anything
• Authorisation Code only; nothing implicit

GitHub Actions → AWS

# GitHub action workflow:
permissions:
  id-token: write           # request OIDC token

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123:role/deploy
          aws-region: eu-west-2
      # → role assumed via STS using OIDC; creds last 1h
      - run: aws s3 cp ./dist s3://my-bucket --recursive

Three takeaways

1. OIDC = OAuth 2.0 + the openid scope + an ID token. Same flow you already know; one extra signed assertion comes back.
2. The complexity is in validation: signatures, issuer, audience, nonce, JWKS rotation. Use a conformant library and don't roll your own.
3. OIDC has quietly outgrown "Sign in with Google" — workload OIDC, FAPI 2.0, OpenID Federation 1.0 and SIOPv2 are reshaping identity for the next decade.