OpenID Connect 'response_type' and flows



OpenID Connect 全フロー解説 - Qiita という労作がある。しかし、使ってはならないフローまで解説してあるので、不味いことになっている。

OpenID Connectユースケース、OAuth 2.0の違い・共通点まとめ - Build Insider で、ユースケースごとの認証フロー, single sign on (SSO), 再認証・強制認証のさせ方、パラメータの与え方まで解説。とても参考になる。

Implicitフローを使う局面なら Hybrid フロー、と勧めているが, OPが Hybrid フローをサポートしていないこともあるので、組み合わせに配慮が必要。

response_type の組み合わせ一覧

Authorization Request (認証要求) に含まれる response_type で、フローが決定される。組み合わせは次のいずれか;

"response_type" value Flow IdP Supported
code Authorization Code Flow Google, AzureAD, Yahoo!, Apple, LINE, PayPal
× token response_type=token は, OpenID Connect では使ってはならない (MUST NOT). IDトークンが得られないため。 Google, Yahoo!
id_token Implicit Flow. アクセストークンが得られない。仕様上, IDトークンにユーザ情報も含めることになっているが、Yahoo! JAPAN はサポートしていない。Azure AD などサポートしている IdP では, UserInfo Endpoint への問い合わせを不要にできる。

また別のケースとして, Self-Issued OpenID Provider の場合。

Google, AzureAD, Yahoo! (不正)
id_token token Implicit Flow. IDトークンとアクセストークンの両方を得る. Implicit Flow といえば通常はこちら。 Google, AzureAD, Yahoo!
code id_token Hybrid Flow. FAPI 1.0 Part 2 はこれを指示。 Google, AzureAD, Yahoo!, PayPal
code token Hybrid Flow. 例えば解説記事 ハイブリッドフローによる 2 つのアクセストークンの発行 Google, Yahoo!
code id_token token Hybrid Flow. 廃れた。 Google, Yahoo!
none

scopeパラメタ

response_type が 'none' 以外の場合、常に scope パラメタに 'openid' スコープ値を含めなければならない (MUST). response_typecode または code token のときに必須なのは、仕様から明らか。それ以外の場合も、実装はエラーになる。

See Basics: OAuth and OpenID Connect #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018

使い分け

Authorization Code Flow (Basic client)

Webアプリでは, response_type=code (Authorization Code Flow) でOK. Client secret が安全に保持できること。

Implicit Flow

[2024-02 追記] OpenID Connect 認証仕様の基礎である OAuth 2.0 認可 (認証にあらず) フレームワークについて、改定作業が行われている. The OAuth 2.1 Authorization Framework Internet-Draft. Implicit Flow は単に削除される見込み。response_type = id_token token は廃止。

今後は Authorization Code Flow with PKCE を使え。[/2024-02 ここまで]

ネイティブ (デスクトップ) アプリは, バイナリ内に秘密情報を持たせることができないので, Implicit Flow または Hybrid Flow. サーバアプリであっても, client secret を維持する必要がなくなるので、メリットある。

IDトークンについて, OPが付加したデジタル署名の検証が必要になる。アクセストークンについても、適切に検証が必要。

右は 2016年のガイドラインで古い。依拠できない。『OpenID Connect と SCIM のエンタープライズ実装ガイドライン』 1.0 では, response_typeid_token または id_token token でなければならない (MUST). Implicit Flow を仮定。

OpenID Connect Implicit Client Implementer's Guide 1.0 によれば, 通常は id_token token でなければならない。OpenID Connect Core 1.0 仕様では id_token でもいいことになっているが、その記述はない。

Financial-grade API

業務領域による考慮もある。

金融などセキュリティが厳しい領域のために, Financial-grade API (FAPI) が定められた。更新系 (read and write) の操作 (operation) を行う場合, Financial-grade API Security Profile 1.0 - Part 2: Advanced による。

response_typecode id_token または code id_token token でなければならない (MUST, Hybrid Flow). もしくは, response_type=code かつ response_mode=jwt (JARM).

必要があれば再認証、でもいいか? Financial API 実装の技術課題 - Qiita