SlideShare a Scribd company logo
1 of 71
Download to read offline
いまどきのOAuth/OIDC一挙おさらい
2020年2月
工藤達雄
Authlete, Inc.
2
「ポストPKCE/JWT」を中心に
Authlete社の独断と偏見により
2020年に注目すべきOAuth 2.0 /
OIDC関連仕様とプラクティスを
ご紹介します
Welcome!
3
• サン・マイクロシステムズ、野村総合研究所、
NRI セキュアを経て、2018年からAuthlete 社に
て VP of Solution Strategy を担当
• 専門はデジタル・アイデンティティを中心とする
プリセールス、コンサルティング、事業開発、
エバンジェリズム
– LinkedInhttps://www.linkedin.com/in/tatsuokudo
– Twitter @tkudos
About Me
OAuth 2.0 and OpenID Connect in the early 2010s
5
• トークンを用いたAPIアクセス権移譲のフレームワーク
– RFC 6749: トークン付与プロセスと基本的な付与フロー
(認可コード、クライアントクレデンシャルなど)
• 広範なユースケースに適用可能
– トークン付与方式やトークン形式の拡張
– ユーザー、サーバー、クライアント、デバイス、…
OAuth 2.0とは
6
(「トークン」を受け取り
「関連情報」を提供)
「認可グラント」を受け取り
「トークン」を提供
(「認可リクエスト」を受け取り
「認可グラント」を提供)
OAuth 2.0 認可サーバーが行うやりとり
Source: RFC 6749 1.2. Protocol Flow https://tools.ietf.org/html/rfc6749
• Resource Owner
e.g. end user
• User Agent
e.g. Web browser
• Client
e.g. Web application using APIs
• Authorization Server
e.g. user authentication server
• Resource Server
e.g. API server
“OAuth Dance”
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
7
8
• 認可リクエストを受け付けたら
認可コードを返す
• 認可コードをもらったら
アクセストークンを返す
• (アクセストークンつきの
APIリクエストを受け付けて
レスポンスを返す)
OAuth 2.0 認可コードグラントフロー
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
認可
リクエスト
認可
コード
認可
コード アクセス
トークン
アクセス
トークン
APIレスポンス
9
• OIDC認証リクエストを受け付けたら
認可コードを返す
• 認可コードをもらったら
アクセストークンと
IDトークンを返す
– (RPは)IDトークンを用いて
ユーザーを識別する
• アクセストークンつきの
UserInfoリクエストを受け付けて
レスポンスを返す
OpenID Connect 認可コードフロー
Identity Provider
Resource
Owner
User Agent Relying Party
Authorization
Server
UserInfo
Endpoint
OIDC認証
リクエスト
認可
コード
認可
コード アクセス
トークン +
IDトークン
アクセス
トークン
UserInfo
レスポンス
IDトークン
10
• コンパクトかつURL
セーフな「クレーム」
の表現方式
• 署名・暗号化に対応
• OAuth 2.0 における
トークン形式として用
いられることもある
• OpenID Connectでは
JWTを用いてIDトーク
ンを定義している
JWT (JSON Web Token) を用いたトークン表現
{
"iss": "http://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"gender": "female",
"birthdate": "0000-10-31",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}
eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlz
cyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4
Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi
bi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz
MTEyODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6
ICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJm
ZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6
ICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9l
eGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNn
spA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoKrWHcip
R2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2mac
AAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5RZOQ0TLrOY
u0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33TcxkIjNrCD
4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-rDaQzUHl
6cQQWNiDpWOl_lxXjQEvQ
JWS形式の
IDトークン
“OpenID Connect Core1.0,A.2. Example using response_type=id_token”
BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)
ヘッダー
ペイロード
署名
各部分は base64url で
エンコードされている
{"kid":"1e9gdk7","alg":"RS256"}
base64url でデコード
base64url でデコード
(バイナリデータ)
base64url でデコード
JWS Signed JWT の例
11
• 2012年ごろには
全体の構成が確立
• 2015年、主要な
仕様がすべて標準化
…2020年もそのまま!?
OAuth 2.0 関連仕様
Source: OAuth 101 & Secure APIs 2012 Cloud Identity Summit
https://www.slideshare.net/briandav idcampbell/oauth-101-secure-apis-2012-cloud-identity -summit-2012/66
OAuth/OIDC in 2020
OAUTH 2.0 SECURITY BCP
PKCE / Resource Indicators / MTLS / private_key_jwt
14
• 現在のOAuth 2.0の利用状況は当初
(2012年) の想定から乖離
– 実装時の問題:アンチパターンの認識不足
(仕様に書いてあるのに)、OAuth周辺
の技術の変化
– High-stakesな分野への適用:金融・医療
– 多数との動的な連携:クライアントが複数
のAS/RSと連携。かつ動的な連携も
→ 過去の同種のドキュメントを更新
– OAuth 2.0 Threat Model and Security
Considerations (RFC 6819)
– OAuth 2.0 Security Considerations
(RFC 6749 & 6750)
OAuth 2.0 Security Best Current Practice (BCP)
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
Source: draf t-ietf -oauth-security-topics-14 - OAuth 2.0 Security Best Current Practice
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
OAuth 2.0 Security BCPの構成
15
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions and Terminology . . . . . . . . . . . . . . . 4
2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Protecting Redirect-Based Flows . . . . . . . . . . . . . 5
2.1.1. Authorization Code Grant . . . . . . . . . . . . . . 6
2.1.2. Implicit Grant . . . . . . . . . . . . . . . . . . . 6
2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 7
2.3. Access Token Privilege Restriction . . . . . . . . . . . 7
2.4. Resource Owner Password Credentials Grant . . . . . . . . 8
2.5. Client Authentication . . . . . . . . . . . . . . . . . . 8
2.6. Other Recommendations . . . . . . . . . . . . . . . . . . 8
3. The Updated OAuth 2.0 Attacker Model . . . . . . . . . . . . 8
4. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 10
4.1. Insufficient Redirect URI Validation . . . . . . . . . . 11
4.1.1. Redirect URI Validation Attacks on Authorization Code
Grant . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Redirect URI Validation Attacks on Implicit Grant . . 13
4.1.3. Countermeasures . . . . . . . . . . . . . . . . . . . 14
4.2. Credential Leakage via Referer Headers . . . . . . . . . 15
4.2.1. Leakage from the OAuth Client . . . . . . . . . . . . 15
4.2.2. Leakage from the Authorization Server . . . . . . . . 15
4.2.3. Consequences . . . . . . . . . . . . . . . . . . . . 16
4.2.4. Countermeasures . . . . . . . . . . . . . . . . . . . 16
4.3. Credential Leakage via Browser History . . . . . . . . . 17
4.3.1. Authorization Code in Browser History . . . . . . . . 17
4.3.2. Access Token in Browser History . . . . . . . . . . . 17
4.4. Mix-Up Attacks . . . . . . . . . . . . . . . . . . . . . 18
4.4.1. Attack Description . . . . . . . . . . . . . . . . . 18
4.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 20
4.5. Authorization Code Injection . . . . . . . . . . . . . . 21
4.5.1. Attack Description . . . . . . . . . . . . . . . . . 21
4.5.2. Discussion . . . . . . . . . . . . . . . . . . . . . 22
4.5.3. Countermeasures . . . . . . . . . . . . . . . . . . . 23
4.5.4. Limitations . . . . . . . . . . . . . . . . . . . . . 24
4.6. Access Token Injection . . . . . . . . . . . . . . . . . 24
4.6.1. Countermeasures . . . . . . . . . . . . . . . . . . . 25
4.7. Cross Site Request Forgery . . . . . . . . . . . . . . . 25
4.7.1. Countermeasures . . . . . . . . . . . . . . . . . . . 25
4.8. Access Token Leakage at the Resource Server . . . . . . . 25
4.8.1. Access Token Phishing by Counterfeit Resource Server 26
4.8.2. Compromised Resource Server . . . . . . . . . . . . . 31
4.9. Open Redirection . . . . . . . . . . . . . . . . . . . . 31
4.9.1. Client as Open Redirector . . . . . . . . . . . . . . 32
4.9.2. Authorization Server as Open Redirector . . . . . . . 32
4.10. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 32
4.11. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 33
4.12. Refresh Token Protection . . . . . . . . . . . . . . . . 34
4.12.1. Discussion . . . . . . . . . . . . . . . . . . . . . 34
4.12.2. Recommendations . . . . . . . . . . . . . . . . . . 35
4.13. Client Impersonating Resource Owner . . . . . . . . . . . 36
4.13.1. Countermeasures . . . . . . . . . . . . . . . . . . 36
4.14. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 36
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 38
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. Normative References . . . . . . . . . . . . . . . . . . 38
8.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Document History . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
16
• 認可サーバーによる不適切なリダイレクトの防止
• クライアントが「オープンリダイレクター」になることの
防止
• CSRF対策(PKCE or nonce, もしくは state)
• “Mix-up Attack” 対策
• 認可サーバーにおけるユーザークレデンシャルの想定外の
漏洩防止
draft-ietf-oauth-security-topics-14/ 2. Recommendations
2.1. リダイレクトベースのフローの保護
Resource
Server
Native Appsにおける戻し先の乗っ取り
カスタムURLスキームの上書きにより正当なAppではなく攻撃者Appに認可コードが渡る
被害者のスマートフォン
被害者
OS / 標準
ブラウザ
正当なApp
Authorization
Server
攻撃者の
App
カスタムURLスキームを上書き
17
認可レスポンス
認可コード
認可レスポンス
HTTP/1.1 302 Found
Location: <AppのカスタムURLスキーム>
?code=<被害者にひもづく認可コード>
&state=xyz
被害者の
認可コードを
入手
攻撃者の
Appに処理を
引き継ぎ
連携開始
認可リクエスト
GET /authorize
?response_type=code
&client_id=s6BhdRkqt3
&scope=message.readonly
&redirect_uri=<AppのカスタムURLスキーム>
HTTP/1.1
Host: server.example.com
処理開始を指示
認可リクエスト
ユーザー認証・
アクセス承認
Resource
Server
RFC 7636: Proof Key for Code Exchange by OAuth
Public Clients (PKCE) https://datatracker.ietf.org/doc/rfc7636/
18
被害者のスマートフォン
被害者
OS / 標準
ブラウザ
正当なApp
Authorization
Server
攻撃者の
App
カスタムURLスキームを上書き
認可レスポンス
認可コード
認可レスポンス
HTTP/1.1 302 Found
Location: <AppのカスタムURLスキーム>
?code=<被害者にひもづく認可コード>
&state=xyz
被害者の
認可コードを
入手
攻撃者の
Appに処理を
引き継ぎ
トークン
リクエスト
認可コード
code_verifier
が無いため
トークンを取
得できない
認可リクエスト
連携開始
認可リクエスト
GET /authorize
?response_type=code
&client_id=s6BhdRkqt3
&scope=message.readonly
&redirect_uri=<AppのカスタムURLスキーム>
&code_challenge=<code_verifierから
code_challenge_methodに従って生成した値>
&code_challenge_method=S256
HTTP/1.1
Host: server.example.com
code_challenge
受け取りcode_challenge
処理開始を指示
ユーザー認証・
アクセス承認
エンドユーザー サービスサイト 「OAuth認証」サーバー
19
1. 「OAuth認証でログイン」をクリック
2. 「OAuth認証サーバー」にリダイレクト
3. 「ログインしてください」
4. ID/パスワードを送信
5. サービスサイトにリダイレクト
6. 認可コードを送信しアクセストークンを取得
7. アクセストークンを用いてユーザー情報APIにア
クセスし、ユーザー識別子を取得
8. 取得したユーザー識別子をもとにユーザーを特
定してログイン完了
CSRF +「OAuth認証」
アクセストークンを用いてユーザー識別子を取得
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
1
2
3
4
5
6
7
8
認可コード
認可コード
トークン
トークン
ユーザー識別子
エンドユーザー サービスサイト 「OAuth認証」サーバー
CSRF +「OAuth認証」
攻撃者にひもづく認可コードを生成
攻撃者
攻撃者の
Webブラウザ
Client
Authorization
Server
Resource
Server
認可レスポンス
認可レスポンス
HTTP/1.1 302 Found
Location: https://client.example.com/cb
?code=<攻撃者にひもづく認可コード>
認可コード
リダイレクトを
中断して
認可コードを
取得
認可リクエスト
GET /authorize
?response_type=code
&client_id=s6BhdRkqt3
&scope=message.readonly
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
HTTP/1.1
Host: server.example.com
攻撃者自身としてユーザー認証 & 同意確認
「IDひもづけ開始」
20
処理開始を指示
認可リクエスト
ユーザー認証・
アクセス承認
エンドユーザー サービスサイト 「OAuth認証」サーバー
CSRF +「OAuth認証」
被害者が「攻撃者にひもづく認可コード」を送信
被害者
被害者の
Webブラウザ
Client
Authorization
Server
Resource
Server
認可レスポンス
認可コード
被害者に
認可レスポンスを
送信させる
トークン
リクエスト
トークン
レスポンス
認可コード
トークン
トークン
認可レスポンス(CSRF)
GET /cb
?code= <攻撃者にひもづく認可コード>
HTTP/1.1
Host: server.example.com
被害者はクライアントにログイン済
被害者のログイン
情報に攻撃者の
ID情報がひもづく ID情報
21
エンドユーザー サービスサイト 「OAuth認証」サーバー
CSRF +「OAuth認証」
攻撃者が「被害者としてログイン」できる
攻撃者
攻撃者の
Webブラウザ
Client
Authorization
Server
Resource
Server
認可レスポンス
HTTP/1.1 302 Found
Location: https://client.example.com/cb
?code=<攻撃者にひもづく認可コード>
認可リクエスト
攻撃者自身としてユーザー認証 & 同意確認
「OAuth認証開始」
認可レスポンス
認可コード
トークン
リクエスト
トークン
レスポンス
認可コード
トークン
トークン
ID情報
「攻撃者のID情報」をもとに
被害者としてのログインセッションを生成
攻撃者のID情報を返却攻撃者が被害者
のアカウントを
乗っ取る
22
処理開始を指示
認可リクエスト
ユーザー認証・
アクセス承認
エンドユーザー サービスサイト 「OAuth認証」サーバー
stateパラメーターによるCSRF対策
「認可リクエストの送信元」と「認可コードの送信元」が同一であるかをクライアントが確認
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
認可レスポンス
state +
認可コード
認可レスポンス
HTTP/1.1 302 Found
Location: https://client.example.com/cb
?code=<エンドユーザーにひもづく認可コード>
&state=3af23asl0989gnv
認可リクエスト認可リクエスト
GET /authorize
?response_type=code
&client_id=s6BhdRkqt3
&scope=message.readonly
&state=3af23asl0989gnv
&redirect_uri= https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
HTTP/1.1
Host: server.example.com
state
stateの値が
セッションに
ひもづくか
チェック
ユーザーのセッションに
ひもづく値をセット
23
処理開始を指示
ユーザー認証・
アクセス承認
認可リクエスト
トークン
リクエスト
認可レスポンス
24
エンドユーザー サービスサイト 「OAuth認証」サーバー
PKCEによるCSRF対策
「認可リクエストの送信元」と「認可コードの送信元」が同一であるかを認可サーバーが確認
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
認可コード
トークンリクエスト
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=<認可コード>
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&code_verifier=<最初に生成したcode_verifierの値>
認可リクエスト
GET /authorize
?response_type=code
&client_id=s6BhdRkqt3
&scope=message.readonly
&code_challenge=<code_verifierからcode_challenge_methodに従って生
成した値>
&code_challenge_method=S256
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
HTTP/1.1
Host: server.example.com
code_challenge
ユーザーのセッション
からcode_verifierを取得
し、その値を送信
ユーザーのセッションにひもづく値(code_verifier)
を生成し、そのハッシュ値をセット
認可コード +
code_verifier
code_challengeを用いて
認可コードとcode_verifier
とのひもづけを確認
認可コード発行時の
code_challenge
を記録
処理開始を指示
ユーザー認証・
アクセス承認
25
• クライアントにおける認可コード注入(リプレイ)攻撃
対策としてPKCEを推奨(対応していればnonceも可)
• 認可サーバーはPKCE対応が必須
draft-ietf-oauth-security-topics-14/ 2. Recommendations
2.1.1. 認可コードグラント
認可リクエスト
認可レスポンス
トークン
リクエスト
トークンリクエスト
認可コード差し替え攻撃対策としてのPKCE
認可コードの不正利用によるアクセストークン窃取を防止
攻撃者
攻撃者の
Webブラウザ
Client
Authorization
Server
Resource
Server
認可コード
認可コード
認可コード
リダイレクトを
中断して
認可コードを
差し替え
認可リクエスト
GET /authorize
?response_type=code
&client_id=s6BhdRkqt3
&scope=message.readonly
&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&code_challenge=<code_verifierからcode_challenge_methodに従って生成した値>
&code_challenge_method=S256 HTTP/1.1
Host: server.example.com
認可レスポンス
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=<攻撃者にひもづく認可コード>
&state=xyz
認可レスポンス(差し替え後)
GET /cb
?code=<被害者にひもづく認可コード>&state=xyz HTTP/1.1
Host: server.example.com
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=<被害者にひもづく認可コード>
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&code_verifier=<最初に生成したcode_verifierの値>
差し替えられた認可コードは
code_verifierにひもづかない
→ このトークンリクエストは不正
認可コード
発行時の
code_challenge
を記録
code_challenge
受け取り
code_challenge
code_verifier
26
処理開始を指示
ユーザー認証・
アクセス承認
code_verifier /
code_challenge
生成
code_verifier
取出し
code_verifier
チェック
27
• 認可レスポンスからのアクセストークン返却は非推奨
draft-ietf-oauth-security-topics-14/ 2. Recommendations
2.1.2. Implicit Grant
28
• アクセストークンの受け手(オーディエンス)となるリソースサー
バーの限定と、リソースサーバーにおけるアクセストークンのオー
ディエンスのチェック
– クライアントおよび認可サーバーにおける、“scope” パラメーターや “resource”
[I-D.ietf-oauth-resource-indicators] パラメーターの指定
• 加えてアクセストークンを「特定のリソース」や「特定のアクショ
ン」に限定
– クライアントおよび認可サーバーにおける、“scope” パラメーターや
“authorization_details” [I-D.ietf-oauth-rar] パラメーターの指定
draft-ietf-oauth-security-topics-14/ 2. Recommendations
2.3. アクセストークンの権限の制限
29
Resource Indicators for OAuth 2.0
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/
• 認可リクエストにてresourceパ
ラメーターを用いて対象リソー
ス(絶対URI)を指定
– […]&resource=https%3A%2F%2F
cal.example.com%2F&[…]
• さらにトークンリクエストでも
resourceを指定し、効力を限定
したトークンを取得可能
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
処理開始を指示
「リソース」を
含む認可リクエスト
認可レスポンス
「リソース」を
含むトークン
リクエスト
トークン
レスポンス
API
リクエスト
API
レスポンス
(完了)
ユーザー認証・
アクセス承認
イントロス
ペクション
リクエスト
「リソース」
を含む
イントロ
スペクション
レスポンス
30
• リソースオーナーパスワードクレデンシャルズグラント
は利用禁止
draft-ietf-oauth-security-topics-14/ 2. Recommendations
2.4. リソースオーナーパスワードクレデンシャルズグラント
31
• 認可サーバーにおけるクライアント認証の実施を推奨
• mTLS [I-D.draft-ietf-oauth-mtls] もしくは private_key_jwt
[OIDC] のような非対称(公開鍵ベース)の方式を推奨
draft-ietf-oauth-security-topics-14/ 2. Recommendations
2.5. クライアント認証
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
Client’s
X.509 Cert
TLS相互認証
32
• クライアントから提示されたX.509証明書の「サブジェクト識別名(DN)」を登録値と照合
OAuth 2.0 Mutual-TLS ClientAuthentication and Certificate-Bound
Access Tokens (MTLS) https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
トークンリクエスト
• TLS相互認証を行ってクライアントのX.509証明書を取得し、
その証明書のサブジェクトDNをもとにクライアントを認証
• リクエスト内のclient_idの値からクライアントを識別
• そのクライアント情報として事前登録されている「証明書の
サブジェクトDN」の値と照合し認証
トークンレスポンス
• 証明書に結びつけた(バインドした)アクセストークンを返却
APIリクエスト
• TLS相互認証を行いクライアントのX.509証明書を取得
• 証明書とアクセストークンの結びつき(バインド)を確認
処理開始を指示
認可リクエスト
認可レスポンス
トークン
リクエスト
API
リクエスト
ユーザー認証・
アクセス承認
client_id
トークン
レスポンス
Subject DNを
事前登録
33
• 公開鍵暗号により署名された情報(クレームセット)をもとに認証
OIDC Core 1.0 / 9. Client Authentication / private_key_jwt
https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
クレームセット
{
"iss": "55f9f559-2496-49d4-b6c3-351a586b7484”,
"sub": "55f9f559-2496-49d4-b6c3-351a586b7484",
"aud": "https://idp-p.example.com/token",
"iat": 1418698788,
"exp": 1418698848,
"jti": "1418698788/107c4da5194df463e52b56865c5af34e5595"
}
トークンリクエスト
POST /token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: idp-p.example.com
grant_type=authorization_code
&code=sedaFh
&scope=openid+email
&client_id=55f9f559-2496-49d4-b6c3-351a586b7484
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-
assertion-type%3Ajwt-bearer&
client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.
ew0KICAg[...omitted for brevity...].
t-_gX8JQ[...omitted for brevity...]
Signed JWT生成
処理開始を指示
認可リクエスト
認可レスポンス
トークン
リクエスト
API
リクエスト
ユーザー認証・
アクセス承認
トークン
レスポンス
Signed JWT
34
• 認可サーバーおよびリソースサーバーにおいて「送信者
限定アクセストークン」を用いること
– そのしくみとして Mutual TLS for OAuth 2.0 [RFC8705] を推奨
• リフレッシュトークンは送信者限定にすること、もしく
はローテーションすることを必須
• エンドツーエンドのTLSを推奨
draft-ietf-oauth-security-topics-14/ 2. Recommendations
2.2. トークンリプレイの防止
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
35
• トークンリクエスト時のクライアント証明書に、発行するアクセストークンをバインド
OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound
Access Tokens (MTLS) https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
Client’s
X.509 Cert
TLS相互認証
トークンリクエスト
• TLS相互認証を行ってクライアントのX.509証明書を取得し、
その証明書のサブジェクトDNをもとにクライアントを認証
• リクエスト内のclient_idの値からクライアントを識別
• そのクライアント情報として事前登録されている「証明書の
サブジェクトDN」の値と照合し認証
トークンレスポンス
• 証明書に結びつけた(バインドした)アクセストークンを返却
AT, RT
Client’s
X.509 Cert
TLS相互認証
APIリクエスト
• TLS相互認証を行いクライアントのX.509証明書を取得
• 証明書とアクセストークンの結びつき(バインド)を確認
• トークンに含まれる or イントロスペクションの結果と
して得られる、証明書の「サムプリント」を利用
AT
Client’s
X.509 Cert
TLS相互認証
RT + client_id
処理開始を指示
認可リクエスト
認可レスポンス
トークン
リクエスト
ユーザー認証・
アクセス承認
client_id
code
code + client_id
FINANCIAL-GRADE API (FAPI)
Request Object / Hybrid Flow / JARM
37
• 金融 API 向けの OAuth 2.0 適用
プラクティス
• 2016年にOpenID Foundation傘下に
設置されたFAPI WGにて策定中
• 英国Open Bankingや豪州CDRなど
が既に採用
Financial-grade API (FAPI)
Source: https://openid.net/w g/fapi/
FAPIセキュリティ・プロファイル
• Part 1 (Read Only)
– OAuth 2.0 適用のプラクティス
– OAuth 2.0 拡張仕様
– OIDC によるユーザー識別子の授受
• Part 2 (Read & Write): OIDC の積極
的な活用 + 新たな拡張仕様
– Request Object, Hybrid Flow, MTLS,
OAUTB
– JARM
38
OIDC拡張仕様
OIDCプラクティス
OAuth2拡張仕様
OAuth2プラクティス
Part1(ReadOnly)
Part2(Read&Write)
• 認可リクエスト / レスポンスの送信者
詐称・改ざん防止
– Request Objectの利用
– Hybrid FlowもしくはJARMの利用
• 認可コードの漏洩・盗用防止
– redirect_uriの厳密な管理
• クライアントのなりすまし防止
– Mutual TLSもしくはJWTによる
クライアント認証
• トークンの漏洩・盗用防止
– OAUTB(トークン・バインディング)
もしくはMTLS(双方向TLS接続への
バインド)の利用
FAPIにおける “OAuth Dance” の改善・改良
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
(スタート)
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
(完了)
ユーザー認証・
アクセス承認
認可
リクエスト
認可
コード
認可
コード
アクセス
トークン
アクセス
トークン
APIレスポンス
39
リクエストオブジェクト
OIDC認証リクエストへの署名や暗号化
40
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
OIDC認証リクエスト
• 値渡し
• 参照渡し
リクエストオブジェクトのクレーム
{
"iss": "s6BhdRkqt3",
"aud": "https://server.example.com",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.org/cb",
"scope": "openid",
"state": "af0ifjsldkj",
"nonce": "n-0S6_WzA2Mj",
"max_age": 86400,
"claims":
{
"userinfo": { … "email": {"essential": true},…},
"id_token": { "gender": null, …
"acr": {"values": ["urn:mace:incommon:iap:silver"]}
}
}
}
GET /authorize?request=eyJhbGciOiJSUzI1NiIsImtpZCI6Imsy
YmRjIn0.ew0KICJpc3MiOiAiczZCaGRS…
GET /authorize?
request_uri=%3A%2F%2Fclient.example.org%2Frequest.jwt…
リクエストオブジェクト生成
(スタート)
認可リクエスト
認可レスポンス
トークン
リクエスト
トークン
レスポンス
API
リクエスト
ユーザー認証・
アクセス承認
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
フラグメント
取得
フラグメント
送信
state, code,
id_token
Hybrid Flow
認可コードとIDトークンを認可EPから返却
認可リクエスト
GET /authorize
?response_type=code%20id_token
[…]
&state=af0ifjsldkj
Detached Signatureによる検証
トークンリクエスト
トークンレスポンス
code
AT, RT,
ID Token
認可レスポンス
HTTP/1.1 302 Found
Location: https://api.mytpp.com/cb#
code=SplxlOBeZQQYbYS6WxSbIA
&id_token=eyJ0 ... NiJ9.eyJ1c ...
I6IjIifX0.DeWt4Qu ... ZXso
&state=af0ifjsldkj
Detached Signature生成(スタート)
認可リクエスト
認可レスポンス
ユーザー認証・
アクセス承認
(フラグメント)state,
code, id_token#
41
認可リクエスト
42
Detached Signature
検証用の値に署名して本文と別に返却
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
認可レスポンス
HTTP/1.1 302 Found
Location: https://api.mytpp.com/cb#
code=SplxlOBeZQQYbYS6WxSbIA
&id_token=eyJ0 ... NiJ9.eyJ1c ...
I6IjIifX0.DeWt4Qu ... ZXso
&state=af0ifjsldkj
IDトークン(SignedJWT)を検証した上で、c_hash,
s_hashを抽出し、それぞれをもとにcode,stateを検証
{ …
"s_hash": "76sa5dd",
"c_hash": "asd097d" …
}
code=SplxlOBeZQQYbYS6WxSbIA
state=af0ifjsldkj
state
クレームセット
{ …
"s_hash": "76sa5dd",
"c_hash": "asd097d" …
}
IDトークン(Signed JWT)生成
state, code の値が確定
s_hash, c_hash生成
IDトークン(Signed JWT)として
検証できた(改ざんされていない)値
クエリパラメーターとして
受け取った値
(スタート)
認可レスポンス
ユーザー認証・
アクセス承認
(フラグメント)state, code,
id_token (s_hash, c_hash, 署名)#
トークン
リクエスト
トークン
レスポンス
JARM
JWT SecuredAuthorizationResponseMode
for OAuth 2.0
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
code
AT, RT,
ID Token
認可リクエスト
GET /authorize?
response_type=code&response_mode=jwt&[…]
認可レスポンス
HTTP/1.1 302 Found
Location: https://client.example.com/cb?
response=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJpc3MiOiJodHRwczovL2FjY291bnRzLmV4YW1wbGUuY29tIiwiYXVkI
joiczZCaGRSa3F0MyIsImV4cCI6MTMxMTI4MTk3MCwiY29kZSI6IlB5eU
ZhdXgybzdRMFlmWEJVMzJqaHcuNUZYU1FwdnI4YWt2OUNlUkRTZDBRQSI
sInN0YXRlIjoiUzhOSjd1cWs1Zlk0RWpOdlBfR19GdHlKdTZwVXN2SDlq
c1luaTlkTUFKdyJ9.
HkdJ_TYgwBBj10C-aWuNUiA062Amq2b0_oyuc5P0aMTQphAqC2o9WbGSk
pfuHVBowlb-zJ15tBvXDIABL_t83q6ajvjtq_pqsByiRK2dLVdUwKhW3P
_9wjvI0K20gdoTNbNlP9Z41mhart4BqraIoI8e-L_EfAHfhCG_DDDv7Yg
トークンリクエスト
トークンレスポンス
Signed JWT検証
クレームセット
{
"iss": "https://accounts.example.com",
"aud": "s6BhdRkqt3",
"exp": 1311281970,
"code": "PyyFaux2o7Q0YfXBU32jhw.5FXSQpvr8akv9CeRDSd0QA",
"state": "S8NJ7uqk5fY4EjNvP_G_FtyJu6pUsvH9jsYni9dMAJw"
}
response(SignedJWT)生成
(スタート)
認可リクエスト
認可レスポンス
ユーザー認証・
アクセス承認
response (code, state, 署名)
43
44
• Removed
– OAuth 2.0 Token Binding
– code id_token and code id_token token
– LoA3
– Public client support
• Separated
– Pushed Request Object https://bitbucket.org/openid/fapi/src/master/Financial_API_Pushed_Request_Object.md
• Promoted
– JARM as an alternative to Hybrid Flow
• Added
– 60-minute lifetime for exp in Request Object
FAPIセキュリティプロファイルの現状
(実装者向けドラフト第2版以降)
“LODGING INTENT PATTERN”
PAR / RAR
46
• リソースオーナー(ユーザー)がク
ライアントに移譲する権限の粒度
– APIによってアクセス可能な
データの種類・範囲
(e.g. 口座情報、取引履歴)
– APIによって実行可能な機能の
範囲(e.g. 参照、決済、送金)
• 「ある特定の取引」「同意した範囲
でのデータ取得」のような粒度を表
現するにはどうするか?
OAuth における「スコープ」 (scope)
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
(スタート)
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
(完了)
ユーザー認証・
アクセス承認
GET /authorize?
response_type=code&
client_id=287560982&
redirect_uri=https://
client.example.org/cb&
scope=payment&…
「インテント」の導入
47
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
処理開始を指示
「インテントID」を含む
認可リクエスト
認可レスポンス
トークン
リクエスト
「インテント」に
のみ行使可能な
トークンを返却
API
リクエスト
API
レスポンス
(完了)
取引内容への
承認を確認
「インテント」登録
「インテントID」返却
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
(スタート)
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
(完了)
ユーザー認証・
アクセス承認
48
• サードパーティが銀行のAPIに、
口座情報取得や決済指図伝達な
どの「インテント」を事前登録
• 登録された内容を利用者が
銀行のWebサイトや
アプリにて確認・承認
• 承認後、サードパーティが「イ
ンテント」の内容の実行を銀行
のAPIにリクエスト
インテントによる「取引単位」のアクセス認可
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
処理開始を指示
「インテントID」を含む
認可リクエスト
認可レスポンス
トークン
リクエスト
「インテント」に
のみ行使可能な
トークンを返却
API
リクエスト
API
レスポンス
(完了)
取引内容への
承認を確認
「インテント」登録
「インテントID」返却
49
• FAPI WG が “Lodging Intent Pattern” に注目
https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-intent
– 事前にクライアントが認可サーバーに “intent” を
登録し、返却されたその intent の「ハンドル」を認可リ
クエストに付加
– UK Open Banking では essential claim、Berlin Group
NextGenPSD2 では dynamic scope にて表現
• OAuth 2.0の認可リクエストを拡張する仕様として
現在IETF OAuth WGにて議論が進行中
– OAuth 2.0 Rich Authorization Requests
– OAuth 2.0 Pushed Authorization Requests
「インテント」の標準化
Source: https://www.slideshare.net/tkudo/osw2019/7
Source: https://medium.com/oauth-2/rich-oauth-2-0-
authorization-requests-87870e263ecb
50
• PARエンドポイント(新規)
– クライアントが認可サーバーに「複雑な認可
リクエスト」を登録し、認可サーバーが「リ
クエストURI」を返却
– 認可サーバーがクライアントを認証可能
• 認可エンドポイント(拡張)
– クライアントが認可サーバーに、リクエスト
URIを含む「単純な認可リクエスト」を送信
• https://as.example.com/authorize?
request_uri=<リクエストURI>&…
– ユーザーエージェントによって中継される情
報を最小化
OAuth 2.0 Pushed Authorization Requests (PAR)
https://datatracker.ietf.org/doc/draft-ietf-oauth-par/
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
処理開始を指示
「リクエストURI」を
含む認可リクエスト
認可レスポンス
トークン
リクエスト
トークン
レスポンス
API
リクエスト
API
レスポンス
(完了)
ユーザー認証・
アクセス承認
「複雑な認可
リクエスト」登録
「リクエスト
URI」返却
PAR
EP
Authz
EP
51
• “authorization_details” パラメーター
(新規)
– クライアントが認可サーバーに「詳細な認可
リクエスト」を送信
• https://as.example.com/authorize?
response_type=code&
client_id=6493509078&scope=email&
authorization_details=[{“type”:“type0”,
"locations":["loc0","loc1"],"hello":"world"}]
– 認可サーバーはこの内容を、認可決定に用い
ると同時に、トークンレスポンスやイントロ
スペクションレスポンスとして、それぞれク
ライアントとリソースサーバーに提供
OAuth 2.0 Rich Authorization Requests (RAR)
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
処理開始を指示
「認可詳細」を
含む認可リクエスト
認可レスポンス
トークン
リクエスト
「認可詳細」を
含むトークン
レスポンス
API
リクエスト
API
レスポンス
(完了)
ユーザー認証・
アクセス承認
イントロス
ペクション
リクエスト
認可詳細」
を含むイン
トロスペク
ションレス
ポンス
これからのOAuth/OIDC
UTILIZING END-USER DEVICES
Device Authorization Grant / CIBA
53
54
“Redirect Flow”
Source: マネーフォワード, Google
ユーザー ユーザー・エージェント
1. 「外部サイトで
ログイン」
2. リダイレクト 4. リダイレクト 3. 認証
RFC 8628: OAuth 2.0 Device Authorization Grant
https://datatracker.ietf.org/doc/rfc8628/
ユーザー
クライアント
(デバイス)
認可・APIサーバー
DA EP
API(6)
(6) トークン
を使ってAPI
アクセス
1
1. デバイス認可
リクエスト
2
2. デバイス認可
レスポンス
dev ice_code, user_code etc. デバイス認可
エンドポイント
4’
4’. ユーザー認証
& user_code入力
55
3
3. user_code
表示
Token EP
Web ブラウザ
5
5. トークン
レスポンス
00. スタート
4 dev ice_code etc.
4. トークン
リクエスト
(ポーリング)
ある意味では、ユーザーによる「リダイレクト」
ユーザー
クライアント
(デバイス)
認可・APIサーバー
56
user_code
Web ブラウザ
ユーザーを介さない認証・認可フローはどうか?
ユーザー
クライアント
(デバイス)
認可・APIサーバー
57認証デバイス
“Decoupled Flow”
• 「アレクサ、お店に
5,000円払って」
→ 手元のケータイに
決済サービスAppから
通知
58Source: https://www.europeanpay mentscouncil.eu/document-library /minutes-and-agendas/authentication-sca-guidance-key -topic-clarif ication-api
“Decoupled Flow”
• TVショッピングとかで、
– 視聴者が電話で購入希望を伝える
– オペレーターに「ではお客さまのスマート
フォンに注文内容をお送りします。ご確認
をお願いします」と言われる
– 視聴者は手元のスマートフォンにきた、決
済サービスAppからの通知をみて承認する
– 店舗への決済が行われる
59
“Decoupled Flow”
• 仮に Ponta の ID と決済できるとこのIDが
紐づいてたら
– コンビニ店員「Pontaカードカモン」
– 客「はい」
– 店員「XXX円です」
– 客「CIBAPay(ダッサ)」
– 店員「はい(ポチ)」
– 客のスマホ「(XXX円をローソンに支払います。
よろしいですか?)」
– 客「おk」
– 店員「支払いおわた。レシートどぞ」
ぐらいは出来そうです
Source: https://ritou.hatenablog.com/entry /2018/12/29/224452 60
61
• OpenID Foundation 傘下のWGにて策定中の新たなオープン仕様
– 「サービスを利用するデバイス」と「認証を行うデバイス」を分離
• より良い顧客体験 (CX) の提供とセキュリティ強化に有用
OpenID Connect Client Initiated Backchannel
Authentication (CIBA) Flow - Core 1.0
https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html
CIBA のフロー
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
(リライング・
パーティ)
認可・APIサーバー
(アイデンティティ・
プロバイダー)
0
0. ユーザーの
識別子を把握
login_hint_token
id_token_hint
login_hint
BA EP
API
(*) Access Token
(**) Refresh Token
(4)
(4) トークン
を使ってAPI
アクセス
(4)
(4) 認証結果を
利用して処理を
実行
1
1. 認証
リクエスト
User
Identif ier
2
2. 受付応答
AuthN Req ID
3
3. 認証結果と
トークンを返却
(Poll / Ping /
Push)
ID Token / AT* / (RT**)
バックチャネル認証
エンドポイント
2’
2’. ユーザー
認証
62
ASSURED IDENTITY
IDA
63
Identity Provider
64
• “verified_claims” (新規)
– 「検証済クレーム」
– OIDCのクレームとして定義
• RPは「取得したい検証済ク
レームとその内容」を、認証
リクエストのclaimsパラメー
ターを用いて指定
• IdPはIDトークンやUserInfo
レスポンスとして、検証済ク
レームを返却
OpenID Connect for Identity Assurance 1.0
https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html
Resource
Owner
User Agent Relying Party
Authorization
Server
UserInfo
Endpoint
処理開始を指示
取得したい「検証済クレーム」を
含む認証リクエスト
認可レスポンス
トークン
リクエスト
「検証済
クレーム」を
含むトークン
レスポンス
UserInfo
リクエスト
(完了)
ユーザー認証・
アクセス承認
「検証済
クレーム」を
含むUserInfo
レスポンス
まとめ
66
• 2010年代前半に確立したOAuth 2.0 / OpenID Connectは2020
年の環境においても十分通用する
• 一方で現在も、活用領域の拡大・高度化につれて、関連仕様
の策定や適用方法の更新が続いている
• 2015年以降の仕様・プラクティスは、新たなサービスや今後
のアーキテクチャを考える上での参考として役立つ(かも)
まとめ
Authleteは本日紹介した仕様のすべてに対応
https://www.authlete.com/ja/legal/spec_sheet/
67
プロトコル処理とトークン管理をAuthleteが代行
68
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
(スタート)
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
ユーザー認証・
アクセス承認
Authlete API
認可リクエスト
処理
認可コード生成
トークンリクエスト
処理
アクセス
トークン
検証
/auth/authorizationPOST
/auth/authorization/issuePOST
/auth/tokenPOST
/auth/introspectionPOST
69
AuthleteにおけるFAPI Part 2サポートの例
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
(スタート)
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
ユーザー認証・
アクセス承認
Authlete API
認可リクエスト
処理
認可コード生成
トークンリクエスト
処理
アクセス
トークン
検証
/auth/authorizationPOST
/auth/authorization/issuePOST
/auth/tokenPOST
/auth/introspectionPOST
• リクエストオブジェクト使用の必須化
• ハイブリッドフロー or JARM要求の必須化
• 認証コンテキストリファレンス(acr)クレームの必須化
• ハイブリッドフロー or JARMでのレスポンス生成
• クライアント証明書送付の必須化
• クライアント証明書送付の必須化
70
• 弊社川崎 @darutk の記事
– https://qiita.com/TakahikoKawasaki
• Authlete API チュートリアル
– https://www.authlete.com/ja/developers/tutorial/
• プレゼンテーション資料
– https://www.slideshare.net/tkudo
– https://speakerdeck.com/takahikokawasaki/
リソース
Thank You
www.authlete.com
www.linkedin.com/in/tatsuokudo

