OAuth・OIDC
OAuth・OIDCとは
- OAuth 2.0 = 「あるサービスに、自分の代わりに別サービスのデータへアクセスする権限を委譲する」ための標準仕様
- OIDC(OpenID Connect) = OAuth 2.0の上に「この人は誰か(認証)」を確認する仕組みを追加した拡張仕様
「OAuthは認可、OIDCは認証」という違いを押さえるのが最初の一歩です。[[認証と認可]] の区別がそのまま両者の役割分担になっています。
身近な例で理解する
「アプリAで『Googleでログイン』を押す」流れが典型例です。
1. アプリA → Googleへリダイレクト「ログインして権限を許可してください」
2. ユーザー → Googleにログインし、許可ボタンを押す
3. Google → アプリAへ「認可コード」を渡す
4. アプリA → 認可コードと引き換えに「アクセストークン」を取得
5. アプリA → トークンを使ってGoogleのAPI([[REST API]])を呼び出す
このときアプリAはユーザーのGoogleパスワードを一切知りません。これがOAuthの核心的な価値です。
初学者向けポイント
- 「権限の委譲」であって「パスワードの共有」ではない。だからこそ第三者アプリにパスワードを渡さずに済む
- OIDCでは認証結果として IDトークン(JWT) が発行される。誰であるかの情報(名前、メールなど)がここに署名付きで入っている
- JWTの署名検証には[[暗号化の基礎]]で扱う公開鍵暗号が使われる。改ざんされていないことを数学的に確認できる
代表的な登場人物
| 用語 | 役割 |
|---|---|
| リソースオーナー | データの持ち主(ユーザー本人) |
| クライアント | 権限を求めるアプリ(アプリA) |
| 認可サーバー | ログインと許可を処理するサーバー(Google等) |
| リソースサーバー | 実際のデータを持つAPI |
開発者が気をつけること
- 自分でOAuthのプロトコルを実装するより、実績あるライブラリ・SDKに任せる
- トークンは必ず [[HTTPS・TLS]] 上でやり取りする。平文でのトークン送信は即座に漏洩リスクになる
- リダイレクトURLの検証を厳格に行わないと、認可コードを横取りされる攻撃(認可コード横取り攻撃)につながる
関連技術とのつながり
- [[認証と認可]] — OAuth/OIDCが具体化する認証・認可の標準的な実装
- [[HTTPS・TLS]] — トークンをやり取りする通信路の必須要件
- [[REST API]] — アクセストークンで保護される代表的な対象
- [[暗号化の基礎]] — IDトークンの署名検証に使われる公開鍵暗号の応用
Q: OAuth 2.0とOIDCの役割分担として正しいのはどれ?
- [ ] OAuthは認証、OIDCは認可
- [x] OAuthは認可、OIDCは認証
- [ ] どちらも暗号化を担当する
解説: OAuthは権限の委譲(認可)、OIDCはその上に「この人は誰か」を確認する認証を追加した拡張仕様です。
Q: 「Googleでログイン」の流れで、アプリAが一切知らないものは?
- [ ] アクセストークン
- [ ] 認可コード
- [x] ユーザーのGoogleパスワード
解説: アプリAはパスワードを知らずにトークンで権限を得るのがOAuthの核心的な価値です。
Q: OIDCのIDトークン(JWT)の署名検証に使われる技術は?
- [x] 公開鍵暗号
- [ ] パスワードの共有
- [ ] Cookieの照合
解説: JWTの署名検証には公開鍵暗号が使われ、改ざんされていないことを数学的に確認できます。