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

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

Today, we'll systematically learn about OIDC (OpenID Connect) from the ground up. We'll thoroughly answer questions like "How does it differ from OAuth 2.0 and SAML?" and "How do you use it with AWS and GitHub?" with practical examples and diagrams. Note: "OCDC" mentioned in the question is interpreted as a typo for OIDC.

Table of Contents

1. Introduction: Authentication vs Authorization
2. What is OIDC and what standard does it solve?
3. History and positioning: SAML → OAuth 2.0 → OIDC
4. OIDC fundamentals: ID tokens, Discovery, JWK (key distribution)
5. Why it's "amazing": Design philosophy and practical benefits
6. Comparison with other methods: OAuth 2.0 / SAML 2.0 / LDAP / Kerberos / API keys
7. Latest developments: Logout standards, Federation, eKYC/Identity Assurance
8. Practical example: GitHub Actions → AWS securely connected with OIDC
9. Implementation checklist & design considerations
10. Summary

1. はじめに：認証（Authentication）と認可（Authorization）

まず用語をそろえます。

• 認証：あなたは誰か？を確かめる。
• 認可：その「あなた」に何をさせて良いか？権限を与える。

OAuth 2.0は本来認可の枠組みです。ここに“認証の薄い層（アイデンティティ層）”を足して、ログイン（=本人確認）の相互運用を可能にしたのがOIDCです。([IETF Datatracker][1])

2. OIDCとは何の略で、何を解決する標準か

OIDC = OpenID Connect。 OAuth 2.0の上に成り立つ“認証”のオープン標準で、ログインの事実と基本プロフィール情報を、IDトークンという標準形式で安全に配布します。スマホ・SPA・サーバーのいずれでも扱いやすいJSONベースで、エンドポイントの自動発見や公開鍵の配布まで含めて“動く相互運用”を提供します。仕様はOpenID Foundationで整備され、OpenID Connect Core 1.0にまとまっています。([OpenIDファンデーション][2])

一言でいえば：「OAuth 2.0をログイン用途にも安全に使えるようにした“合意セット”がOIDC」。([OpenIDファンデーション][2])

3. 歴史と位置づけ：SAML → OAuth 2.0 → OIDC

• SAML 2.0（2005）：企業間SSOで普及。XMLベースの「アサーション」をPOST/リダイレクトでやり取り。エンタープライズで標準。([OASIS Open Documents][3])
• OAuth 2.0（2012）：APIアクセスの認可標準。Web/モバイルで幅広く採用。([IETF Datatracker][1])
• OIDC（2014）：OAuth 2.0に認証レイヤを定義。IDトークン（JWT）で「誰か」を機械可読に。([OpenIDファンデーション][4])

この流れにより、Web／モバイルで扱いやすいJSON・JWT中心の世界へと進化しました。([IETF Datatracker][5])

4. OIDCの基礎部品：IDトークン・発見（Discovery）・JWK

4.1 IDトークン（JWT）

• 形式：JWT（JSON Web Token）。署名付きで改ざん検出が容易、URLセーフなコンパクト形式。([IETF Datatracker][5])
• 中身：iss（発行者）sub（ユーザー識別子）aud（想定受信者）exp（有効期限）などに加え、email等のClaims（属性）も運べます。([OpenIDファンデーション][2])

4.2 Discovery（自動発見）

• .well-known/openid-configurationにプロバイダのエンドポイントや対応機能がJSONで公開され、クライアントは自動設定可能。([OpenIDファンデーション][6])

4.3 JWK/JWKS（公開鍵配布）

• トークン検証に使う公開鍵をJWKS（JWK Set）として配布。鍵ローテーションも標準化され、RP（連携先）はオンラインで鍵を取得して検証できます。([IETF Datatracker][7])

例：GoogleやApple、Microsoft Entra IDなど主要IdPはOIDCをサポートし、DiscoveryとJWKSを公開しています。([Google for Developers][8])

5. どう“すごい”のか：設計思想と実用メリット