More Related Content

What's hot

認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜Masaru Kurahayashi
 
これからのネイティブアプリにおけるOpenID Connectの活用
これからのネイティブアプリにおけるOpenID Connectの活用これからのネイティブアプリにおけるOpenID Connectの活用
これからのネイティブアプリにおけるOpenID Connectの活用Masaru Kurahayashi
 
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
KeycloakでFAPIに対応した高セキュリティなAPIを公開するKeycloakでFAPIに対応した高セキュリティなAPIを公開する
KeycloakでFAPIに対応した高セキュリティなAPIを公開するHitachi, Ltd. OSS Solution Center.
 
OpenID Connect入門
OpenID Connect入門OpenID Connect入門
OpenID Connect入門土岐 孝平
 
3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal3分でわかるAzureでのService Principal
3分でわかるAzureでのService PrincipalToru Makabe
 
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDayマイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay都元ダイスケ Miyamoto
 
分散型IDと検証可能なアイデンティティ技術概要
分散型IDと検証可能なアイデンティティ技術概要分散型IDと検証可能なアイデンティティ技術概要
分散型IDと検証可能なアイデンティティ技術概要Naohiro Fujie
 
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)Tatsuo Kudo
 
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューションOAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューションTatsuo Kudo
 
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawawsOAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawawsTatsuo Kudo
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021Hiroshi Tokumaru
 
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールこんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールdcubeio
 
