😎

OIDCのImplicit FlowでClientSecretを使わずにID連携する

2022/02/14に公開

Security

ritouです。
なんか反応いっぱいあったこれですが

一番伝えたかったのは

ログインだけなら(ClientSecret)いらねーじゃん

なのでその部分を書きます。特に新しい話ではありません。

まとめ

まとめます。

OIDCで新規登録やログインさせたいだけ、かつUserInfo API叩かなくていいなら、 client_secretはいらないよ！
Implicitって言っても、OAuth 2.0 の response_type=token は使わん方がいいけど OIDC の response_type=id_token は使っていい
みんな大好きSAMLと大体一緒よ。しらんけど。

こんなところですね。

ID連携の時、リソースアクセスしてる？

OIDC Core ってのは

IDTokenによる "認証イベント" 情報、ユーザーの属性情報を受け渡し
UserInfo APIによる最新のユーザー属性情報の提供

という仕様を OAuth 2.0 の仕組みを拡張/利用する形で定義しています。

そしてここからは要件によりますが、 継続的に最新のユーザー情報を取得して利用するような要件がなければ前者の "IDToken" を利用するだけで新規登録/ログイン機能を実装可能 です。

例えばWebアプリケーションに対して GSuite 改め Google Workspace のアカウントのみ利用できるように制限する、みたいな時はAPIアクセスなんていらないでしょう。

こういう時に使えるのが response_type=id_token という認証リクエストにより実現できる、「OIDC の Implicit Flow」です。

response_type=id_token

仕様では

AuthN Request に response_type=id_token を指定
AuthN Response には IDToken が含まれる(フラグメント部分に指定される)
RP は IDToken を検証した上で新規登録なりログインをさせる
アクセストークン/リフレッシュトークンは含まれない

と言うあたりです。

CSRFやリプレイアタックなどへの対策としては state/nonce が使えますね。
Token EndpointへのリクエストがないためPKCEは使えません。

ClientSecret　の管理不要

仕様上、ClientSecretの利用用途は

Client認証
alg=HS256で署名してくるIDTokenの署名検証 <- ほとんど使われてない

あたりです。当然ながら

Client認証が行われるToken Endpointへのリクエストが存在しないフローではClientSecretの管理は不要 なわけなので、SPAだとかClientTypeだとか考える必要すらないですね。

Implicit Flow ってやばいやつじゃなかったっけ？

「単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」話は OAuth 2.0 の Implicit Flow であり、 response_type=tokenってやつです。

今回紹介したOIDCのとは別物です。OIDCの方は使って良いです。

すみません、SAMLで説明してください

出たな #SAMLai ！！！ってことで。
SAMLでもいろんなbindingがあるんですよね。

HTTP Rediret Binding
HTTP POST Binding

あたりが今回紹介した OIDC 　の Implicit Flow に当たるわけです。
なので #SAMLai がこの話を理解できないはずはない。

まとめ

(トークンを発行しない) OIDC の Implicit Grant を使えば Client Secret の管理なしでシンプルにID連携が実装できるので要件次第で使っても良いんじゃないか、と言うお話でした。

別件ですが、最近は GitHub のあれこれで IDToken を送って何かするみたいなユースケースも理解しやすくなったと思います。

OIDCは「簡単なことは簡単に」実装できるように設計されているはずなので、必要に応じてベストな設計/実装をやっていきましょう。

ではまた！

そういえば本記事をもちまして「Digital Identity技術勉強会 #iddance Advent Calendar 2021」完走です。9個も書いたお。

次回はみなさん、ちゃんと書きましょう。