OAuth 2.0
参考：
OAuth Community Site (oauth.net)
概要
参考：
OAuth 認証を真面目に考える | DevelopersIO
OAuth 2.0 の仕組みと認証方法 | murashun.jp
多分わかりやすい OAuth | SIOS Tech. Lab
アプリ開発で知っておきたい認証技術 OAuth 1.0 + OAuth 2.0 + OpenID Connect – SlideShare
OAuth 認証
参考：
非技術者のための OAuth 認証 (?)と OpenID の違い入門 | @_Nat Zone
OpenID Connect
参考：
OpenID Connect ユースケース、OAuth 2.0 の違い・共通点まとめ | Build Insider
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita
OAuth2 や OpenID Connect とは何か、なんとなくわかった気になるための概要メモ | 備忘録の裏のチラシ (norikone.hatenablog.com)
ユースケース
Web アプリ
- secret (= クライアント ID に対応するパスワードなどのクレデンシャル情報) を秘匿に保てる
- (バッチ処理など) 比較的長期間有効な API アクセス権限を必要とする場合がある
ネイティブアプリ (アプリ独自の Backend Server なし)
- secret を秘匿に保てない
- 初回起動時以外はログインさせることもないので、長期間有効な API アクセス権限を必要とする
- 端末は特定ユーザーと1対1でひも付くことが想定されるため、ユーザー認証の重要性は低い
ネイティブアプリ (アプリ独自の Backend Server あり)
- secret を秘匿に保てない
- 初回起動時以外はログインさせることもないので、長期間有効な API アクセス権限を必要とする
- バックエンド側では全ユーザーのデータを管理しているため、バックグラウンドではユーザー認証が必要
JS アプリ (アプリ独自の Backend Server なし)
- secret を秘匿に保てない
- 常にユーザーがブラウザーの前にいることが期待できるため、必要に応じて API アクセス権限を再取得可能
- ブラウザーは特定ユーザーと1対1でひも付くことが想定されるため、ユーザー認証の重要性は低い
JS アプリ (アプリ独自の Backend Server あり)
- secret を秘匿に保てない
- 常にユーザーがブラウザーの前にいることが期待できるため、必要に応じて API アクセス権限を再取得可能
- バックエンド側では全ユーザーのデータを管理しているため、バックグラウンドではユーザー認証が必要
参考：
OAuth 2.0 の代表的な利用パターンを仕様から理解しよう | Build Insider
クライアントタイプ | The OAuth 2.0 Authorization Framework (openid-foundation-japan.github.io)
アクセストークン
実装タイプ
- 識別子型
- 内包型 (JWT / JSON Web Token)
- ハイブリッド型
署名アルゴリズム (JWT)
- 対称鍵 (共有鍵方式)
- 非対称鍵 (秘密鍵・公開鍵方式)
参考：
OAuth アクセストークンの実装に関する考察 – Qiita
認可レスポンス
- code
- 必須 (REQUIRED). 認可コードは認可サーバーによって許可される. 漏洩のリスクを軽減するため, 認可コードは発行されてから短期間で無効にしなければならない (MUST). 認可コードの有効期限は最大でも10分を推奨する (RECOMMENDED). クライアントは2回以上認可コードを使用してはならない (MUST NOT). もし認可コードが2回以上使用された場合は, 認可サーバーはリクエストを拒否しなければならず (MUST), この認可コードを基に発行されたこれまでのすべてのトークンを無効化すべきである (SHOULD). 認可コードはクライアント識別子とリダイレクト URI に紐づく.
- state
- クライアントからの認可リクエストに state パラメーターが含まれていた場合は必須 (REQUIRED). クライアントから受け取った値をそのまま返す.
参考：
認可レスポンス | The OAuth 2.0 Authorization Protocol (openid-foundation-japan.github.io)
refresh_token
参考：
refresh_token で access_token を再発行した時の挙動について – teratail
トークン置換攻撃
参考：
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone
OAuth 2.0 Implicit Flow をユーザー認証に利用する際のリスクと対策方法について | r-weblife
「OAuth 2.0 (Implicit Flow) でログイン」の被害例 | OAuth.jp
Is the OAuth 2.0 Implicit Flow Dead? | Okta Developer
CSRF 対策
参考：
クロスサイトリクエストフォージェリ | The OAuth 2.0 Authorization Protocol (openid-foundation-japan.github.io)
クリックジャッキング
参考：
クリックジャッキング | The OAuth 2.0 Authorization Protocol (openid-foundation-japan.github.io)
The OAuth 2.0 Authorization Framework
参考：
Authorization Flow
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
参考：
Yahoo! ID 連携 Authorization Codeフロー | Yahoo! デベロッパーネットワーク
Authorization Code Grant – RFC 6749 The OAuth 2.0 Authorization Framework | IETF (tools.ietf.org)
Implicit Flow
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
参考：
Implicit Grant – RFC 6749 The OAuth 2.0 Authorization Framework | IETF (tools.ietf.org)
PKCE
参考：
PKCE で防げる「認可コード横取り攻撃」とはどのような攻撃か – Qiita
認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと – Qiita
OAuth2.0 で認可コードの漏洩を防ぐ PKCE | 理系学生日記
Web API
参考：
第二弾 OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita
Tips
参考：