SSIとDIDで何を解決したいのか?(β版)
SSIとDIDで何を解決したいのか?(β版)SSIとDIDで何を解決したいのか?(β版)
SSIとDIDで何を解決したいのか?(β版)Naohiro Fujie
 
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能Kohei Tokunaga
 
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPCマイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPCdisc99_
 
Kongの概要と導入事例
Kongの概要と導入事例Kongの概要と導入事例
Kongの概要と導入事例briscola-tokyo
 

What's hot (20)

Keycloakの最近のトピック
Keycloakの最近のトピックKeycloakの最近のトピック
Keycloakの最近のトピック
 
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜
 
これからのネイティブアプリにおけるOpenID Connectの活用
これからのネイティブアプリにおけるOpenID Connectの活用これからのネイティブアプリにおけるOpenID Connectの活用
これからのネイティブアプリにおけるOpenID Connectの活用
 
FIDOのキホン
FIDOのキホンFIDOのキホン
FIDOのキホン
 
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
KeycloakでFAPIに対応した高セキュリティなAPIを公開するKeycloakでFAPIに対応した高セキュリティなAPIを公開する
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
 
OAuth 2.0のResource Serverの作り方
OAuth 2.0のResource Serverの作り方OAuth 2.0のResource Serverの作り方
OAuth 2.0のResource Serverの作り方
 