1. 相互運用性：DiscoveryとJWKSにより設定・鍵管理が自動化。ライブラリが揃い、実装負担が小さい。([OpenIDファンデーション][6])
2. モバイル/SPAとの親和性：JSON/HTTP中心で軽量。JWTはURLセーフで、SAMLのXMLより取り回しが良い。([IETF Datatracker][5])
3. セキュリティ拡張：PKCE（2015）などの最新対策を取り込みやすい。([IETF Datatracker][9])
4. ログアウトやセッション管理の標準化：RP発イニシエイト・フロント/バックチャネルなどログアウトの標準が整備。([OpenIDファンデーション][10])
5. クラウドCI/CD連携：GitHub Actions→AWSのように、短期トークンで安全に権限を引き渡す運用（後述の実例）。([GitHub Docs][11])

6. 他方式との比較：要点整理

6.1 OAuth 2.0（単体）との違い

• OAuth 2.0は認可標準。誰であるかは前提に過ぎない。
• OIDCはIDトークンで認証の事実とユーザー属性（Claims）を標準化して配布。([IETF Datatracker][1])

6.2 SAML 2.0との違い

• 表現：SAMLはXML、OIDCはJSON/JWT。
• 適用感：SAMLはエンタープライズSSOに強く、OIDCはWeb/モバイル/APIで軽量・実装容易。([OASIS Open Documents][3])

6.3 LDAP／Kerberosとの違い

• LDAPはディレクトリ（ユーザー台帳）にアクセスするためのプロトコルで、アプリSSOの連携標準ではありません。([IETF Datatracker][12])
• Kerberosはチケットを配って相互認証するネットワーク認証。オンプレ環境やAD統合で強いが、Webの相互運用やクラウド連携ではOIDCの方が取り回しが良いケースが多いです。([IETF Datatracker][13])

6.4 APIキー・長期トークンとの違い

• APIキーは共有秘密の配布が前提で漏洩リスクが高い。OIDCは短命トークンを都度払い出し、権限も絞りやすい（スコープや条件）ため、漏えい時の影響と管理コストを低減できます。([GitHub Docs][11])

7. 最新の状況：ログアウト、Federation、eKYC/Identity Assurance

• RP-Initiated Logout（2022）／Front-Channel Logout（2022）：OIDCにおけるログアウト手順の標準。実装が進んでいます。([OpenIDファンデーション][10])
• OpenID Federation 1.0：大規模な信頼連鎖（トラストアンカー）で組織間のメタデータ配布とポリシー適用を自動化。仕様は進化中。([OpenIDファンデーション][14])
• OIDC for Identity Assurance 1.0（2024）：eKYC用途で“検証済みクレーム”を標準形式で運ぶ拡張。金融・行政でのデジタル本人確認に波及。([OpenIDファンデーション][15])

8. 具体例：GitHub Actions → AWSをOIDCで安全につなぐ

みなさんがCI/CDでよく直面するのが「GitHubからAWSにデプロイするのに長期AWSキーをGitHub Secretsに置きたくない」問題。OIDCなら“その都度”短命な一時資格情報を発行できます。

8.1 発行の流れ（概念）

1. GitHub ActionsがGitHubのOIDCプロバイダからIDトークン（token.actions.githubusercontent.com発行）を取得。
2. AWS STSのAssumeRoleWithWebIdentityで、そのIDトークンを提示し、条件に合致するIAMロールに一時スイッチ。([GitHub Docs][11])
3. STSが短期クレデンシャル（数分〜1時間程度）を払い出し、ジョブはそれでS3/CloudFront/Lambda等を操作。([AWS Documentation][16])

8.2 AWS側の設定（要点）

• OIDCアイデンティティプロバイダ：token.actions.githubusercontent.comを信頼登録。
• IAMロールの信頼ポリシー：aud=sts.amazonaws.comやsubに対象リポジトリやブランチを条件指定して最小権限に。([Amazon Web Services, Inc.][17])

8.3 GitHub Actions側のWorkflow例（抜粋）

name: deploy
on:
  push:
    branches: [ main ]
permissions:
  id-token: write   # OIDCトークンの取得を許可
  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

この構成はGitHub公式のガイドラインに沿っています。長期キーをSecretsに置かず、毎回短命かつスコープ済みの権限だけを使うため安全です。([GitHub Docs][11])

なお、AWSの一時資格情報発行APIはAssumeRoleWithWebIdentity。モバイル/Web IdP（Google等のOIDC対応IdP）からのフェデレーションにも用いられます。([AWS Documentation][18])

