What is OIDC? How is it Different? Why is it "Amazing"? (Complete Guide with AWS×GitHub Examples)

What Is OIDC? How Does It Differ? Why Is It "Impressive"? (A Full Walkthrough, with a Real AWS × GitHub Example)

Today we are going to learn OIDC (OpenID Connect) systematically, from zero. Along the way I will answer the questions that usually come up — "How is it different from OAuth 2.0 and SAML?", "How do I actually use it with AWS and GitHub?" — with concrete examples.

Contents

1. Preliminaries: authentication versus authorization
2. What OIDC stands for, and what standard problem it solves
3. History and positioning: SAML → OAuth 2.0 → OIDC
4. The building blocks: ID tokens, Discovery, JWK (key distribution)
5. What makes it impressive: design philosophy and practical benefits
6. Comparison with the alternatives: OAuth 2.0 / SAML 2.0 / LDAP / Kerberos / API keys
7. Where things stand now: logout standards, Federation, eKYC / Identity Assurance
8. A worked example: connecting GitHub Actions → AWS securely over OIDC
9. Adoption checklist and design essentials
10. Summary

1. Preliminaries: Authentication and Authorization

Let us line up the terms first.

• Authentication: establishing who you are.
• Authorization: granting that "you" permission to do particular things.

OAuth 2.0 is fundamentally an authorization framework. OIDC is what you get when you add a thin identity layer on top of it, making login — proof of who someone is — interoperable. (IETF Datatracker)

2. What OIDC Stands For, and What It Solves

OIDC = OpenID Connect.

It is an open standard for authentication built on top of OAuth 2.0. It distributes the fact of a login, plus basic profile information, securely and in a standard shape: the ID token. It is JSON-based, which makes it easy to handle on mobile, in an SPA, or on a server, and it covers automatic endpoint discovery and public-key distribution, so what you get is interoperability that actually works. The specification is maintained by the OpenID Foundation and consolidated in OpenID Connect Core 1.0. (OpenID Foundation)

In one line: OIDC is the agreed set of conventions that makes OAuth 2.0 safe to use for login as well. (OpenID Foundation)

3. History and Positioning: SAML → OAuth 2.0 → OIDC

• SAML 2.0 (2005): widely adopted for business-to-business SSO. XML-based "assertions" exchanged by POST and redirect. The enterprise standard. (OASIS Open Documents)
• OAuth 2.0 (2012): the authorization standard for API access. Broadly adopted on web and mobile. (IETF Datatracker)
• OIDC (2014): defines an authentication layer over OAuth 2.0. The ID token (a JWT) makes "who" machine-readable. (OpenID Foundation)

The arc of that progression moved the world toward JSON and JWT, which are far easier to work with on web and mobile. (IETF Datatracker)

4. The Building Blocks: ID Tokens, Discovery, JWK

4.1 ID tokens (JWT)

• Format: JWT (JSON Web Token). Signed, so tampering is easy to detect, and compact in a URL-safe encoding. (IETF Datatracker)
• Contents: iss (issuer), sub (user identifier), aud (intended audience), exp (expiry), and so on — plus claims such as email carrying user attributes. (OpenID Foundation)

4.2 Discovery

• A provider publishes its endpoints and supported features as JSON at .well-known/openid-configuration, so a client can configure itself. (OpenID Foundation)

4.3 JWK / JWKS (public-key distribution)

• The public keys used to verify tokens are distributed as a JWKS (JWK Set). Key rotation is standardised too, so a relying party can fetch keys online and verify against them. (IETF Datatracker)

For example: major identity providers including Google, Apple, and Microsoft Entra ID all support OIDC and publish Discovery documents and JWKS. (Google for Developers)

5. What Makes It Impressive