OpenID Connect入門
OpenID Connect入門OpenID Connect入門
OpenID Connect入門
 
3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal3分でわかるAzureでのService Principal
3分でわかるAzureでのService Principal
 
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDayマイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
 
分散型IDと検証可能なアイデンティティ技術概要
分散型IDと検証可能なアイデンティティ技術概要分散型IDと検証可能なアイデンティティ技術概要
分散型IDと検証可能なアイデンティティ技術概要
 
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)
 
Keycloak入門
Keycloak入門Keycloak入門
Keycloak入門
 
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューションOAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
 
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawawsOAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
 
こんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツールこんなに使える!今どきのAPIドキュメンテーションツール
こんなに使える!今どきのAPIドキュメンテーションツール
 
SSIとDIDで何を解決したいのか?(β版)
SSIとDIDで何を解決したいのか?(β版)SSIとDIDで何を解決したいのか?(β版)
SSIとDIDで何を解決したいのか?(β版)
 
BuildKitの概要と最近の機能
BuildKitの概要と最近の機能BuildKitの概要と最近の機能
BuildKitの概要と最近の機能
 
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPCマイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
 
Kongの概要と導入事例
Kongの概要と導入事例Kongの概要と導入事例
Kongの概要と導入事例
 

Similar to いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete

技術書典4 く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版
 技術書典4  く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版 技術書典4  く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版
技術書典4 く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版Hiroyuki Ohnaka
 
BYOD_Policy_JP-1.0.pdf
BYOD_Policy_JP-1.0.pdfBYOD_Policy_JP-1.0.pdf
BYOD_Policy_JP-1.0.pdfHisaho Nakata
 
Rの拡張を書く (R 2.15.2)
Rの拡張を書く (R 2.15.2)Rの拡張を書く (R 2.15.2)
Rの拡張を書く (R 2.15.2)itoyan110
 
Windows azure stepbystep_tutorialguide
Windows azure stepbystep_tutorialguideWindows azure stepbystep_tutorialguide
Windows azure stepbystep_tutorialguideYoshida Yuri
 
00_O365_SecureConfigurationAlignment_JP_v1.0.pdf
00_O365_SecureConfigurationAlignment_JP_v1.0.pdf00_O365_SecureConfigurationAlignment_JP_v1.0.pdf
00_O365_SecureConfigurationAlignment_JP_v1.0.pdfHisaho Nakata
 
Citrix XenServer ® 5.6 Service Pack 2 管理者ガイド
Citrix XenServer ® 5.6 Service Pack 2 管理者ガイド Citrix XenServer ® 5.6 Service Pack 2 管理者ガイド
Citrix XenServer ® 5.6 Service Pack 2 管理者ガイド sjeho
 
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版Hiroyuki Ohnaka
 
ワンストップ技術書を書こう おためし版
ワンストップ技術書を書こう おためし版ワンストップ技術書を書こう おためし版
ワンストップ技術書を書こう おためし版親方 親方
 
コーディング規約「Scratch編」v1.0
コーディング規約「Scratch編」v1.0コーディング規約「Scratch編」v1.0
コーディング規約「Scratch編」v1.0satoshi59
 
Linux+PHPを学んで日程調整アプリを作ろう①
Linux+PHPを学んで日程調整アプリを作ろう①Linux+PHPを学んで日程調整アプリを作ろう①
Linux+PHPを学んで日程調整アプリを作ろう①Aina Hara
 
卒業論文「主張と根拠のクラスタを用いた 多様な主張を提示するニュース推薦手法の提案」
卒業論文「主張と根拠のクラスタを用いた 多様な主張を提示するニュース推薦手法の提案」卒業論文「主張と根拠のクラスタを用いた 多様な主張を提示するニュース推薦手法の提案」
卒業論文「主張と根拠のクラスタを用いた 多様な主張を提示するニュース推薦手法の提案」Nagi Kataoka
 
コーディング規約_Scratch編_v1.1
コーディング規約_Scratch編_v1.1コーディング規約_Scratch編_v1.1
コーディング規約_Scratch編_v1.1satoshi59
 
It crコンサルティング
It crコンサルティングIt crコンサルティング
It crコンサルティング翔央 古川
 
Mathworks installation help_ja_jp
Mathworks installation help_ja_jpMathworks installation help_ja_jp
Mathworks installation help_ja_jpEddie Muñoz
 
Unspsc product classification process and samples
Unspsc product classification process and samples Unspsc product classification process and samples
Unspsc product classification process and samples Indra kumar
 
Instalaciones de servidores ejemplo
Instalaciones de servidores ejemploInstalaciones de servidores ejemplo
Instalaciones de servidores ejemploGary Flores Marcos
 
PostgreSQL 11 New Features With Examples (Japanese)
PostgreSQL 11 New Features With Examples (Japanese)PostgreSQL 11 New Features With Examples (Japanese)
PostgreSQL 11 New Features With Examples (Japanese)Noriyoshi Shinoda
 

Similar to いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete (20)

技術書典4 く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版
 技術書典4  く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版 技術書典4  く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版
技術書典4 く-35「錬金術MeetUp」 Alchemist Vol.1 サンプル版
 
BYOD_Policy_JP-1.0.pdf
BYOD_Policy_JP-1.0.pdfBYOD_Policy_JP-1.0.pdf
BYOD_Policy_JP-1.0.pdf
 
