このビデオについて
このビデオは、2020 年 1 月 31 日に開催した弊社勉強会のプレゼンテーション録画のパート 5 です。 今後普及が期待される仕様として、“Device Flow” / CIBA / Identity Assurance について、 Authlete の工藤達雄が紹介します。
文字起こし（ログを元に再構成）
Device Authorization Grant ("Device Flow")
工藤: これからどうなるかってところで、2 つご紹介します。 仕様としては 3 つなんですけど、2 つのパートですね。
まずデバイスの活用というところですが、 ここまでの話は基本的には、ユーザーが関与・介在する場合のリダイレクションのフローです。 ユーザーがクライアントにまずアクセスし、たとえばログインしたいです、と。 そうするとユーザーからの見た目としては、リダイレクトされてユーザー認証して、またブラウザーのリダイレクトでクライアントに戻る、と。
ここでクライアント側で、 こういった Web サーバーがあるケースはまだいいんですけど。 そうじゃない環境、たとえばこちら側がTVだとかデバイスだとして、そこに対して最終的にアクセストークンを払い出すためには、 どうしたらいいかっていうところですね。
これを実現するための仕様として、最近 Proposed Standard になった Device Authorization Grant、 昔ながらの言いかただと「デバイスフロー」というものがあります。
これは、ユーザーの側に Web ブラウザが使える端末があって、 クライアントはインターネットにアウトバウンドでつながるデバイスで、 認可/APIサーバーがあって、認可サーバーのところには新しく Device Authorization Endpoint ってのがある、ってのが前提になります。
ユーザーはクライアントに対して、連携したいですということを伝えて、 そうするとクライアントはデバイス認可リクエストを Device Authorization Endpointに送る、と。
そうすると、このあと何をするべきかというところで、必要な情報が返ってくる。
たとえば典型的なところだと device_code と user_code、あともうちょっといろいろあるんですけど返ってきて、
このうち user_code をユーザーに、そのまま数字でももいいし,なにかこれを読み取ってくださいとQRコードを見せる、でもいいんですけど、ユーザーに渡す、と。
ユーザーはそれを認可サーバーに出すんですけど、その一方で定期的にクライアントは この Token Endpoint に対してポーリングをかけて、
ユーザーが認可サーバーでユーザー認証をして、user_code を入力すると、アンロックされるというかトークンが発行されて、
クライアントにはポーリングのいつかのタイミングでトークンが返る、と。
トークンが返ったらあとは API アクセスをする、という流れになります。
これ、リダイレクトではないんですよね、見てみると。ブラウザに対して行ったり来たりしてるわけじゃないので。
ただよくよく考えてみると、これって user_code がぐるっと（デバイスから、ブラウザ/ユーザーを経由し、認可サーバーへ）回ってるだけで、
ここで（デバイスから）人間が user_code をもらって、認可サーバーに、左から右に流しているんです。
ある意味、リダイレクトって言えばリダイレクトですよね。
Client Initiated Backchannel Authentication (CIBA)
ここ（デバイスと、ブラウザ/ユーザーとの間）を、通らないフローってのが、実はあるんじゃないか、と。 オチはたぶんもうご存知かと思うんですけど。
ここは認証デバイス、もうちょっとスマートなデバイスっていうのがいまみなさんもお持ちだと思うんですけど、 スマートフォンとかあってですね、そこに対して、なにかプッシュするっていうことも、まあできるでしょう、と。
なので、クライアントがこの認可リクエストを裏で、バックチャネルでイニシエイトして、オーセンティケートする、 っていうような仕組みっていうのが、実はいまできるんじゃないか、と。
これができるとどうなるかっていうと、たとえばクライアント側がスマートスピーカーで、さっきの API サーバーというのが決済サービスだとすると。
それで、わたしがスマートスピーカーになにか話しかけると、スマートスピーカーが裏で認可リクエストを送って、 決済サービスがわたしのケータイに入っている決済サービスのアプリに通知を送って、 確認を出してコンファームすると、決済が終わる、みたいなパターン。
あるいは TV ショッピングみたいなところで、 わたしがいて、デバイスというのはコールセンターのオペレーターが使っている端末で、 決済サービスがあって。
わたしが電話でこれ買いたいですというのを伝えると、コールセンター側ではたとえば電話番号とかからユーザー名を引いてきて、 裏で決済サービスにリクエストして、わたしのケータイの方に通知が送られて、わたしがそれを確認すると、 決済サービスからコールセンターにトークンが返る、というような流れ。
さっきの図でいうと、わたしと、このコールセンターのオペレーターっていうのは、電話で繋がっているだけなんですね。 ここは切れている。何もやりとりしていないっていうとアレなんですけど、OpenID Connect とか OAuth 的ななにかのやりとりはしていない。
あるいは、 この内容はわたしが考えたものじゃなくて、人のをパクってきたんですけど、 コンビニ決済みたいなところで買い物したときに、 端末で、会員証を見せて、支払いをするっていうときに、 コンビニの店員と、レジがあって、こちら側に自分が使っている決済のアプリがあって、決済のモバイルアプリがあって。
ここで「なんとか Pay で払いたいです」って伝えると、 コンビニが裏でわたしのほうの決済サービス事業者にリクエストを送って、わたしには端末に通知が来て、 いまからあなたはこれをいくらで、っていうので、それにオッケーすると裏側でトークンが返る、みたいなモデルですね。
これを実現するのが、CIBAというものになります。
もともと、モバイル系の OpenID Connect のところの話だったんですけど、 けっこう金融系で使い勝手がいいんじゃないかっていう話があって、 いま決済の例を出しましたけど、あと銀行とかあって、 こういうところでいろいろ使おうとしているところですね。
イギリスでは、リダイレクションのフローと、もうひとつ Decoupled Authenticationって言ってますけど、 CIBA を使ったフローが、こちらはオプショナルなんですけど、2 つ並んで、やるべし、というような感じで書いてあります。
フローをちょっとだけおさらいすると…そうですね、今日はちょっとちなみに「おさらい」なので、あんまり深い話はしてないですよね、深い話は。 かんたんに、こういうのがありますよってことで、もし興味があったらいろんな URL とか検索すると出てくるので、別途見ていただきたいと思います。
CIBAのフローですけれど、まず、デバイスが分かれるんですよね。 API 使う側のデバイスと、ユーザーが認証に使うデバイスとが、まず分かれる、と。 ここは物理的に離れててもいいし、この（APIを使う側の）端末を使っている人が、たとえばコールセンターのオペレーターのように自分じゃなくていいですし、 というぐらいわかれているものです。
CIBAの場合には、まずこちら（クライアント）側で、ユーザーは誰っていうことを知っておく必要があるんですね。 なぜかと言うと、この（認証リクエストを）裏で流すときに、ユーザーに対してプッシュ通知する必要があるので、 なにかしらの方法、たとえば Web でまずログインしておくとか、あるいはさっきのコンビニ決済の例のように会員証を見せるとかして、 ユーザーを特定しておく必要があると。
その前提で、認証リクエストを、そのユーザーを特定する値をつけて送ってやる。 認可サーバーは、受け付けましたというのを返して、そのあと、ユーザーに対して通知をする。
通知を受けたユーザーは、端末でもう一回認証するもよし、ログイン済みだったらなにかもう一回バイオメトリクスなんかをやるもよし、 なにかしら認証して取引内容を確認して、オッケーすると、 クライアントにアクセストークンなりIDトークンが返っていく、という感じになります。
ここ（「認証結果とトークンを返却」）で、poll と ping と push ってのがありますけど、 デバイスフローの場合にはポーリングだったのが、一応 3 通りあるということにはなってます。 いろいろ考えていくと poll 一択なんですけど、まあこんな感じですね。
これでトークンをもらって、ID トークンをもらった場合には、ここでユーザーは誰かっていうのがわかるので、 たとえばここ（認証リクエスト）で、こういう認証結果やクレームをくださいとして、返却されたクレームを以って本人の確認を行ったりですとか、 あるいはふつうにアクセストークンをもらう場合には、ここにある、たとえば取引の API をコールするなど、なにか処理をする、 という感じで動いていくものになります。
Identity Assurance (IDA)
最後、これはまだ本当にこれからだと思うんですけど、Identity Assurance のところです。
ここはスライドはないんですが、 さっきもこの essential claim っていうところがありましたけど、 認証リクエストで、どういうクレーム、どういうユーザー属性をください、っていうのを、 あらかじめクライアント、Relying Party が、Identity Provider に教えることができるんですよね。
あと、こういうアイデンティティですよっていうことを返すしくみっていうのも、 ひとつは ID トークン、もうひとつは UserInfo っていうしくみを使って、 OpenID Connect のところで提供方法が定義されています。
ここに検証済、ベリファイされたクレームをどうやって載せるかを定義しているのが、 Identity Assurance 仕様になります。
具体的には、検証済クレームというのを入れるための verified_claims っていう新しいクレームを用意して、
この中（ID トークンや UserInfo レスポンス）にこういうものを入れましょうっていうことや、
このとき（認証リクエスト）にどういうふうに必要だと要求しましょう、みたいなことをこの仕様の中では定義しています。
技術的には、どうなんでしょうね、あまり新しい話ではないかな、と。 こういうのを入れる器をつくりますっていうことで。 どっちかっていうと、ここの中にどういう文言を入れるか、どういうのを入れていいか、っていうところを決めていくのが、 しんどいというとアレなんですけど、グローバルで使っていく中で整備されていくのかな、と思います。
