「ID TokenをAuthorization Headerにつけて送る」というお作法について思うところ

こんばんは、ritouです。

f:id:ritou:20200517193756p:plain

ID Tokenがやりとりされている背景

ちょっと前にこんな話がありました。

blog.ssrf.in

この id_token が JWT になっていますので、これを Authorization: Bearer $ID_TOKEN というヘッダにして oauth2-proxy で保護されているアプリケーションへ送信するだけです。

docs.aws.amazon.com

Authorization ヘッダー (または、オーソライザー作成時に指定した別のヘッダー) に ID トークンを含めます。

この「ID TokenをAuthorization Headerに指定して保護されているっぽいリソースにアクセスする行為」は一体何なのかというお話です。

ある有識者はOAuth 2.0のProtected ResourceをID Tokenで保護することについての投稿をしました。

medium.com

いわゆる3legged(ユーザー、AuthZ/Resource Server, Client)でこういう実装をすると上記リスクがあるのは当然でしょうが、世の中にはセッショントークンとしてID Tokenと名乗る物を使うユースケースが存在します。

ritou.hatenablog.com

IDaaSのような認証基盤を利用するとき、

  • (セッショントークンである)ID TokenをID Token発行元のサービスに送り、何らかの操作を行う

という処理が発生するのだろうと考えています。

OSSなものでそのような実装が行われる際には「これってリソースアクセスでは?ID TokenじゃなくAccess Tokenでやるべきでは?」なんて意見が出るようですが、「いや、こっちはリソースサーバーじゃねーし(セッショントークン相当のID Token送るでヨシ!)」みたいな感じになってるようでした。

カオスなままで良いのか?そもそもセッショントークンの扱いとは?

上記のような現状について「リソースサーバーじゃないからそうか。仕様で定義されていない物ならしょうがないか」となっている意見も見受けられます。 仕様がないからしょうがない。 特定の小さな領域でのみの作法に止まるならばそれでも良いでしょう。 しかし、この話はIDaaSを使わない、単純な1st PartyなNativeApp/SPAとバックエンドサーバーの実装にも影響するのではないかと気になっています。

例えばですが、

これはどうでしょうか。

1st Party なアプリとバックエンドでやりとりにOAuth 2.0を適用!ってのをやったことがある開発者であれば、その間は Access Token を用いたAPIアクセスとなるでしょう。 しかし、今後上記のようなIDaaSのお作法から入った開発者の場合、ID Tokenを使ってAPIアクセスを行うという可能性もあるのではないでしょうか? 暗黙的にこれらの2つの実装が広く使われ始めると、開発者の混乱を生みそうです。そうでもない?

この辺りで自分の認識はどうかというと、むかーし、こんな記事を書きました。

ritou.hatenablog.com

この時は今よりも舌ったらずなので内容もいまいち何言いたいかわからんし、今では説明に使うべきではないと思っている「認証」「認可」なんていうワードを軽々しく使っているため皆さんの反応もパッとしない感じでしたが、ブラウザとWebサーバーとのやりとりもざっくりいったら特殊なクライアントとリソースサーバーとのやりとりと同じような意味合いであり、セッションクッキー/セッショントークンは「凄まじい権限を持った」アクセストークン相当であろうというお話です。 当時はブラウザはUserAgent何だからClientではない、みたいなご指摘をもらったりもしましたが、SPAの場合はClient相当がちゃんといるのでなおさら意識しやすくなったのではないかと思ったりもします。

現状に対する自分の考えるあるべき姿としては「どんなユースケースであれ、ID TokenじゃなくAccess Tokenでやれ」という考えであり、中身に含まれる情報の話や処理についてなど、これから色々足りない部分を補足していきたいところであります。