Rの拡張を書く (R 2.15.2)
Rの拡張を書く (R 2.15.2)Rの拡張を書く (R 2.15.2)
Rの拡張を書く (R 2.15.2)
 
Windows azure stepbystep_tutorialguide
Windows azure stepbystep_tutorialguideWindows azure stepbystep_tutorialguide
Windows azure stepbystep_tutorialguide
 
Thes qpsk
Thes qpskThes qpsk
Thes qpsk
 
00_O365_SecureConfigurationAlignment_JP_v1.0.pdf
00_O365_SecureConfigurationAlignment_JP_v1.0.pdf00_O365_SecureConfigurationAlignment_JP_v1.0.pdf
00_O365_SecureConfigurationAlignment_JP_v1.0.pdf
 
Citrix XenServer ® 5.6 Service Pack 2 管理者ガイド
Citrix XenServer ® 5.6 Service Pack 2 管理者ガイド Citrix XenServer ® 5.6 Service Pack 2 管理者ガイド
Citrix XenServer ® 5.6 Service Pack 2 管理者ガイド
 
Tour
TourTour
Tour
 
Tour
TourTour
Tour
 
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版
4/22 技術書典4 か-16「ふぃーるどのーつ」 新刊「すいーとみゅーじっく vol.5Mackerelではじめるお手軽サーバー監視」サンプル版
 
ワンストップ技術書を書こう おためし版
ワンストップ技術書を書こう おためし版ワンストップ技術書を書こう おためし版
ワンストップ技術書を書こう おためし版
 
コーディング規約「Scratch編」v1.0
コーディング規約「Scratch編」v1.0コーディング規約「Scratch編」v1.0
コーディング規約「Scratch編」v1.0
 
Linux+PHPを学んで日程調整アプリを作ろう①
Linux+PHPを学んで日程調整アプリを作ろう①Linux+PHPを学んで日程調整アプリを作ろう①
Linux+PHPを学んで日程調整アプリを作ろう①
 
卒業論文「主張と根拠のクラスタを用いた 多様な主張を提示するニュース推薦手法の提案」
卒業論文「主張と根拠のクラスタを用いた 多様な主張を提示するニュース推薦手法の提案」卒業論文「主張と根拠のクラスタを用いた 多様な主張を提示するニュース推薦手法の提案」
卒業論文「主張と根拠のクラスタを用いた 多様な主張を提示するニュース推薦手法の提案」
 
コーディング規約_Scratch編_v1.1
コーディング規約_Scratch編_v1.1コーディング規約_Scratch編_v1.1
コーディング規約_Scratch編_v1.1
 
It crコンサルティング
It crコンサルティングIt crコンサルティング
It crコンサルティング
 
Mathworks installation help_ja_jp
Mathworks installation help_ja_jpMathworks installation help_ja_jp
Mathworks installation help_ja_jp
 
Unspsc product classification process and samples
Unspsc product classification process and samples Unspsc product classification process and samples
Unspsc product classification process and samples
 
Instalaciones de servidores ejemplo
Instalaciones de servidores ejemploInstalaciones de servidores ejemplo
Instalaciones de servidores ejemplo
 
PostgreSQL 11 New Features With Examples (Japanese)
PostgreSQL 11 New Features With Examples (Japanese)PostgreSQL 11 New Features With Examples (Japanese)
PostgreSQL 11 New Features With Examples (Japanese)
 

More from Tatsuo Kudo

Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」Tatsuo Kudo
 
金融APIセキュリティの動向・事例と今後の方向性
金融APIセキュリティの動向・事例と今後の方向性金融APIセキュリティの動向・事例と今後の方向性
金融APIセキュリティの動向・事例と今後の方向性Tatsuo Kudo
 
Client Initiated Backchannel Authentication (CIBA) and Authlete’s Approach
Client Initiated Backchannel Authentication (CIBA) and Authlete’s ApproachClient Initiated Backchannel Authentication (CIBA) and Authlete’s Approach
Client Initiated Backchannel Authentication (CIBA) and Authlete’s ApproachTatsuo Kudo
 
In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021
In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021
In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021Tatsuo Kudo
 
Authlete: API Authorization Enabler for API Economy
Authlete: API Authorization Enabler for API EconomyAuthlete: API Authorization Enabler for API Economy
Authlete: API Authorization Enabler for API EconomyTatsuo Kudo
 
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizdayTatsuo Kudo
 
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_insideAuthlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_insideTatsuo Kudo
 
Financial-grade API Hands-on with Authlete
Financial-grade API Hands-on with AuthleteFinancial-grade API Hands-on with Authlete
Financial-grade API Hands-on with AuthleteTatsuo Kudo
 
Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...
Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...
Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...Tatsuo Kudo
 
英国オープンバンキング技術仕様の概要
英国オープンバンキング技術仕様の概要英国オープンバンキング技術仕様の概要
英国オープンバンキング技術仕様の概要Tatsuo Kudo
 
オープン API と Authlete のソリューション
オープン API と Authlete のソリューションオープン API と Authlete のソリューション
オープン API と Authlete のソリューションTatsuo Kudo
 
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...Tatsuo Kudo
 
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019Tatsuo Kudo
 
APIエコノミー時代の認証・認可
APIエコノミー時代の認証・認可APIエコノミー時代の認証・認可
APIエコノミー時代の認証・認可Tatsuo Kudo
 
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...Tatsuo Kudo
 
Japan/UK Open Banking and APIs Summit 2018 TOI
Japan/UK Open Banking and APIs Summit 2018 TOIJapan/UK Open Banking and APIs Summit 2018 TOI
Japan/UK Open Banking and APIs Summit 2018 TOITatsuo Kudo
 
Trends in Banking APIs
Trends in Banking APIsTrends in Banking APIs
Trends in Banking APIsTatsuo Kudo
 
銀行APIのトレンド #fapisum
銀行APIのトレンド #fapisum銀行APIのトレンド #fapisum
銀行APIのトレンド #fapisumTatsuo Kudo
 
アイデンティティ (ID) 技術の最新動向とこれから
アイデンティティ (ID) 技術の最新動向とこれからアイデンティティ (ID) 技術の最新動向とこれから
アイデンティティ (ID) 技術の最新動向とこれからTatsuo Kudo
 
OAuth Security Workshop 2017 #osw17
OAuth Security Workshop 2017 #osw17OAuth Security Workshop 2017 #osw17
OAuth Security Workshop 2017 #osw17Tatsuo Kudo
 

More from Tatsuo Kudo (20)

Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
 
金融APIセキュリティの動向・事例と今後の方向性
金融APIセキュリティの動向・事例と今後の方向性金融APIセキュリティの動向・事例と今後の方向性
金融APIセキュリティの動向・事例と今後の方向性
 
Client Initiated Backchannel Authentication (CIBA) and Authlete’s Approach
Client Initiated Backchannel Authentication (CIBA) and Authlete’s ApproachClient Initiated Backchannel Authentication (CIBA) and Authlete’s Approach
Client Initiated Backchannel Authentication (CIBA) and Authlete’s Approach
 
In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021
In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021
In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021
 
Authlete: API Authorization Enabler for API Economy
Authlete: API Authorization Enabler for API EconomyAuthlete: API Authorization Enabler for API Economy
Authlete: API Authorization Enabler for API Economy
 
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
 
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_insideAuthlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
 
Financial-grade API Hands-on with Authlete
Financial-grade API Hands-on with AuthleteFinancial-grade API Hands-on with Authlete
Financial-grade API Hands-on with Authlete
 
Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...
Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...
Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...
 
英国オープンバンキング技術仕様の概要
英国オープンバンキング技術仕様の概要英国オープンバンキング技術仕様の概要
英国オープンバンキング技術仕様の概要
 
オープン API と Authlete のソリューション
オープン API と Authlete のソリューションオープン API と Authlete のソリューション
オープン API と Authlete のソリューション
 
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
 
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019
 
APIエコノミー時代の認証・認可
APIエコノミー時代の認証・認可APIエコノミー時代の認証・認可
APIエコノミー時代の認証・認可
 
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
 
Japan/UK Open Banking and APIs Summit 2018 TOI
Japan/UK Open Banking and APIs Summit 2018 TOIJapan/UK Open Banking and APIs Summit 2018 TOI
Japan/UK Open Banking and APIs Summit 2018 TOI
 
Trends in Banking APIs
Trends in Banking APIsTrends in Banking APIs
Trends in Banking APIs
 
銀行APIのトレンド #fapisum
銀行APIのトレンド #fapisum銀行APIのトレンド #fapisum
銀行APIのトレンド #fapisum
 
アイデンティティ (ID) 技術の最新動向とこれから
アイデンティティ (ID) 技術の最新動向とこれからアイデンティティ (ID) 技術の最新動向とこれから
アイデンティティ (ID) 技術の最新動向とこれから
 
OAuth Security Workshop 2017 #osw17
OAuth Security Workshop 2017 #osw17OAuth Security Workshop 2017 #osw17
OAuth Security Workshop 2017 #osw17
 

いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete

  • 3. 3 • サン・マイクロシステムズ、野村総合研究所、 NRI セキュアを経て、2018年からAuthlete 社に て VP of Solution Strategy を担当 • 専門はデジタル・アイデンティティを中心とする プリセールス、コンサルティング、事業開発、 エバンジェリズム – LinkedInhttps://www.linkedin.com/in/tatsuokudo – Twitter @tkudos About Me
  • 4. OAuth 2.0 and OpenID Connect in the early 2010s
  • 5. 5 • トークンを用いたAPIアクセス権移譲のフレームワーク – RFC 6749: トークン付与プロセスと基本的な付与フロー (認可コード、クライアントクレデンシャルなど) • 広範なユースケースに適用可能 – トークン付与方式やトークン形式の拡張 – ユーザー、サーバー、クライアント、デバイス、… OAuth 2.0とは
  • 7. • Resource Owner e.g. end user • User Agent e.g. Web browser • Client e.g. Web application using APIs • Authorization Server e.g. user authentication server • Resource Server e.g. API server “OAuth Dance” Resource Owner User Agent Client Authorization Server Resource Server 7
  • 8. 8 • 認可リクエストを受け付けたら 認可コードを返す • 認可コードをもらったら アクセストークンを返す • (アクセストークンつきの APIリクエストを受け付けて レスポンスを返す) OAuth 2.0 認可コードグラントフロー Resource Owner User Agent Client Authorization Server Resource Server 認可 リクエスト 認可 コード 認可 コード アクセス トークン アクセス トークン APIレスポンス
  • 9. 9 • OIDC認証リクエストを受け付けたら 認可コードを返す • 認可コードをもらったら アクセストークンと IDトークンを返す – (RPは)IDトークンを用いて ユーザーを識別する • アクセストークンつきの UserInfoリクエストを受け付けて レスポンスを返す OpenID Connect 認可コードフロー Identity Provider Resource Owner User Agent Relying Party Authorization Server UserInfo Endpoint OIDC認証 リクエスト 認可 コード 認可 コード アクセス トークン + IDトークン アクセス トークン UserInfo レスポンス IDトークン
  • 10. 10 • コンパクトかつURL セーフな「クレーム」 の表現方式 • 署名・暗号化に対応 • OAuth 2.0 における トークン形式として用 いられることもある • OpenID Connectでは JWTを用いてIDトーク ンを定義している JWT (JSON Web Token) を用いたトークン表現 { "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": "janedoe@example.com", "picture": "http://example.com/janedoe/me.jpg" } eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlz cyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4 Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi bi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz MTEyODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6 ICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJm ZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6 ICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9l eGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNn spA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoKrWHcip R2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2mac AAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5RZOQ0TLrOY u0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33TcxkIjNrCD 4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-rDaQzUHl 6cQQWNiDpWOl_lxXjQEvQ JWS形式の IDトークン “OpenID Connect Core1.0,A.2. Example using response_type=id_token” BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature) ヘッダー ペイロード 署名 各部分は base64url で エンコードされている {"kid":"1e9gdk7","alg":"RS256"} base64url でデコード base64url でデコード (バイナリデータ) base64url でデコード JWS Signed JWT の例
  • 11. 11 • 2012年ごろには 全体の構成が確立 • 2015年、主要な 仕様がすべて標準化 …2020年もそのまま!? OAuth 2.0 関連仕様 Source: OAuth 101 & Secure APIs 2012 Cloud Identity Summit https://www.slideshare.net/briandav idcampbell/oauth-101-secure-apis-2012-cloud-identity -summit-2012/66
  • 13. OAUTH 2.0 SECURITY BCP PKCE / Resource Indicators / MTLS / private_key_jwt
  • 14. 14 • 現在のOAuth 2.0の利用状況は当初 (2012年) の想定から乖離 – 実装時の問題:アンチパターンの認識不足 (仕様に書いてあるのに)、OAuth周辺 の技術の変化 – High-stakesな分野への適用:金融・医療 – 多数との動的な連携:クライアントが複数 のAS/RSと連携。かつ動的な連携も → 過去の同種のドキュメントを更新 – OAuth 2.0 Threat Model and Security Considerations (RFC 6819) – OAuth 2.0 Security Considerations (RFC 6749 & 6750) OAuth 2.0 Security Best Current Practice (BCP) https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ Source: draf t-ietf -oauth-security-topics-14 - OAuth 2.0 Security Best Current Practice https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
  • 15. OAuth 2.0 Security BCPの構成 15 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 4 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Protecting Redirect-Based Flows . . . . . . . . . . . . . 5 2.1.1. Authorization Code Grant . . . . . . . . . . . . . . 6 2.1.2. Implicit Grant . . . . . . . . . . . . . . . . . . . 6 2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 7 2.3. Access Token Privilege Restriction . . . . . . . . . . . 7 2.4. Resource Owner Password Credentials Grant . . . . . . . . 8 2.5. Client Authentication . . . . . . . . . . . . . . . . . . 8 2.6. Other Recommendations . . . . . . . . . . . . . . . . . . 8 3. The Updated OAuth 2.0 Attacker Model . . . . . . . . . . . . 8 4. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 10 4.1. Insufficient Redirect URI Validation . . . . . . . . . . 11 4.1.1. Redirect URI Validation Attacks on Authorization Code Grant . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Redirect URI Validation Attacks on Implicit Grant . . 13 4.1.3. Countermeasures . . . . . . . . . . . . . . . . . . . 14 4.2. Credential Leakage via Referer Headers . . . . . . . . . 15 4.2.1. Leakage from the OAuth Client . . . . . . . . . . . . 15 4.2.2. Leakage from the Authorization Server . . . . . . . . 15 4.2.3. Consequences . . . . . . . . . . . . . . . . . . . . 16 4.2.4. Countermeasures . . . . . . . . . . . . . . . . . . . 16 4.3. Credential Leakage via Browser History . . . . . . . . . 17 4.3.1. Authorization Code in Browser History . . . . . . . . 17 4.3.2. Access Token in Browser History . . . . . . . . . . . 17 4.4. Mix-Up Attacks . . . . . . . . . . . . . . . . . . . . . 18 4.4.1. Attack Description . . . . . . . . . . . . . . . . . 18 4.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 20 4.5. Authorization Code Injection . . . . . . . . . . . . . . 21 4.5.1. Attack Description . . . . . . . . . . . . . . . . . 21 4.5.2. Discussion . . . . . . . . . . . . . . . . . . . . . 22 4.5.3. Countermeasures . . . . . . . . . . . . . . . . . . . 23 4.5.4. Limitations . . . . . . . . . . . . . . . . . . . . . 24 4.6. Access Token Injection . . . . . . . . . . . . . . . . . 24 4.6.1. Countermeasures . . . . . . . . . . . . . . . . . . . 25 4.7. Cross Site Request Forgery . . . . . . . . . . . . . . . 25 4.7.1. Countermeasures . . . . . . . . . . . . . . . . . . . 25 4.8. Access Token Leakage at the Resource Server . . . . . . . 25 4.8.1. Access Token Phishing by Counterfeit Resource Server 26 4.8.2. Compromised Resource Server . . . . . . . . . . . . . 31 4.9. Open Redirection . . . . . . . . . . . . . . . . . . . . 31 4.9.1. Client as Open Redirector . . . . . . . . . . . . . . 32 4.9.2. Authorization Server as Open Redirector . . . . . . . 32 4.10. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 32 4.11. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 33 4.12. Refresh Token Protection . . . . . . . . . . . . . . . . 34 4.12.1. Discussion . . . . . . . . . . . . . . . . . . . . . 34 4.12.2. Recommendations . . . . . . . . . . . . . . . . . . 35 4.13. Client Impersonating Resource Owner . . . . . . . . . . . 36 4.13.1. Countermeasures . . . . . . . . . . . . . . . . . . 36 4.14. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 36 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . 39 Appendix A. Document History . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
  • 16. 16 • 認可サーバーによる不適切なリダイレクトの防止 • クライアントが「オープンリダイレクター」になることの 防止 • CSRF対策(PKCE or nonce, もしくは state) • “Mix-up Attack” 対策 • 認可サーバーにおけるユーザークレデンシャルの想定外の 漏洩防止 draft-ietf-oauth-security-topics-14/ 2. Recommendations 2.1. リダイレクトベースのフローの保護
  • 17. Resource Server Native Appsにおける戻し先の乗っ取り カスタムURLスキームの上書きにより正当なAppではなく攻撃者Appに認可コードが渡る 被害者のスマートフォン 被害者 OS / 標準 ブラウザ 正当なApp Authorization Server 攻撃者の App カスタムURLスキームを上書き 17 認可レスポンス 認可コード 認可レスポンス HTTP/1.1 302 Found Location: <AppのカスタムURLスキーム> ?code=<被害者にひもづく認可コード> &state=xyz 被害者の 認可コードを 入手 攻撃者の Appに処理を 引き継ぎ 連携開始 認可リクエスト GET /authorize ?response_type=code &client_id=s6BhdRkqt3 &scope=message.readonly &redirect_uri=<AppのカスタムURLスキーム> HTTP/1.1 Host: server.example.com 処理開始を指示 認可リクエスト ユーザー認証・ アクセス承認
  • 18. Resource Server RFC 7636: Proof Key for Code Exchange by OAuth Public Clients (PKCE) https://datatracker.ietf.org/doc/rfc7636/ 18 被害者のスマートフォン 被害者 OS / 標準 ブラウザ 正当なApp Authorization Server 攻撃者の App カスタムURLスキームを上書き 認可レスポンス 認可コード 認可レスポンス HTTP/1.1 302 Found Location: <AppのカスタムURLスキーム> ?code=<被害者にひもづく認可コード> &state=xyz 被害者の 認可コードを 入手 攻撃者の Appに処理を 引き継ぎ トークン リクエスト 認可コード code_verifier が無いため トークンを取 得できない 認可リクエスト 連携開始 認可リクエスト GET /authorize ?response_type=code &client_id=s6BhdRkqt3 &scope=message.readonly &redirect_uri=<AppのカスタムURLスキーム> &code_challenge=<code_verifierから code_challenge_methodに従って生成した値> &code_challenge_method=S256 HTTP/1.1 Host: server.example.com code_challenge 受け取りcode_challenge 処理開始を指示 ユーザー認証・ アクセス承認
  • 19. エンドユーザー サービスサイト 「OAuth認証」サーバー 19 1. 「OAuth認証でログイン」をクリック 2. 「OAuth認証サーバー」にリダイレクト 3. 「ログインしてください」 4. ID/パスワードを送信 5. サービスサイトにリダイレクト 6. 認可コードを送信しアクセストークンを取得 7. アクセストークンを用いてユーザー情報APIにア クセスし、ユーザー識別子を取得 8. 取得したユーザー識別子をもとにユーザーを特 定してログイン完了 CSRF +「OAuth認証」 アクセストークンを用いてユーザー識別子を取得 Resource Owner User Agent Client Authorization Server Resource Server 1 2 3 4 5 6 7 8 認可コード 認可コード トークン トークン ユーザー識別子
  • 20. エンドユーザー サービスサイト 「OAuth認証」サーバー CSRF +「OAuth認証」 攻撃者にひもづく認可コードを生成 攻撃者 攻撃者の Webブラウザ Client Authorization Server Resource Server 認可レスポンス 認可レスポンス HTTP/1.1 302 Found Location: https://client.example.com/cb ?code=<攻撃者にひもづく認可コード> 認可コード リダイレクトを 中断して 認可コードを 取得 認可リクエスト GET /authorize ?response_type=code &client_id=s6BhdRkqt3 &scope=message.readonly &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com 攻撃者自身としてユーザー認証 & 同意確認 「IDひもづけ開始」 20 処理開始を指示 認可リクエスト ユーザー認証・ アクセス承認
  • 21. エンドユーザー サービスサイト 「OAuth認証」サーバー CSRF +「OAuth認証」 被害者が「攻撃者にひもづく認可コード」を送信 被害者 被害者の Webブラウザ Client Authorization Server Resource Server 認可レスポンス 認可コード 被害者に 認可レスポンスを 送信させる トークン リクエスト トークン レスポンス 認可コード トークン トークン 認可レスポンス(CSRF) GET /cb ?code= <攻撃者にひもづく認可コード> HTTP/1.1 Host: server.example.com 被害者はクライアントにログイン済 被害者のログイン 情報に攻撃者の ID情報がひもづく ID情報 21
  • 22. エンドユーザー サービスサイト 「OAuth認証」サーバー CSRF +「OAuth認証」 攻撃者が「被害者としてログイン」できる 攻撃者 攻撃者の Webブラウザ Client Authorization Server Resource Server 認可レスポンス HTTP/1.1 302 Found Location: https://client.example.com/cb ?code=<攻撃者にひもづく認可コード> 認可リクエスト 攻撃者自身としてユーザー認証 & 同意確認 「OAuth認証開始」 認可レスポンス 認可コード トークン リクエスト トークン レスポンス 認可コード トークン トークン ID情報 「攻撃者のID情報」をもとに 被害者としてのログインセッションを生成 攻撃者のID情報を返却攻撃者が被害者 のアカウントを 乗っ取る 22 処理開始を指示 認可リクエスト ユーザー認証・ アクセス承認
  • 23. エンドユーザー サービスサイト 「OAuth認証」サーバー stateパラメーターによるCSRF対策 「認可リクエストの送信元」と「認可コードの送信元」が同一であるかをクライアントが確認 Resource Owner User Agent Client Authorization Server Resource Server 認可レスポンス state + 認可コード 認可レスポンス HTTP/1.1 302 Found Location: https://client.example.com/cb ?code=<エンドユーザーにひもづく認可コード> &state=3af23asl0989gnv 認可リクエスト認可リクエスト GET /authorize ?response_type=code &client_id=s6BhdRkqt3 &scope=message.readonly &state=3af23asl0989gnv &redirect_uri= https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com state stateの値が セッションに ひもづくか チェック ユーザーのセッションに ひもづく値をセット 23 処理開始を指示 ユーザー認証・ アクセス承認
  • 24. 認可リクエスト トークン リクエスト 認可レスポンス 24 エンドユーザー サービスサイト 「OAuth認証」サーバー PKCEによるCSRF対策 「認可リクエストの送信元」と「認可コードの送信元」が同一であるかを認可サーバーが確認 Resource Owner User Agent Client Authorization Server Resource Server 認可コード トークンリクエスト POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=<認可コード> &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &code_verifier=<最初に生成したcode_verifierの値> 認可リクエスト GET /authorize ?response_type=code &client_id=s6BhdRkqt3 &scope=message.readonly &code_challenge=<code_verifierからcode_challenge_methodに従って生 成した値> &code_challenge_method=S256 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com code_challenge ユーザーのセッション からcode_verifierを取得 し、その値を送信 ユーザーのセッションにひもづく値(code_verifier) を生成し、そのハッシュ値をセット 認可コード + code_verifier code_challengeを用いて 認可コードとcode_verifier とのひもづけを確認 認可コード発行時の code_challenge を記録 処理開始を指示 ユーザー認証・ アクセス承認
  • 26. 認可リクエスト 認可レスポンス トークン リクエスト トークンリクエスト 認可コード差し替え攻撃対策としてのPKCE 認可コードの不正利用によるアクセストークン窃取を防止 攻撃者 攻撃者の Webブラウザ Client Authorization Server Resource Server 認可コード 認可コード 認可コード リダイレクトを 中断して 認可コードを 差し替え 認可リクエスト GET /authorize ?response_type=code &client_id=s6BhdRkqt3 &scope=message.readonly &state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &code_challenge=<code_verifierからcode_challenge_methodに従って生成した値> &code_challenge_method=S256 HTTP/1.1 Host: server.example.com 認可レスポンス HTTP/1.1 302 Found Location: https://client.example.com/cb?code=<攻撃者にひもづく認可コード> &state=xyz 認可レスポンス(差し替え後) GET /cb ?code=<被害者にひもづく認可コード>&state=xyz HTTP/1.1 Host: server.example.com POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=<被害者にひもづく認可コード> &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &code_verifier=<最初に生成したcode_verifierの値> 差し替えられた認可コードは code_verifierにひもづかない → このトークンリクエストは不正 認可コード 発行時の code_challenge を記録 code_challenge 受け取り code_challenge code_verifier 26 処理開始を指示 ユーザー認証・ アクセス承認 code_verifier / code_challenge 生成 code_verifier 取出し code_verifier チェック
  • 28. 28 • アクセストークンの受け手(オーディエンス)となるリソースサー バーの限定と、リソースサーバーにおけるアクセストークンのオー ディエンスのチェック – クライアントおよび認可サーバーにおける、“scope” パラメーターや “resource” [I-D.ietf-oauth-resource-indicators] パラメーターの指定 • 加えてアクセストークンを「特定のリソース」や「特定のアクショ ン」に限定 – クライアントおよび認可サーバーにおける、“scope” パラメーターや “authorization_details” [I-D.ietf-oauth-rar] パラメーターの指定 draft-ietf-oauth-security-topics-14/ 2. Recommendations 2.3. アクセストークンの権限の制限
  • 29. 29 Resource Indicators for OAuth 2.0 https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ • 認可リクエストにてresourceパ ラメーターを用いて対象リソー ス(絶対URI)を指定 – […]&resource=https%3A%2F%2F cal.example.com%2F&[…] • さらにトークンリクエストでも resourceを指定し、効力を限定 したトークンを取得可能 Resource Owner User Agent Client Authorization Server Resource Server 処理開始を指示 「リソース」を 含む認可リクエスト 認可レスポンス 「リソース」を 含むトークン リクエスト トークン レスポンス API リクエスト API レスポンス (完了) ユーザー認証・ アクセス承認 イントロス ペクション リクエスト 「リソース」 を含む イントロ スペクション レスポンス
  • 30. 30 • リソースオーナーパスワードクレデンシャルズグラント は利用禁止 draft-ietf-oauth-security-topics-14/ 2. Recommendations 2.4. リソースオーナーパスワードクレデンシャルズグラント
  • 31. 31 • 認可サーバーにおけるクライアント認証の実施を推奨 • mTLS [I-D.draft-ietf-oauth-mtls] もしくは private_key_jwt [OIDC] のような非対称(公開鍵ベース)の方式を推奨 draft-ietf-oauth-security-topics-14/ 2. Recommendations 2.5. クライアント認証
  • 32. Resource Owner User Agent Client Authorization Server Resource Server Client’s X.509 Cert TLS相互認証 32 • クライアントから提示されたX.509証明書の「サブジェクト識別名(DN)」を登録値と照合 OAuth 2.0 Mutual-TLS ClientAuthentication and Certificate-Bound Access Tokens (MTLS) https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ トークンリクエスト • TLS相互認証を行ってクライアントのX.509証明書を取得し、 その証明書のサブジェクトDNをもとにクライアントを認証 • リクエスト内のclient_idの値からクライアントを識別 • そのクライアント情報として事前登録されている「証明書の サブジェクトDN」の値と照合し認証 トークンレスポンス • 証明書に結びつけた(バインドした)アクセストークンを返却 APIリクエスト • TLS相互認証を行いクライアントのX.509証明書を取得 • 証明書とアクセストークンの結びつき(バインド)を確認 処理開始を指示 認可リクエスト 認可レスポンス トークン リクエスト API リクエスト ユーザー認証・ アクセス承認 client_id トークン レスポンス Subject DNを 事前登録
  • 33. 33 • 公開鍵暗号により署名された情報(クレームセット)をもとに認証 OIDC Core 1.0 / 9. Client Authentication / private_key_jwt https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication Resource Owner User Agent Client Authorization Server Resource Server クレームセット { "iss": "55f9f559-2496-49d4-b6c3-351a586b7484”, "sub": "55f9f559-2496-49d4-b6c3-351a586b7484", "aud": "https://idp-p.example.com/token", "iat": 1418698788, "exp": 1418698848, "jti": "1418698788/107c4da5194df463e52b56865c5af34e5595" } トークンリクエスト POST /token HTTP/1.1 Content-Type: application/x-www-form-urlencoded Host: idp-p.example.com grant_type=authorization_code &code=sedaFh &scope=openid+email &client_id=55f9f559-2496-49d4-b6c3-351a586b7484 &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient- assertion-type%3Ajwt-bearer& client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9. ew0KICAg[...omitted for brevity...]. t-_gX8JQ[...omitted for brevity...] Signed JWT生成 処理開始を指示 認可リクエスト 認可レスポンス トークン リクエスト API リクエスト ユーザー認証・ アクセス承認 トークン レスポンス Signed JWT
  • 34. 34 • 認可サーバーおよびリソースサーバーにおいて「送信者 限定アクセストークン」を用いること – そのしくみとして Mutual TLS for OAuth 2.0 [RFC8705] を推奨 • リフレッシュトークンは送信者限定にすること、もしく はローテーションすることを必須 • エンドツーエンドのTLSを推奨 draft-ietf-oauth-security-topics-14/ 2. Recommendations 2.2. トークンリプレイの防止
  • 35. Resource Owner User Agent Client Authorization Server Resource Server 35 • トークンリクエスト時のクライアント証明書に、発行するアクセストークンをバインド OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (MTLS) https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ Client’s X.509 Cert TLS相互認証 トークンリクエスト • TLS相互認証を行ってクライアントのX.509証明書を取得し、 その証明書のサブジェクトDNをもとにクライアントを認証 • リクエスト内のclient_idの値からクライアントを識別 • そのクライアント情報として事前登録されている「証明書の サブジェクトDN」の値と照合し認証 トークンレスポンス • 証明書に結びつけた(バインドした)アクセストークンを返却 AT, RT Client’s X.509 Cert TLS相互認証 APIリクエスト • TLS相互認証を行いクライアントのX.509証明書を取得 • 証明書とアクセストークンの結びつき(バインド)を確認 • トークンに含まれる or イントロスペクションの結果と して得られる、証明書の「サムプリント」を利用 AT Client’s X.509 Cert TLS相互認証 RT + client_id 処理開始を指示 認可リクエスト 認可レスポンス トークン リクエスト ユーザー認証・ アクセス承認 client_id code code + client_id
  • 36. FINANCIAL-GRADE API (FAPI) Request Object / Hybrid Flow / JARM
  • 37. 37 • 金融 API 向けの OAuth 2.0 適用 プラクティス • 2016年にOpenID Foundation傘下に 設置されたFAPI WGにて策定中 • 英国Open Bankingや豪州CDRなど が既に採用 Financial-grade API (FAPI) Source: https://openid.net/w g/fapi/
  • 38. FAPIセキュリティ・プロファイル • Part 1 (Read Only) – OAuth 2.0 適用のプラクティス – OAuth 2.0 拡張仕様 – OIDC によるユーザー識別子の授受 • Part 2 (Read & Write): OIDC の積極 的な活用 + 新たな拡張仕様 – Request Object, Hybrid Flow, MTLS, OAUTB – JARM 38 OIDC拡張仕様 OIDCプラクティス OAuth2拡張仕様 OAuth2プラクティス Part1(ReadOnly) Part2(Read&Write)
  • 39. • 認可リクエスト / レスポンスの送信者 詐称・改ざん防止 – Request Objectの利用 – Hybrid FlowもしくはJARMの利用 • 認可コードの漏洩・盗用防止 – redirect_uriの厳密な管理 • クライアントのなりすまし防止 – Mutual TLSもしくはJWTによる クライアント認証 • トークンの漏洩・盗用防止 – OAUTB(トークン・バインディング) もしくはMTLS(双方向TLS接続への バインド)の利用 FAPIにおける “OAuth Dance” の改善・改良 Resource Owner User Agent Client Authorization Server Resource Server (スタート) (OAuth) 認可リクエスト (OAuth) 認可レスポンス (OAuth) トークン リクエスト (OAuth) トークン レスポンス (OAuth) API リクエスト (OAuth) API レスポンス (完了) ユーザー認証・ アクセス承認 認可 リクエスト 認可 コード 認可 コード アクセス トークン アクセス トークン APIレスポンス 39
  • 40. リクエストオブジェクト OIDC認証リクエストへの署名や暗号化 40 Resource Owner User Agent Client Authorization Server Resource Server OIDC認証リクエスト • 値渡し • 参照渡し リクエストオブジェクトのクレーム { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400, "claims": { "userinfo": { … "email": {"essential": true},…}, "id_token": { "gender": null, … "acr": {"values": ["urn:mace:incommon:iap:silver"]} } } } GET /authorize?request=eyJhbGciOiJSUzI1NiIsImtpZCI6Imsy YmRjIn0.ew0KICJpc3MiOiAiczZCaGRS… GET /authorize? request_uri=%3A%2F%2Fclient.example.org%2Frequest.jwt… リクエストオブジェクト生成 (スタート) 認可リクエスト 認可レスポンス トークン リクエスト トークン レスポンス API リクエスト ユーザー認証・ アクセス承認
  • 41. Resource Owner User Agent Client Authorization Server Resource Server フラグメント 取得 フラグメント 送信 state, code, id_token Hybrid Flow 認可コードとIDトークンを認可EPから返却 認可リクエスト GET /authorize ?response_type=code%20id_token […] &state=af0ifjsldkj Detached Signatureによる検証 トークンリクエスト トークンレスポンス code AT, RT, ID Token 認可レスポンス HTTP/1.1 302 Found Location: https://api.mytpp.com/cb# code=SplxlOBeZQQYbYS6WxSbIA &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso &state=af0ifjsldkj Detached Signature生成(スタート) 認可リクエスト 認可レスポンス ユーザー認証・ アクセス承認 (フラグメント)state, code, id_token# 41
  • 42. 認可リクエスト 42 Detached Signature 検証用の値に署名して本文と別に返却 Resource Owner User Agent Client Authorization Server Resource Server 認可レスポンス HTTP/1.1 302 Found Location: https://api.mytpp.com/cb# code=SplxlOBeZQQYbYS6WxSbIA &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso &state=af0ifjsldkj IDトークン(SignedJWT)を検証した上で、c_hash, s_hashを抽出し、それぞれをもとにcode,stateを検証 { … "s_hash": "76sa5dd", "c_hash": "asd097d" … } code=SplxlOBeZQQYbYS6WxSbIA state=af0ifjsldkj state クレームセット { … "s_hash": "76sa5dd", "c_hash": "asd097d" … } IDトークン(Signed JWT)生成 state, code の値が確定 s_hash, c_hash生成 IDトークン(Signed JWT)として 検証できた(改ざんされていない)値 クエリパラメーターとして 受け取った値 (スタート) 認可レスポンス ユーザー認証・ アクセス承認 (フラグメント)state, code, id_token (s_hash, c_hash, 署名)# トークン リクエスト トークン レスポンス
  • 43. JARM JWT SecuredAuthorizationResponseMode for OAuth 2.0 Resource Owner User Agent Client Authorization Server Resource Server code AT, RT, ID Token 認可リクエスト GET /authorize? response_type=code&response_mode=jwt&[…] 認可レスポンス HTTP/1.1 302 Found Location: https://client.example.com/cb? response=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9. eyJpc3MiOiJodHRwczovL2FjY291bnRzLmV4YW1wbGUuY29tIiwiYXVkI joiczZCaGRSa3F0MyIsImV4cCI6MTMxMTI4MTk3MCwiY29kZSI6IlB5eU ZhdXgybzdRMFlmWEJVMzJqaHcuNUZYU1FwdnI4YWt2OUNlUkRTZDBRQSI sInN0YXRlIjoiUzhOSjd1cWs1Zlk0RWpOdlBfR19GdHlKdTZwVXN2SDlq c1luaTlkTUFKdyJ9. HkdJ_TYgwBBj10C-aWuNUiA062Amq2b0_oyuc5P0aMTQphAqC2o9WbGSk pfuHVBowlb-zJ15tBvXDIABL_t83q6ajvjtq_pqsByiRK2dLVdUwKhW3P _9wjvI0K20gdoTNbNlP9Z41mhart4BqraIoI8e-L_EfAHfhCG_DDDv7Yg トークンリクエスト トークンレスポンス Signed JWT検証 クレームセット { "iss": "https://accounts.example.com", "aud": "s6BhdRkqt3", "exp": 1311281970, "code": "PyyFaux2o7Q0YfXBU32jhw.5FXSQpvr8akv9CeRDSd0QA", "state": "S8NJ7uqk5fY4EjNvP_G_FtyJu6pUsvH9jsYni9dMAJw" } response(SignedJWT)生成 (スタート) 認可リクエスト 認可レスポンス ユーザー認証・ アクセス承認 response (code, state, 署名) 43
  • 44. 44 • Removed – OAuth 2.0 Token Binding – code id_token and code id_token token – LoA3 – Public client support • Separated – Pushed Request Object https://bitbucket.org/openid/fapi/src/master/Financial_API_Pushed_Request_Object.md • Promoted – JARM as an alternative to Hybrid Flow • Added – 60-minute lifetime for exp in Request Object FAPIセキュリティプロファイルの現状 (実装者向けドラフト第2版以降)
  • 46. 46 • リソースオーナー(ユーザー)がク ライアントに移譲する権限の粒度 – APIによってアクセス可能な データの種類・範囲 (e.g. 口座情報、取引履歴) – APIによって実行可能な機能の 範囲(e.g. 参照、決済、送金) • 「ある特定の取引」「同意した範囲 でのデータ取得」のような粒度を表 現するにはどうするか? OAuth における「スコープ」 (scope) Resource Owner User Agent Client Authorization Server Resource Server (スタート) (OAuth) 認可リクエスト (OAuth) 認可レスポンス (OAuth) トークン リクエスト (OAuth) トークン レスポンス (OAuth) API リクエスト (OAuth) API レスポンス (完了) ユーザー認証・ アクセス承認 GET /authorize? response_type=code& client_id=287560982& redirect_uri=https:// client.example.org/cb& scope=payment&…
  • 47. 「インテント」の導入 47 Resource Owner User Agent Client Authorization Server Resource Server 処理開始を指示 「インテントID」を含む 認可リクエスト 認可レスポンス トークン リクエスト 「インテント」に のみ行使可能な トークンを返却 API リクエスト API レスポンス (完了) 取引内容への 承認を確認 「インテント」登録 「インテントID」返却 Resource Owner User Agent Client Authorization Server Resource Server (スタート) (OAuth) 認可リクエスト (OAuth) 認可レスポンス (OAuth) トークン リクエスト (OAuth) トークン レスポンス (OAuth) API リクエスト (OAuth) API レスポンス (完了) ユーザー認証・ アクセス承認
  • 48. 48 • サードパーティが銀行のAPIに、 口座情報取得や決済指図伝達な どの「インテント」を事前登録 • 登録された内容を利用者が 銀行のWebサイトや アプリにて確認・承認 • 承認後、サードパーティが「イ ンテント」の内容の実行を銀行 のAPIにリクエスト インテントによる「取引単位」のアクセス認可 Resource Owner User Agent Client Authorization Server Resource Server 処理開始を指示 「インテントID」を含む 認可リクエスト 認可レスポンス トークン リクエスト 「インテント」に のみ行使可能な トークンを返却 API リクエスト API レスポンス (完了) 取引内容への 承認を確認 「インテント」登録 「インテントID」返却
  • 49. 49 • FAPI WG が “Lodging Intent Pattern” に注目 https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-intent – 事前にクライアントが認可サーバーに “intent” を 登録し、返却されたその intent の「ハンドル」を認可リ クエストに付加 – UK Open Banking では essential claim、Berlin Group NextGenPSD2 では dynamic scope にて表現 • OAuth 2.0の認可リクエストを拡張する仕様として 現在IETF OAuth WGにて議論が進行中 – OAuth 2.0 Rich Authorization Requests – OAuth 2.0 Pushed Authorization Requests 「インテント」の標準化 Source: https://www.slideshare.net/tkudo/osw2019/7 Source: https://medium.com/oauth-2/rich-oauth-2-0- authorization-requests-87870e263ecb
  • 50. 50 • PARエンドポイント(新規) – クライアントが認可サーバーに「複雑な認可 リクエスト」を登録し、認可サーバーが「リ クエストURI」を返却 – 認可サーバーがクライアントを認証可能 • 認可エンドポイント(拡張) – クライアントが認可サーバーに、リクエスト URIを含む「単純な認可リクエスト」を送信 • https://as.example.com/authorize? request_uri=<リクエストURI>&… – ユーザーエージェントによって中継される情 報を最小化 OAuth 2.0 Pushed Authorization Requests (PAR) https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ Resource Owner User Agent Client Authorization Server Resource Server 処理開始を指示 「リクエストURI」を 含む認可リクエスト 認可レスポンス トークン リクエスト トークン レスポンス API リクエスト API レスポンス (完了) ユーザー認証・ アクセス承認 「複雑な認可 リクエスト」登録 「リクエスト URI」返却 PAR EP Authz EP
  • 51. 51 • “authorization_details” パラメーター (新規) – クライアントが認可サーバーに「詳細な認可 リクエスト」を送信 • https://as.example.com/authorize? response_type=code& client_id=6493509078&scope=email& authorization_details=[{“type”:“type0”, "locations":["loc0","loc1"],"hello":"world"}] – 認可サーバーはこの内容を、認可決定に用い ると同時に、トークンレスポンスやイントロ スペクションレスポンスとして、それぞれク ライアントとリソースサーバーに提供 OAuth 2.0 Rich Authorization Requests (RAR) https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ Resource Owner User Agent Client Authorization Server Resource Server 処理開始を指示 「認可詳細」を 含む認可リクエスト 認可レスポンス トークン リクエスト 「認可詳細」を 含むトークン レスポンス API リクエスト API レスポンス (完了) ユーザー認証・ アクセス承認 イントロス ペクション リクエスト 認可詳細」 を含むイン トロスペク ションレス ポンス
  • 53. UTILIZING END-USER DEVICES Device Authorization Grant / CIBA 53
  • 54. 54 “Redirect Flow” Source: マネーフォワード, Google ユーザー ユーザー・エージェント 1. 「外部サイトで ログイン」 2. リダイレクト 4. リダイレクト 3. 認証
  • 55. RFC 8628: OAuth 2.0 Device Authorization Grant https://datatracker.ietf.org/doc/rfc8628/ ユーザー クライアント (デバイス) 認可・APIサーバー DA EP API(6) (6) トークン を使ってAPI アクセス 1 1. デバイス認可 リクエスト 2 2. デバイス認可 レスポンス dev ice_code, user_code etc. デバイス認可 エンドポイント 4’ 4’. ユーザー認証 & user_code入力 55 3 3. user_code 表示 Token EP Web ブラウザ 5 5. トークン レスポンス 00. スタート 4 dev ice_code etc. 4. トークン リクエスト (ポーリング)
  • 58. “Decoupled Flow” • 「アレクサ、お店に 5,000円払って」 → 手元のケータイに 決済サービスAppから 通知 58Source: https://www.europeanpay mentscouncil.eu/document-library /minutes-and-agendas/authentication-sca-guidance-key -topic-clarif ication-api
  • 59. “Decoupled Flow” • TVショッピングとかで、 – 視聴者が電話で購入希望を伝える – オペレーターに「ではお客さまのスマート フォンに注文内容をお送りします。ご確認 をお願いします」と言われる – 視聴者は手元のスマートフォンにきた、決 済サービスAppからの通知をみて承認する – 店舗への決済が行われる 59
  • 60. “Decoupled Flow” • 仮に Ponta の ID と決済できるとこのIDが 紐づいてたら – コンビニ店員「Pontaカードカモン」 – 客「はい」 – 店員「XXX円です」 – 客「CIBAPay(ダッサ)」 – 店員「はい(ポチ)」 – 客のスマホ「(XXX円をローソンに支払います。 よろしいですか?)」 – 客「おk」 – 店員「支払いおわた。レシートどぞ」 ぐらいは出来そうです Source: https://ritou.hatenablog.com/entry /2018/12/29/224452 60
  • 61. 61 • OpenID Foundation 傘下のWGにて策定中の新たなオープン仕様 – 「サービスを利用するデバイス」と「認証を行うデバイス」を分離 • より良い顧客体験 (CX) の提供とセキュリティ強化に有用 OpenID Connect Client Initiated Backchannel Authentication (CIBA) Flow - Core 1.0 https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html
  • 62. CIBA のフロー ユーザー Consumption Device (CD) Authentication Device (AD) クライアント (リライング・ パーティ) 認可・APIサーバー (アイデンティティ・ プロバイダー) 0 0. ユーザーの 識別子を把握 login_hint_token id_token_hint login_hint BA EP API (*) Access Token (**) Refresh Token (4) (4) トークン を使ってAPI アクセス (4) (4) 認証結果を 利用して処理を 実行 1 1. 認証 リクエスト User Identif ier 2 2. 受付応答 AuthN Req ID 3 3. 認証結果と トークンを返却 (Poll / Ping / Push) ID Token / AT* / (RT**) バックチャネル認証 エンドポイント 2’ 2’. ユーザー 認証 62
  • 64. Identity Provider 64 • “verified_claims” (新規) – 「検証済クレーム」 – OIDCのクレームとして定義 • RPは「取得したい検証済ク レームとその内容」を、認証 リクエストのclaimsパラメー ターを用いて指定 • IdPはIDトークンやUserInfo レスポンスとして、検証済ク レームを返却 OpenID Connect for Identity Assurance 1.0 https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html Resource Owner User Agent Relying Party Authorization Server UserInfo Endpoint 処理開始を指示 取得したい「検証済クレーム」を 含む認証リクエスト 認可レスポンス トークン リクエスト 「検証済 クレーム」を 含むトークン レスポンス UserInfo リクエスト (完了) ユーザー認証・ アクセス承認 「検証済 クレーム」を 含むUserInfo レスポンス
  • 66. 66 • 2010年代前半に確立したOAuth 2.0 / OpenID Connectは2020 年の環境においても十分通用する • 一方で現在も、活用領域の拡大・高度化につれて、関連仕様 の策定や適用方法の更新が続いている • 2015年以降の仕様・プラクティスは、新たなサービスや今後 のアーキテクチャを考える上での参考として役立つ(かも) まとめ
  • 68. プロトコル処理とトークン管理をAuthleteが代行 68 Resource Owner User Agent Client Authorization Server Resource Server (スタート) (OAuth) 認可リクエスト (OAuth) 認可レスポンス (OAuth) トークン リクエスト (OAuth) トークン レスポンス (OAuth) API リクエスト (OAuth) API レスポンス ユーザー認証・ アクセス承認 Authlete API 認可リクエスト 処理 認可コード生成 トークンリクエスト 処理 アクセス トークン 検証 /auth/authorizationPOST /auth/authorization/issuePOST /auth/tokenPOST /auth/introspectionPOST
  • 69. 69 AuthleteにおけるFAPI Part 2サポートの例 Resource Owner User Agent Client Authorization Server Resource Server (スタート) (OAuth) 認可リクエスト (OAuth) 認可レスポンス (OAuth) トークン リクエスト (OAuth) トークン レスポンス (OAuth) API リクエスト (OAuth) API レスポンス ユーザー認証・ アクセス承認 Authlete API 認可リクエスト 処理 認可コード生成 トークンリクエスト 処理 アクセス トークン 検証 /auth/authorizationPOST /auth/authorization/issuePOST /auth/tokenPOST /auth/introspectionPOST • リクエストオブジェクト使用の必須化 • ハイブリッドフロー or JARM要求の必須化 • 認証コンテキストリファレンス(acr)クレームの必須化 • ハイブリッドフロー or JARMでのレスポンス生成 • クライアント証明書送付の必須化 • クライアント証明書送付の必須化
  • 70. 70 • 弊社川崎 @darutk の記事 – https://qiita.com/TakahikoKawasaki • Authlete API チュートリアル – https://www.authlete.com/ja/developers/tutorial/ • プレゼンテーション資料 – https://www.slideshare.net/tkudo – https://speakerdeck.com/takahikokawasaki/ リソース