このビデオは、2020 年 1 月 31 日に開催した弊社勉強会のプレゼンテーション録画のパート 4 です。 Lodging Intent Pattern の概要と、関連仕様である Pushed Authorization Requests (PAR) / Rich Authorization Requests (RAR) について、 Authlete の工藤達雄が紹介します。
工藤: Lodging Intentっていうものになります。
なんて日本語に訳したらいいんですかね、こう、インテントを入れる、みたいなやりかた、でいいんですかね。
なんでこれが出てきたかという背景のお話をすると、 まず OAuth のスコープが何も決まってないとのは、たぶんご存知かと思うんですよね。 この枠だけ決まっていて、ここに入るものって、何も決まってないんです。
たんなる、こういった payment っていう 7 文字の文字列でもいいし、ビットを立てて数字でもいいし、
動的に変わるものでもいいと。たとえば何か、構造化したものをエンコードしてもいいと。
もちろん文字種は決まってますけど、何を入れてもいい、ってのが決まっていて。
ただそうすると、この API リクエストのところで、やりたい内容をこのスコープに入れるのは、けっこうしんどいんですよね。
金融系だと、認可リクエストをしたときに、実際の口座を持っている人に対して、 あなたの口座のこの部分をいつまでは（クライアントに）見せたいか、どの範囲で見せたいかってのを、（認可サーバーが）伝えたいと。 それを、同意を取った上で、その同意に基づいてこのあと API リクエストをさせたい、だとか。
あるいはもっと単純に、何か注文を行いたい、あるいは決済を行いたいときに、 ここ（認可リクエスト）で何をいくら書いますみたいなのを送ってですね、 ここ（ユーザー認証・同意）でコンファメーションを出して、そのあと決済のリクエストを飛ばす、みたいなことをやりたい、と。 そういうのをスコープでやるって、けっこう難しいんですよね。
そこでいま、よく欧州でやられているのは、「インテント」っていう考えかたになります。
インテントでは、クライアントが「インテント登録」でやりたい内容に関してはじめに入れて、ロッジして、 ハンドルをもらってそれを認可リクエストに埋め込んで送信します。
認可サーバーはその内容を、「取引内容への承認を確認」で、 認可リクエストに含まれるインテント ID から先の登録内容を引いてきて、それをユーザーに提示して、 OK だったらコードを返して、同意をとった範囲しか処理できないトークンを返します。
クライアントは、そのトークンを使って、API リクエストを送る、と。
たとえば「取引内容への承認を確認」で、どういう決済をしますとか、そのための決済を完了させるとか、 あるいは、3 ヶ月間口座情報を見ていいですかっていうのを訊いて、OK だったら 30 日間有効なトークンを返す、とか。
そういう、「インテント」を登録してもらって、それに応じたトークンを返す、というのがひとつは出てきたっていうことです。
だから、単純なスコープとか、「ペイメント」あるいは「ユーザー」とかみたいな大きな括りではなくて、もっと動的に、取引内容に応じて使えるトークンを払い出したい、 というのが背景にあるわけですね。
このやりかたとして、いくつかのやり方、プラクティスはあったんですけど、これを標準化しようという動きがここ最近、1 年くらいですかね、出てきている感じです。
たとえばどうやってたかっていうと、UK Open Banking だと、これ essential claims って書いてますけれども、 OpenID Connect ではクライアント（リライングパーティ）が、こういうユーザー情報、クレームをほしいですっていうのを、認証リクエストに入れて送ることができるんですね。 この値をくれというのが指定できて、そこに取引内容、あるいは登録した取引のハンドルを埋め込んでそれを送る、っていうやり方で指定している、と。これが UK の場合。
また Berlin Group という、ドイツに限らないんですけど PSD2 をやるにあたっての API 標準化、セキュリティ標準化をやってるところがあって、 ここでやってるのは、Request Object みたいなまどろっこしいことしないで、ダイナミックスコープ、 スコープがころころ変わるようなものでやればいいんじゃないか、インテント ID を毎回毎回スコープに違う値として入れてくようなやりかたでやってく、 というようなケース。
余談ですけど、たぶんこれ、実装的にはけっこうしんどいんですよね。ダイナミックスコープっていうのは、あらかじめクライアント側も認可サーバーも、 決まったスコープを覚えられないので、何かパターンみたいなもので覚えておくことになるんですけど、 商用製品だと難しいかなって気がします。
これで出てきたのが、ひとつは Rich Authorization Requests で、もうひとつは Pushed Authorization Requests というものです。
どちらかっていうと、こっちの下の方ですね、PAR、ピーエーアールとかいてパーと呼んでますけど、 PAR のほうが意外と mature な感じかなという気はします。
これは何を拡張したかというと、PAR エンドポイントっていうのを新しく作るんですね。
認可リクエストを登録しておくエンドポイントを定義して、ここに登録すると request_uri が返ってくると。
そして request_uri を認可リクエストのパラメーターに入れて送ります、っていう感じです。
あらかじめ登録しておくことができるのには利点があって、複雑なリクエスト、何千バイトみたいなものを、リダイレクトに入れなくていい、というのがひとつ。
あともうひとつは、PAR エンドポイントとのやりとりは直接通信なんですね。 なので、そのクライアントが本当に認可リクエストを送っていいかを、事前に直接認可サーバーが確認することができる、と。 場合によっては、このクライアントが、公開鍵ベースで自分を証明した上で送る、と。
ということで、認可リクエストで何か改ざん・すり替えが行われるリスクが、ちょっと下がっていくという感じですね。
もうひとつ、この登録内容を認可リクエストのどこに入れるか、っていうのがあって、
さっきの取引内容みたいなものを、いままでの scope だとかではなく、なにかしら場所を作った方が良いと。
ということで出てきたのが RAR、アールエーアールでラーというように呼びますが、この RAR という仕様になります。
新しく authorization_details っていうパラメーターを定義して、この中にこういう感じで、JSON で入れて、
それを認可リクエストとして送るしくみを定義しています。
PAR と、RARっていうのは、なんというかコンビみたいな関係でですね、こういう長いリクエストを RAR で入れることができても、 そのまま送るっていうのはいろいろ大変なので、PAR を組み合わせるといったような使いかたが想定されています。
仕様自体は、けっこう最近 OAuth ワーキンググループのドラフトとして扱うようになったくらいなので、 まだ新しいといえば新しいです。ただ PAR についてはかなりまとまってきているので、標準化は早いんじゃないかなという気がします。
最後、これからというところですね、 ここまでは割といま使われるというか、よく使われてるとは思うというところで、ちょっと PAR / RAR は（仕様としてはまだでは）ありますけど、 これからどうなるかというところで、2 つご紹介します。