9. 導入チェックリスト＆設計の要点

9.1 実装選定

• フロー：Web/SPA/ネイティブともAuthorization Code + PKCEを第一候補に。([IETF Datatracker][9])
• ライブラリ：OIDC/OAuth 2.0の実績ある実装を採用。

9.2 セキュリティ設定

• Discoveryの固定：issuer一致・HTTPS必須・ピン留め方針。([OpenIDファンデーション][6])
• JWKSキャッシュ＆ローテ対応：kid切替に備える。([IETF Datatracker][7])
• トークン検証：署名検証、aud/iss/exp/nbfの厳格チェック。([IETF Datatracker][5])
• スコープ最小化：openid profile emailなど必要最小限に。([AWS Documentation][19])
• ログアウト：RP-Initiated Logout等、IdPのサポートに合わせて設計。([OpenIDファンデーション][10])

9.3 運用

• 権限の条件付与：AWSならロールの信頼ポリシーでsub（例：repo:org/name:ref:refs/heads/main）を制限。([Amazon Web Services, Inc.][17])
• 期限短縮：一時資格情報の有効期限は短く。([AWS Documentation][16])
• 監査：OIDC発行ログ・STS利用履歴の継続監視。

10. まとめ（説明 → たとえ話 → 要点）

説明の要点

• OIDCはOAuth 2.0の上に“認証”を載せた標準。IDトークン（JWT）で「本人確認の結果」を安全に配布し、DiscoveryとJWKSで設定と鍵管理を自動化します。([OpenIDファンデーション][2])
• SaaS・クラウド・モバイルでの相互運用に強く、PKCEやログアウト仕様など周辺も成熟。([IETF Datatracker][9])
• GitHub Actions → AWSのような秘密鍵を置かないCI/CDを現実にします。([GitHub Docs][11])

たとえ話

• OAuth 2.0は「この倉庫の“特定の棚”に入る権限を渡すための“通行証”の出し方」。
• OIDCはその前段で「あなたが誰かを公的に確認できる身分証の作り方」。
• DiscoveryとJWKSは「役所の公式掲示板（窓口と書式、印影の公開）」。これがあるから、違う町の役所（IdP）でも同じ手順で身分証の真偽を確かめられるわけです。([OpenIDファンデーション][6])

メリット・デメリット

• メリット：相互運用・軽量・自動発見・鍵ローテ対応・短期資格情報・最小権限。([OpenIDファンデーション][6])
• デメリット：SAML中心の既存エンタープライズ基盤では移行コスト／ログアウトまわりの相互運用に差異／設定の自由度が高くベストプラクティス遵守が必要。([OpenIDファンデーション][10])

付録：用語ミニ事典

• IDトークン：ユーザーの認証結果を表すJWT。([IETF Datatracker][5])
• Accessトークン：APIアクセスのための“許可証”。OIDCでは通常OAuth 2.0と併用。([IETF Datatracker][1])
• Discovery：IdPの設定を自動取得する仕組み（.well-known/openid-configuration）。([OpenIDファンデーション][6])
• JWKS（JWK Set）：検証用公開鍵の配布形式。([IETF Datatracker][7])
• PKCE：認可コード奪取対策。SPAやモバイルで必須級。([IETF Datatracker][9])
• RP-Initiated Logout：RPからIdPへログアウト要求を標準化。([OpenIDファンデーション][10])

参考：主要ベンダのOIDCサポート（例）

• Google：「Sign in with Google」はOIDCに準拠。([Google for Developers][8])
• Microsoft（Entra ID）：OIDCを公式サポート。([Microsoft Learn][20])
• AWS：CognitoやSTSのWebアイデンティティ連携、GitHub OIDC連携のガイドあり。([AWS Documentation][21])

みなさん、これでOIDCの全体像と実践手順がつながったはずです。エンプラのSAML資産と、Web/モバイル/クラウドのOIDCをユースケースで使い分けるのが現実解です。CI/CDやゼロトラスト的な「長期秘密の撤廃」にも効くので、まずはGitHub Actions→AWSのOIDC連携から導入してみると効果が実感しやすいでしょう。([Amazon Web Services, Inc.][17])