1. Interoperability: Discovery and JWKS automate configuration and key management. Libraries exist, so the implementation burden is small. (OpenID Foundation)
2. A good fit for mobile and SPAs: JSON and HTTP centred, so it is lightweight. JWTs are URL-safe and easier to move around than SAML's XML. (IETF Datatracker)
3. Room for security extensions: recent mitigations such as PKCE (2015) slot in cleanly. (IETF Datatracker)
4. Standardised logout and session management: RP-initiated, front-channel, and back-channel logout standards are in place. (OpenID Foundation)
5. Cloud CI/CD integration: patterns such as GitHub Actions → AWS that hand over permissions safely using short-lived tokens — the worked example below. (GitHub Docs)

6. Comparison with the Alternatives

6.1 Versus OAuth 2.0 on its own

• OAuth 2.0 is an authorization standard. Who you are is merely a premise.
• OIDC standardises the distribution of the fact of authentication and user attributes (claims) through the ID token. (IETF Datatracker)

6.2 Versus SAML 2.0

• Representation: SAML uses XML; OIDC uses JSON and JWT.
• Where each fits: SAML is strong for enterprise SSO; OIDC is lighter and easier to implement for web, mobile, and APIs. (OASIS Open Documents)

6.3 Versus LDAP and Kerberos

• LDAP is a protocol for accessing a directory — a user registry — not a federation standard for application SSO. (IETF Datatracker)
• Kerberos is network authentication based on issuing tickets for mutual authentication. It is strong on-premises and in Active Directory environments, but for web interoperability and cloud federation, OIDC is usually easier to work with. (IETF Datatracker)

6.4 Versus API keys and long-lived tokens

• An API key presupposes distributing a shared secret, which carries a high risk of leakage. OIDC issues short-lived tokens on demand and makes it straightforward to narrow permissions through scopes and conditions, which reduces both the blast radius of a leak and the cost of managing credentials. (GitHub Docs)

7. Where Things Stand Now: Logout, Federation, eKYC / Identity Assurance

• RP-Initiated Logout (2022) and Front-Channel Logout (2022): standardised logout procedures for OIDC. Implementation is progressing. (OpenID Foundation)
• OpenID Federation 1.0: automates metadata distribution and policy enforcement between organisations through large-scale chains of trust anchored at a trust anchor. The specification is still evolving. (OpenID Foundation)
• OIDC for Identity Assurance 1.0 (2024): an extension that carries verified claims in a standard shape for eKYC purposes. It is spreading into digital identity verification in finance and government. (OpenID Foundation)

8. A Worked Example: Connecting GitHub Actions → AWS Securely over OIDC

The problem you meet constantly in CI/CD: you do not want a long-lived AWS key sitting in GitHub Secrets just to deploy from GitHub to AWS. With OIDC you can mint short-lived temporary credentials each time instead.

8.1 How issuance works, conceptually

1. GitHub Actions obtains an ID token from GitHub's OIDC provider (issued by token.actions.githubusercontent.com).
2. It presents that ID token to AWS STS via AssumeRoleWithWebIdentity, temporarily switching into an IAM role whose conditions the token matches. (GitHub Docs)
3. STS hands back short-lived credentials — valid for a few minutes to about an hour — and the job uses those to operate S3, CloudFront, Lambda, and so on. (AWS Documentation)

8.2 The AWS-side configuration, in essence

• OIDC identity provider: register token.actions.githubusercontent.com as trusted.
• The IAM role's trust policy: keep it least-privilege by putting conditions on aud (sts.amazonaws.com) and on sub (the specific repository and branch). (Amazon Web Services, Inc.)

8.3 The GitHub Actions workflow (excerpt)

name: deploy
on:
  push:
    branches: [ main ]
permissions:
  id-token: write   # allow the OIDC token to be requested
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>
          aws-region: ap-northeast-1
      - run: aws s3 sync dist s3://example-bucket --delete

This setup follows GitHub's official guidance. It is safe because no long-lived key sits in Secrets and every run uses only short-lived, scoped permissions. (GitHub Docs)

The AWS API that issues the temporary credentials is AssumeRoleWithWebIdentity. It is also used for federation from mobile and web identity providers — any OIDC-capable IdP such as Google. (AWS Documentation)

