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 |
---|---|
code | Authorization Code Flow |
response_type=token は, OpenID Connect では, 使ってはならない (MUST NOT). IDトークンが得られないため。
| |
id_token
| Implicit Flow. アクセストークンが得られない。IDトークンにユーザ識別情報が含まれる IdP を用いるため、UserInfo Endpoint への問い合わせが不要の場合に使用できる。例えば Azure AD. また別のケースとして, Self-Issued OpenID Provider の場合。 |
id_token token | Implicit Flow. IDトークンとアクセストークンの両方を得る. 通常はこちら。 |
code id_token | Hybrid Flow |
code token | Hybrid Flow |
code id_token token | Hybrid Flow |
none
|
scope
パラメタresponse_type
が 'none
' 以外の場合、常に scope
パラメタに 'openid
' スコープ値を含めなければならない (MUST). response_type
が code
または code token
のときに必須なのは、仕様から明らか。それ以外の場合も、実装はエラーになる。
Webアプリでは, response_type=code
(Authorization Code Flow) でOK. Client secret が安全に保持できること。
ネイティブ (デスクトップ) アプリは, バイナリ内に秘密情報を持たせることができないので, Implicit Flow または Hybrid Flow. サーバアプリであっても, client secret を維持する必要がなくなるので、メリットある。
IDトークンについて, OPが付加したデジタル署名の検証が必要になる。アクセストークンについても、適切に検証が必要。
『OpenID Connect と SCIM のエンタープライズ実装ガイドライン』 1.0 では, response_type
は id_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 (FAPI) が定められた。更新系 (read and write) の操作 (operation) を行う場合, Financial-grade API Security Profile 1.0 - Part 2: Advanced による。
response_type
は code id_token
または でなければならない (MUST). Hybrid Flow. もしくは, code id_token token
response_type=code
で, かつ response_mode=jwt
(JARM).
必要があれば再認証、でもいいか? Financial API 実装の技術課題 - Qiita