各Grant Type解説 Grant Type 概要 Authorization Code Grant 認可コードによりユーザーエージェントと経由せずにクライアントにアクセストークンを送信でき データの露出リスクを低減する。 Implicit Grant JavaScriptなどのブラウザー上のクライアントに最適化されている。 認可コードのように仲介するクレデンシャルがないため「Implicit=暗黙の」と呼ばれる。 クライアントが直接アクセストークンを受信するため、リソースオーナーやユーザーエージェント 経由で他のアプリケーションに晒される可能性がある。 Resource Owner Password Credentials Grant リソースオーナーのパスワードを直接送信してアクセストークンを取得する。 リソースオーナーとクライアントの間で高い信頼があり、他のGrant Typeが利用できない場合の み使用されるべきである。 Client Credentials Grant 認可範囲がクライアントの管理下にある保護されたリソース、もしくは認可サーバーとの間で調 整済みの保護されたリソースに制限されている場合に使用される。
1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである。 このプロトコルはクライアントが認可サーバーの認証結果に基づいてエンドユーザーのアイデンティティを検証可能にする . ま た同時にエンドユーザーの必要最低限のプロフィール情報を , 相互運用可能かつ RESTful な形で取得することも可能にす る。 OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. 出典元：OpenID Connect Core 1.0 incorporating errata set 1(日本語版) (https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html) 原文：OpenID Connect Core 1.0 incorporating errata set 1 (https://openid.net/specs/openid-connect-core-1_0-errata1.html) OpenID Connect 1.0 概要 34 ID連携技術の基礎 OpenID Connect 1.0は、ID連携を実現するための標準規格 ※この資料では OIDCと記載
特徴 Authorization Code Flow Implicit Flow Hybrid Flow 全てのトークンは Authorization Endpoint から返却される no yes no 全てのトークンは Token Endpoint から返却される yes no no トークンが User Agent にわたらない yes no no Client 認証が可能である yes no yes Refresh Token を利用できる yes no yes 通信が1往復だけである no yes no ほとんどの通信がサーバ間通信である yes no varies 出典元：OpenID Connect Core 1.0 incorporating errata set 1 (https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html)
のユースケースの分類 POINT：最終的には以下のような表形式にまとめたい RS AS Client ユースケース ① A A’ B 3rd Party アプリを作るケース 例: 印刷サービスに写真へのアクセスを許可する ② A A’ A’’ 全て同一の事業者が運営するケース 例: Web アプリとモバイルアプリでアクセス可能なリソースを分ける ③ A B A’ 外部の認可サーバーを利用するケース 例: 認可サーバーの自作が面倒なので IDaaS に切り出す ④ A B C 全て別の事業者が運営するケース 例: RS は自社サービス, AS は IDaaS, Client は 3rd Party アプリ
のユースケースの分類 中間報告会では 2 ケースに絞ってご説明します RS AS Client ユースケース ① A A’ B 3rd Party アプリを作るケース 例: 印刷サービスに写真へのアクセスを許可する ② A A’ A’’ 全て同一の事業者が運営するケース 例: Web アプリとモバイルアプリでアクセス可能なリソースを分ける ③ A B A’ 外部の認可サーバーを利用するケース 例: 認可サーバーの自作が面倒なので IDaaS に切り出す ④ A B C 全て別の事業者が運営するケース 例: RS は自社サービス, AS は IDaaS, Client は 3rd Party アプリ
のユースケースの分類 POINT：ここまでの分類を表にまとめる RS AS Client ユースケース ① A A’ B 3rd Party アプリを作るケース 例: 印刷サービスに写真へのアクセスを許可する ② A A’ A’’ 全て同一の事業者が運営するケース 例: Web アプリとモバイルアプリでアクセス可能なリソースを分ける
のユースケースの分類 POINT：最終的には以下のような表形式にまとめたい RP OP ユースケース ① A B 外部の ID 基盤で SSO するケース 例: ログイン機能を自作したくないので外部 IdP を用いる ② A A’ 自社の ID 基盤を開発するケース 例: 自社 ID を統一して UX を改善したい
のユースケースの分類 POINT：ここまでの分類を表にまとめる RP OP ユースケース ① A B 外部の ID 基盤で SSO するケース 例: ログイン機能を自作したくないので外部 IdP を用いる ② A A’ 自社の ID 基盤を開発するケース 例: 自社 ID を統一して UX を改善したい
# 認証技術の基礎 - 参考文献 Digital Identity Guidelines, NIST SP 800-63-4 (Initial Public Draft), National Institute of Standards and Technology, https://doi.org/10.6028/NIST.SP.800-63-4.ipd を日本語訳した文献を参考にしています Initial Public Draftであり最終確定版ではありません 本ガイドライン群は, Digital Identity サービスを実装する連邦機関に対する技術的要件を提供するものであり , それ以外の条件下での標準仕様の開発・利用に対する制約を意図したものではない . 引用：「NIST Special Publication 800-63-4」https://openid-foundation-japan.github.io/800-63-4/sp800-63.ja.html
- 参考文献 passkeys.dev is brought to you by the W3C WebAuthn Community Adoption Group and members of the FIDO Alliance. 引用：passkeys.dev「About | passkeys.dev」https://passkeys.dev/about/. Licensed under CC BY-SA 4.0.
- パスキーとは # Passkey The high level, end-user centric term for a FIDO2/WebAuthn Discoverable Credential. Like “password”, “passkey” is a common noun intended to be used in every day conversations and experiences. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0. FIDOクレデンシャル ディスカバラブルFIDOクレデンシャル 参考元：「FAQ's - FIDO Alliance」https://fidoalliance.org/faqs
パスキーとは # Passkey From the technical side, there are two flavors of passkeys: synced and device-bound. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0. FIDOクレデンシャル ディスカバラブルFIDOクレデンシャル（パスキー） 同期パスキー デバイス固定パスキー
同期パスキー パスワード検証など不要で認証要求時に常に利用可能なディスカバラブル FIDOクレデンシャル デバイス固定パスキー 単一の認証器に紐づくデバイスから離れることがないディスカバラブル FIDOクレデンシャル # Synced passkey A FIDO2 Discoverable Credential that can reliably be used for bootstrapping sign-in, without requiring other login challenges such as passwords and OTPs. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0. # Device-bound passkey A FIDO2 Discoverable Credential that is bound to a single authenticator. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0.
同期パスキー パスワード検証など不要で認証要求時に常に利用可能なディスカバラブル FIDOクレデンシャル デバイス固定パスキー 単一の認証器に紐づくデバイスから離れることがないディスカバラブル FIDOクレデンシャル # Synced passkey A FIDO2 Discoverable Credential that can reliably be used for bootstrapping sign-in, without requiring other login challenges such as passwords and OTPs. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0. # Device-bound passkey A FIDO2 Discoverable Credential that is bound to a single authenticator. 引用：passkeys.dev「Terms | passkeys.dev」https://passkeys.dev/docs/reference/terms/. Licensed under CC BY-SA 4.0.
Grant ◦ Access Token の漏洩およびリプレイに対して脆弱なため ◦ > “The implicit grant (response type "token") and other response types causing the authorization server to issue access tokens in the authorization response are vulnerable to access token leakage and access token replay as described in Section 4.1, Section 4.2, Section 4.3, and Section 4.6.” 引用元：「OAuth 2.0 Security Best Current Practice」https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-29#name-implicit-grant ◦ OIDC の Implicit Flow (response_type=id_token) は非推奨の対象でない • Resource Owner Password Credentials Grant ◦ Client に対して安全でない方法でクレデンシャルが渡ってしまうため ◦ Client が無害であっても、攻撃対象が拡大するため ◦ > “The resource owner password credentials grant [RFC6749] MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client. Even if the client is benign, this results in an increased attack surface (credentials can leak in more places than just the authorization server) and users are trained to enter their credentials in places other than the authorization server.” 引用元：「OAuth 2.0 Security Best Current Practice」https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-29#name-resource-owner-password-cre Appendix Implicit Grant と Resource Owner Password Credentials Grant は非推奨
RS と Client が同一なら OAuth は不要、のように整理できる RS AS Client ユースケース ① A A’ B 3rd Party アプリを作るケース 例: 印刷サービスに写真へのアクセスを許可する ② A A’ A’’ 全て同一の事業者が運営するケース 例: Web アプリとモバイルアプリでアクセス可能なリソースを分ける ③ A B A’ 外部の認可サーバーを利用するケース 例: 認可サーバーの自作が面倒なので IDaaS に切り出す ④ A B C 全て別の事業者が運営するケース 例: RS は自社サービス・AS は IDaaS・Client は 3rd Party アプリ ⑤ A B A クライアントとアプリが一体であるケース サービス間連携を前提としたアクセス制御の仕組みは不要
.png){kind=small}
.png){kind=avatar}
.png){kind=avatar}
oidfj
sh_fk2
ninomiya_ii
takasyou
dak2
elmodev09
izumii19
akkiesoft
hamukazu
tanimuyk
oikon48
takasehideki
jacopen
samtorres
frankvandijk
portentint
gurzu
rabernat
jonoalderson
brettharned
akosma
bluesmoon
eileencodes
mlcsv
pedronauck
![© OpenID Foundation Japan FIDO標準[*]によりFIDOクレデンシャルの妥当性を判断するプロセス ∟ FIDO UAF [*][*1] /](https://files.speakerdeck.com/presentations/fba8ef0132a54e25b52fc50c97f278b8/slide_133.jpg){kind=link}
![© OpenID Foundation Japan FIDO標準[*]によりFIDOクレデンシャルの妥当性を判断するプロセス ∟ FIDO UAF [*][*1] /](https://files.speakerdeck.com/presentations/fba8ef0132a54e25b52fc50c97f278b8/slide_136.jpg){kind=link}