9. Adoption Checklist and Design Essentials

9.1 Choosing an implementation

• Flow: make Authorization Code + PKCE your first choice, on web, SPA, and native alike. (IETF Datatracker)
• Libraries: use a proven OIDC / OAuth 2.0 implementation.

9.2 Security settings

• Pin Discovery: require the issuer to match, require HTTPS, and decide a pinning policy. (OpenID Foundation)
• Cache JWKS and handle rotation: be ready for the kid to change. (IETF Datatracker)
• Verify tokens: check the signature, and check aud, iss, exp, and nbf strictly. (IETF Datatracker)
• Minimise scopes: request only what you need, such as openid profile email. (AWS Documentation)
• Logout: design around what your IdP supports — RP-Initiated Logout and the rest. (OpenID Foundation)

9.3 Operations

• Attach conditions to permissions: on AWS, restrict sub in the role's trust policy (for example repo:org/name:ref:refs/heads/main). (Amazon Web Services, Inc.)
• Keep lifetimes short: temporary credentials should expire quickly. (AWS Documentation)
• Audit: keep monitoring OIDC issuance logs and STS usage history.

10. Summary (Explanation → Analogy → Key Points)

The explanation, in short

• OIDC is a standard that puts authentication on top of OAuth 2.0. It distributes the result of identity verification safely as an ID token (a JWT), and automates configuration and key management through Discovery and JWKS. (OpenID Foundation)
• It is strong for interoperability across SaaS, cloud, and mobile, and the surrounding pieces — PKCE, the logout specifications — have matured. (IETF Datatracker)
• It makes CI/CD without stored secrets, as in GitHub Actions → AWS, a practical reality. (GitHub Docs)

The analogy

• OAuth 2.0 is the procedure for issuing a pass that grants entry to specific shelves in a warehouse.
• OIDC is the step before that: how to produce an identity document that officially establishes who you are.
• Discovery and JWKS are the official public noticeboard at the town hall — the counters, the forms, and the published seal impressions. Because they exist, a town hall in a different town (a different IdP) can be checked for authenticity by the same procedure. (OpenID Foundation)

Upsides and downsides

• Upsides: interoperability, light weight, automatic discovery, key rotation support, short-lived credentials, least privilege. (OpenID Foundation)
• Downsides: migration cost where the existing enterprise estate is built around SAML; interoperability gaps around logout; and enough configuration freedom that following best practice is genuinely required. (OpenID Foundation)

Appendix: A Short Glossary

• ID token: a JWT representing the result of authenticating a user. (IETF Datatracker)
• Access token: the "permit" for API access. Under OIDC it is normally used alongside OAuth 2.0. (IETF Datatracker)
• Discovery: the mechanism for fetching an IdP's configuration automatically (.well-known/openid-configuration). (OpenID Foundation)
• JWKS (JWK Set): the distribution format for the public keys used in verification. (IETF Datatracker)
• PKCE: a mitigation against authorization-code interception. Effectively mandatory for SPAs and mobile. (IETF Datatracker)
• RP-Initiated Logout: standardises a logout request sent from the relying party to the IdP. (OpenID Foundation)

Reference: OIDC Support at Major Vendors

• Google: "Sign in with Google" conforms to OIDC. (Google for Developers)
• Microsoft (Entra ID): officially supports OIDC. (Microsoft Learn)
• AWS: has guidance for Cognito, web identity federation in STS, and GitHub OIDC integration. (AWS Documentation)

That should connect the overall picture of OIDC to how you actually put it into practice. The realistic answer is to choose by use case — keep the enterprise's SAML investment where it belongs, and reach for OIDC on web, mobile, and cloud. Since it also helps with eliminating long-lived secrets in CI/CD and zero-trust work generally, starting with GitHub Actions → AWS over OIDC is the easiest way to feel the benefit. (Amazon Web Services, Inc.)