「2回認可コードフローやる」をもうちょっと考える
はじめに
以前投稿した記事の続編です。
プラットフォームとして OIDC を開発者に楽をしてもらおう！なんて意気込みましたが設計を白紙としたため記事として供養しました。
設計はしたものの、まだモヤモヤしているポイントがありました。
もやりポイント
設計はしたものの、もやもやしているポイントがあります。
２度目の認可コードフローです。
サーバー間認証でお茶を濁した感じです ...
許可されていないサーバーからのアクセスは防げますが、同一のセッションであることを担保できていない気がします。
（PKCE みたいな仕組みを入れれば同一セッションであることを担保できるのかな ... ）
気になっていたのは最後にプラットフォームとしてのアクセストークン（リフレッシュトークン）を払い出す処理です。
サーバー間認証でお茶を濁すような実装を考えましたが、これで本当によかったのだろうか。
もうちょっと考えて、改めてシーケンス図を書いてみました。
設計（シーケンス）
前回の記事では RP に対して OP(IdP) の指定を行うために provider というクエリパラメータを要求していましたが今回の記事ではそこは省略しています。
（PKCE みたいな仕組みを入れれば同一セッションであることを担保できるのかな ... ）
とコメントを残していましたが、シンプルに Service で state を発行しその state を連れ回して UserAgent <-> Service および UserAgent <-> Relying Party で同一セッションであることを担保するように考えてみました。
サーバー間認証でお茶を濁した感じです ...
サーバー間認証に関しては Relying Party <-> OpenID Provider 間で ClientID および ClientSecret をやり取りするのと同様に Service <-> Relying Party でも用いることにします。
4つのステップ
前回の記事と異なる点は Service 側にて state を発行し Relying Party へとリダイレクトでアクセスを促すようにした点です。
Step 1 ログイン開始
Service の API です。
Step 2 OpenID Provider へのログイン
Relying Party の API です。
Step 3 OpenID Provider の ID トークンを取得
Relying Party の API です。
Step 4 アクセス(リフレッシュ)トークンの発行
Service の API です。
Relying Party の API です。
考えてみたが ...
セッションが同一であることを担保するために state を連れ回すようにしてみましたが Service 側もほぼOIDC 認可コードフローをやることになりました。
プラットフォームとして開発者に OIDC を使いやすくしてもらうために考えてみましたが、そこまで認知負荷は軽減されていないような気がします。
軽減されるのは OP の管理でしょうか。ただ、サービス側が主導で外部サービスと SSO したいなどの決定権を持つような場合は結局使うようにするためのフォームなどを整備する必要がありそうです。
おわりに
OIDC の認知負荷を下げるというのはなかなか難しそうです。
OIDC を知らないでいい世界ではなくみんなが OIDC を知っている世界を目指したいですね。
頑張ってみなさんで理解していきましょう！
（セッションが同一であることを担保する方法って cookie 以外あるんですかね ... ???）
Discussion