OIDCって何？どう違う？なぜ"すごい"のか（AWS×GitHubの実例つき徹底講義）

OIDCって何？どう違う？なぜ"すごい"のか（AWS×GitHubの実例つき徹底講義）

みなさん、今日はOIDC（OpenID Connect）について、ゼロから体系的に学びます。途中で「OAuth2.0やSAMLとの違いは？」「AWSとGitHubでどう使うの？」といった疑問にも、実例と図解のつもりで丁寧に答えていきます。なお、ご質問文にあった「OCDC」はOIDCの誤記と解釈して進めます。

目次

1. はじめに：認証と認可のちがい
2. OIDCとは何の略で、何を解決する標準か
3. 歴史と位置づけ：SAML → OAuth 2.0 → OIDC
4. OIDCの基礎部品：IDトークン・発見（Discovery）・JWK（鍵配布）
5. どう“すごい”のか：設計思想と実用メリット
6. 他方式との比較：OAuth 2.0／SAML 2.0／LDAP／Kerberos／APIキー
7. 最新の状況：ログアウト標準・Federation・eKYC/Identity Assurance
8. 具体例：GitHub Actions → AWSをOIDCで安全につなぐ
9. 導入チェックリスト＆設計の要点
10. まとめ

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])