Table of Contents
この文字起こしは、2022 年 12 月 7 日に開催された Authlete Customer and Partner Meetup 2022 のプレゼンテーションのひとつです。 Authlete 代表取締役の川崎貴彦が、2022 年 12 月リリース予定の Authlete 2.3 をはじめ、今後展開する新機能や仕様についてお話しました。
よろしくお願いします。Authlete の川崎です。本日はありがとうございます。 はじめに、Authlete がやっている標準仕様策定活動について、概要を説明したいと思います。
グローバルに OpenID Foundation という標準仕様策定団体があります。 この団体が、OpenID Connect 関連の技術仕様を中心に策定作業を行っています。
この組織の構成ですが、まずコミュニティボードというのがあります。コミュニティから選ばれた方々であり、議長は日本人の崎村夏彦さんです。崎村さんには Authlete の社外取締役をやっていただいていて、今日本日会場にもいらっしゃっています。のちほど交流していただければと思います。
次にコーポレートボードがあります。こちらは企業会員、お金を払っている会員企業がボードに入れます。
スタッフですが、いまは Gail Hodges さんがエグゼクティブディレクターをやっています。
この組織にサーティフィケーションチームがあります。ここは OIDF 認証制度のために公式適合性テストを開発しているチームです。弊社の CTO である Joseph Heenan が率いています。Domingos Creado という弊社のブラジルのコンサルタントも、このチームに入っています。
OpenID Foundation にはワーキンググループ (WG) が現時点で 10 個ぐらいあります。
中心となるのが AB/Connect WG です。
注目するべき WG として eKYC & IDA があります。ここでは OpenID Connect for Identity Assurance (OIDC4IDA) という仕様を策定しています。
FAPI は、FAPI1 や FAPI2 の WG です。
あと MODRNA（モダーナ）という WG があります。ここは CIBA 仕様を最初に作ったところです。
そして、ここでの議論は全部公開されています。この議論に参加し発言するためには、あらかじめコントリビューションアグリーメントへの署名が必要です。それを署名さえすれば、みんな誰でも議論に参加できます。お金を払うと OIDF 会員になることができ、仕様に対する投票ができます。
我々はいくつかの WG に定期的に参加しています。FAPI の WG は毎週水曜日夜 11 時から参加しています。eKYC & IDA WG の定例会がその FAPI の WG のすぐ後にあり、これは木曜日の午前 0 時、水曜日の夜中です。
あとで言及しますが、GAINというプロジェクトの PoC の WG があります。これは隔週木曜日の 9 時と金曜日の朝 4 時です。金曜日の朝 4 時に参加するのはけっこうきついです。
もう一つ、標準化団体として気にかけておかないといけないのは、IETF (Internet Engineering Task Force) です。 そこに WG がたくさんあります。OAuth や HTTP の WG があります。 しばしば OAuth の文脈で RFC の番号や名前が出てきますが、これは IETF で承認された仕様ということになります。
余談ですが、FAPI の WG には Authlete のメンバーがたくさん参加しています。ある日は Authlete メンバーの比率が高くて面白かったので、スクリーンショットを撮りました。
そして OIDF に「サーティフィケーションプログラム」があります。これは実装が仕様に準拠しているかどうかを確認し、サーティフィケーションを与える、というプログラムです。OpenID Foundation という組織に Joseph Heenan が率いるサーティフィケーションチームがあります。ここが適合性テストを開発しています。
テストスイートはオープンソースです。認証を受けたい企業がこれを使って自分でテストを実行し、全部パスしたら、テスト結果を添えて OIDF に認証を申請します。
結果を中で精査して、本当にパスしていれば認証を付与します。そして、認証を受けた企業は、OpenID Certified というマークを使う許可を得られます。
適合性テストを作っていますが、テスト自体のテストはどうするの、ということがあります。
これは、テスト対象となる技術仕様の実装を用いてテストします。 よって、ある程度動いている実装が、テストの前に必要です。サーティフィケーションチームはどうしているか。 実は実装として Authlete を裏で使っています。 そして、テストの更新版をリリースするのは、Authlete とのテストをパスした後になります。
このような経緯から、Authlete が 新しい公式テストの認証の世界で最初に取るのは、実は必然です。それが、Authlete の認証取得が一番早い理由です。
OpenID Foundation で仕様を作って、Authlete が実装して、FinTechLabs.io が試験しています。この FinTechLabs.io というのは OIDF からテスト開発を受託している会社です。イギリスの会社ですけど、実は Authlete のグループ会社のようなものです。Joseph が CTO をやっています。
テストを作って、そのテストを実行すると、Authlete がテストをパスしない場合があります。そしてこの時に考えられる可能性としては、Authlete の実装に不具合がある・テストの実装に不具合がある・仕様の記述が曖昧で解釈が分かれる、の 3 つです。
三番目の場合、実装を作ったわたしと、テストを作った Joseph との間で、この仕様のここの文言は、こういう意味じゃなくてこういう意味じゃないの、という具合になります。
そしてこのパターンはしばしば発生します。あるときは Authlete 社内の Slack で、わたしと Joseph と Justin Richer が、仕様の修正案を議論しました。そしてその結論を、WG に提案するというかたちになりました。
この仕様修正案を議論しているときが、最新仕様に関する世界最先端の議論を社内で行っているときであり、技術者的にはけっこう楽しい瞬間だったりします。
この Justin Richer は、実は有名な人です。いろんな仕様を作っています。OAuth 2 in Action の著者でもあります。
次は、Authlete と主要な標準仕様との関係についてです。
Authlete の最初のコミットは 2014 年の 4 月です。けっこう前になります。 そして Authlete 1.1 を出したのが 2017 年ごろです。 このときは OAuth や OpenID Connect の基本的な機能を実装しました。
その後いろんな機能を実装しています。Authlete 2.0 のときの大きな仕様としては FAPI 、Authlete 2.1 のときには CIBA 仕様、Authlete 2.2では IDA 仕様に対応しました。そして今 Authlete 2.3 をリリースしようとしています。この中で大きな仕様が、OpenID Connect Federation です。
順次見ていきます。 まず FAPI です。最初は Financial API という名前で始まって、Financial-grade API になって、最後に FAPI になりました。
2017 年、FAPI の最初の、実装者向け草稿第 1 版が出ました。Implementer’s Draft の 1 番目なので、ID1 と呼ばれたりします。
それから 2018 年の 10 月に ID2 が出ました。このときに Financial API という名前が Financial-grade API に変更になりました。 これは、Financial API だと金融業界だけでしか使えないという、誤解というか認識があったところ、実は他の業界でも使えるよということで、名前を変えて Financial-grade API となりました。
そして 2021 年 3 月にファイナル、Financial-grade API の最終版が出て、これで FAPI は一区切りがつきました。細かいところですが、FAPI の最終版では、Part 1 の Read Only というプロファイルの名前が Baseline に変わったり、Part 2の Read & Write が Advanced に変わったりしました。
ここまでが FAPI1 と呼ばれているものです。
そしてこの後も活動が続いています。FAPI 2.0 の Baseline の ID1 が 2021 年 7 月に出ました。ここから FAPI2 と呼ばれるものになります。
FAPI2 から、Financial-grade API という名前が、FAPI という名前になりました。 Financial-grade だと、まだ Financial が残っていることを他の業界の人が気にして、採用をためらうという話もあったりして、FAPI になりました。 そして、FAPI はなにかの略称ではなく、たんに FAPI である、となりました。
そして現在、FAPI 2.0 Security Profile の ID2 がパブリックレビュー中です。これが予定通り進むと、2023 年の 1 月に承認される見込みです。 また、細かい話ですが、Baseline Profile から Security Profile に、名前が変わりました。
Authlete 2.3 では、この FAPI 2.0 の Security Profile ID2 をサポートします。
さきほど ZDF さまからお話がありましたが、FAPI2 のひとつの例として、PAR (Pushed Authorization Requests) が必須化されます。PAR は認可リクエストを事前に登録するしくみです。最近公開された、サウジアラビアオープンバンキングの仕様でも必須になっています。
通常、認可サーバーは認可エンドポイントとトークンエンドポイントを提供しますが、PAR をサポートする認可サーバーでは、さらに PAR エンドポイントも実装します。
クライアントアプリケーションは、認可リクエストを組み立てた後、最初にこの PAR エンドポイントにアクセスし、認可リクエストを登録します。その結果として、クライアントに Request URI が返却されます。
次にクライアントはいつものように、ウェブブラウザを介して、認可リクエストを認可エンドポイントに送信します。クライアントはこのとき、PAR エンドポイントから発行された Request URI をリクエスト中の request_uri パラメータに含めます。
この後はこれまで同様、認可サーバーは認可コードを発行し、クライアントはその認可コードを持ってトークンエンドポイントにアクセスし、認可サーバーはアクセストークンを発行します。
また余談ですが、あるときオーストラリア CDR (Consumer Data Right) という仕様で PAR を採用する話になりました。
ただし、当時 PAR はドラフト段階でした。このまま採用されると相互運用性の問題が出てしまうため、OIDF は PAR のテストを作る必要が出てきました。 OIDF の Certification Team としては、PAR のテストを作るには参照実装が無いと、テストのテストができません。つまり、誰かに PAR を実装してもらわなくてはなりません。
Authlete としては「お、おぅ」という感じでした。
そのあと Authlete の社内でかなり議論しました。 PAR を実装してもその費用は払ってもらえない。しかし、この赤線を引いたところにあるように、これやったら Authlete の名声が上がるぜ!? みたいなやり取りがあって、がんばって実装しました。
ということで、オーストラリア CDR で PAR が採用されたのは、Authlete が一気に集中して作業した結果です。しかし、オーストラリアの人たちは我々の苦労をまったく知らない状況です。
Authlete 2.1 から CIBA が入っています。これはユーザー認証や同意取得を行う認証デバイスと、クライアントアプリケーションを搭載する消費デバイスとを、別々にすることができるフローです。承認者と実行者を分ける必要があるユースケースにおいて威力を発揮します。
イメージ図です。たとえば家に人がいます。スマートスピーカーがあります。人が、何かを買いますといった命令をスマートスピーカーに出すと、スマートスピーカーが裏にいるシステムに音声を届けます。通常では、そのバックエンドシステムは何かを購入するための API を呼び、取引が完了します。
これが、もし認可サーバーが CIBA をサポートしていた場合には、バックエンドシステムはその API コールを行う前に、CIBA で認可サーバーに権限を要求します。バックチャネル認証エンドポイントという特別なエンドポイントに、バックチャネル認証リクエストを投げます。
そのリクエストを受けた CIBA 対応の認可サーバーは、認証デバイスに通知を送ります。システムが権限を要求していますが承認しますか、と。 それでユーザーが承認すれば、認可サーバーはアクセストークンを発行し、クライアントはそれを使って API リクエストする、という流れです。
これによって新しくカバーできるユースケースがいろいろあります。 たとえば、承認者と実行者が分かれている場合です。親と子供、上司と部下、お客さまと売り手、という感じで、夢が広がります。
Authlete 2.2からは OpenID Connect for Identity Assurance (OIDC4IDA) もサポートされます。
これは、パスポートや運転免許証などの法的書類等で確認済みのユーザー属性情報を、確認手段はこうでしたというような情報と一緒に流通させるしくみです。 技術的には、IDトークンや、ユーザー情報エンドポイントのレスポンスに、verified_ claims という特別なクレームを埋め込みます。
たんにユーザーの名前がこれでした、ということだけではなく、どのような法律に基づいているか、どのような手段で確認したのか、誰がいつか確認したのか、どの証拠を確認したのかを確認できます。
一般的なソーシャルメディアに登録されているユーザーの名前や誕生日は、ユーザーの自己申告です。まったく信用できないため、法的な、厳密な本人確認が必要な文脈、たとえばお酒を販売するときの年齢確認の文脈では使えません。これを解決するのが OIDC4IDA です。
ユーザー登録時にちゃんとした本人確認をやっている事業者が OIDC4IDA 仕様をサポートすると、プラスアルファでいろいろできるようになります。たとえば銀行や携帯キャリアは、銀行口座を作るときや携帯電話の契約をするときに、そのような本人確認をやっているので、その基盤はあるということですよね。
この OIDC4IDA の仕様は、2019 年に草稿第 1 版、2020 年に第 2 版が出ていました。 Authlete 2.2 は、この OIDC4IDA の第 2 版をサポートしています。
その後第 3 版が出て、2022 年の 10 月に第 4 版が出ました。Authlete 2.3 では、この OIDC4IDA の草稿第 4 版をサポートしています。
実は版を重ねるごとに、かなりのブレイキングチェンジ（破壊的変更）が続いていたのですけども、ようやく安定してきて、いま最終版のリリースに向けて準備中の段階です。この破壊的変更についても言いたいことはいろいろあって、仕様策定者とけっこういろいろやりとりをしたんですが、時間がありませんので割愛します。
OpenID Connect Federation の話をします。Authlete 2.3 でサポートします。これはかなり巨大で、実装した中では過去一番難しかった複雑な仕様でした。
どういうものかというと、外部ネットワークにある OpenID プロバイダーやクライアントアプリケーションを、トラストチェーンに基づいて信頼し、事前登録せずに相互連携を可能にする仕様です。
そのほか、OpenID プロバイダーやクライアントアプリケーションのメタデータの値に対して、トラストアンカーや中間オーソリティがルール（制限）を設けることができます。技術用語で言うと、メタデータポリシーの設定が可能になります。
具体的にどんなフローになるか。まず、リライングパーティー (RP) クライアントと、OpenID プロバイダー (OP) あるいは認可サーバーがいます。
RP が OP にリクエストを投げます。そのリクエストにはクライアント ID が含まれます。そしてこのクライアント ID は、OP に登録されていない値であり、URI の形式をしています。
OP は、その URL が指すサーバーにアクセスします。 サーバーの /.well-known/openid-federation に行くと、そこから entity configuration という JWT が発行されます。
ここには RP のメタ情報が含まれます。また、その JWT の中に入っている authority_hints に、中間オーソリティーやトラストアンカーの情報が入っています。
authority_hints の値を元に、OP は、次に中間オーソリティーにアクセスし、「中間オーソリティーの entity configuration」を取得します。この中には、また authority_hints が入っています。
OP が取得した「中間オーソリティーの entity configuration」には、 federation_fetch_endpoint というものも入っています。 OP はこのエンドポイントに、「中間オーソリティであるあなたは、この RP に信頼を与えますか?」と問い合わせます。
その中間オーソリティーがその RP に信頼を与えていて、管理下に置いていれば、OP に entity statement が返却されます。これはその中間オーソリティーが「その RP に関して OK ですよ」と示す情報です。
中間オーソリティーはまだ「中間」であり、「終端」ではありません。よって、トラストアンカーに到達するまで、OP は似たようなことを続けます。
OP がトラストアンカーにアクセスして、entity configuration をもらいます。そしてその情報をもとに federation_fetch_endpoint にアクセスして、entity statement を取得します。つまり今度は、トラストアンカーに「その中間オーソリティに関して OK ですよ」と証明してもらう感じです。
以上の結果、一番最初に entity configuration があり、その後に 2 つの entity statement が続きます。この例では、この 3 つでトラストチェーンができあがります。
このトラストチェーンができた後に、最後にトラストアンカーがあるので、OP は、そのトラストアンカーを信用済みかどうか確認します。
そして JWT の署名を全部チェックして、メタデータポリシーを適用して、ようやくクライアント (RP) のメタデータが用意できました。このメタデータをもとに、OP は RP を自身に登録します。このようにして、自動的に登録するというかたちです。
このように大変な仕様ですが、Authlete への実装は終わっています。
この OpenID Connect Federation という複雑な仕様を、なぜ Authlete は実装したか。それはこの仕様が Global Assured Identity Network (GAIN) と呼ばれるプロジェクトで使われるからです。
GAIN は、インターネット上に世界規模の高信頼性デジタルアイデンティティネットワークを構築するプロジェクトです。2021 年の 9 月には 150 名以上の著者が集まって、こんな世界を実現する、というホワイトペーパーを書いています。
GAIN の PoC のドキュメントから、イメージ図を引用しています。かんたんに言うと、Network of Networks (NoN) という考え方です。たとえば UK には UK オープンバンキング、ドイツにはドイツのオープンバンキングと、それぞれエコシステムが存在する中、それらネットワークを相互につなぐネットワークを作ろうというものです。
GAIN の PoC は現在進行中です。この PoC で用いられる標準仕様として今のところ決まっているのが、OpenID Connect Federationと OpenID Connect for Identity Assurance です。さきほどご紹介した 2 つが使われます。
GAIN PoC に参加している企業は、日本の Authlete 社とドイツの yes.com 社（ベンダーとしてブルガリアの Connect2ID を使用）です。また、OpenID Connect Federation 仕様はイタリアで実はデプロイ済みで、すでに動いています。そのイタリア eID の関係者も、仕様策定者の一人でもあるのですが、PoC に参加しています。あとはオーストラリア CDR の関係者も参加しています。
お互いに、たとえば Authlete とyes.com の間で、クライアントが OpenID プロバイダーに登録できたらつながると。お互いそういうことができれば、つながったねとなります。いよいよそれが動き始めるというところです。
Authlete を使っているお客さまは、Authlete 2.3 がこれらの仕様をサポートするので、海外の、たとえばイタリアのネットワークに入って相互運用できるという、すごいことが可能になります。
次も余談ですけど、OpenID Connect Federation 仕様をサポートするとサーバーメタデータにこういうのが追加されます。
一番上にあるのが client_registration_types_supported、どんなのをサポートしていますかというものです。そして request_authentication_methods_supported という、各エンドポイントでどのようなリクエスト認証メソッドをサポートしているかのリストがあります。
Authlete では、すべての考えられるエンドポイント、考えられるメソッド全部の組み合わせをサポートしました。おそらくここまでやっている実装は、世界でも Authlete ぐらいしかありません。たとえば前述のイタリアの方は、仕様は作っているが、explicit client registration は実装していないと言っていました。
Authlete 2.3 でサポートされる他の標準仕様をご紹介します。
EARTHBRAIN さんに言及していただいた、Token Exchange 仕様をサポートします。 これは、自身が発行したトークンや第三者の発行したトークンの情報をもとに、新たなトークンを発行する仕様です。
仕様としてはけっこう汎用的です。よって、実際に使うためにはもう細かく具体的に決めないといけませんが、大枠となる仕様です。
次に RFC 7523 の JWT Authorization Grant を今回サポートしました。これもすごく単純で、JWT を提示してアクセストークン発行を受けるという感じです。 認可コードフローだと認可コードがいわゆるアクセストークンの発行を受ける権利を表すものになりますが、同じ役目を JWT に持たせます。このJWTは自分自身もしくは第三者が発行したものです。
認可サーバーは、何らかのルールに基づいて、問題なければアクセストークンを発行します。 この仕様も Token Exchange と同様、実際の運用に用いるためには、そのルールを自分たちで決める必要があります。
最近できた仕様として、Step-up Authentication Challenge Protocol があります。
この仕様では、アクセストークン発行時のユーザー認証がどういう基準を満たしているか、ユーザーが最後に認証を受けてからどれくらい時間が経過しているか、といった情報をアクセストークンにひもづけておきます。
そしてクライアントがアクセストークンを持ってリソースサーバーにアクセスしたときに、たとえばこのエンドポイントは「より厳密なユーザー認証をした結果得られたアクセストークンでないとアクセスを許さない」とか「最後のユーザー認証から 600 秒経っていたから再認証してくれ」といったエラーを返すことができます。
このリソースサーバーからのエラーを受けたクライアントは、新しいアクセストークンを取り直そうと判断できます。
これが Step-up Authentication Challenge Protocol です。 これも Authlete に実装されています。
さきほど ZDF さまが言及されていた、Grant Management for OAuth 2.0 にも対応します。FAPI2 で採用される可能性があります。
これはユーザーがクライアントアプリケーションに与えた権限を累積的に管理していくしくみです。 「アクセストークン 1」の発行時に権限をもらっている状態で、「アクセストークン 2」という別のトークンをもらった際に、それを累積的にひとつのグラントとして見なすことができます。
OIDC4IDA の関連仕様として Advanced Syntax for Claims が定義されており、その中にTransformed Claims があります。これはたとえば birthdate（生年月日）というクレームがあったとして、その誕生日という属性を元にいろいろ変換を繰り返して別の値を作るというしくみです。これを Authlete では実装しています。
次の例では、生年月日という元データを使って、ある人が 18 歳以上かどうかをチェックしています。生年月日は個人情報なのでできれば開示したくないのだけれど、18 歳以上かどうかだけを伝えたい。そのような文脈の時に、このように利用できます。
この変換関数はいくつか定義されていますが、Authlete では全部サポートしています。 というか、たぶんこの仕様をサポートしているのは、世界でも Authlete しかありません。 以前、OAuth Security Workshop でデモもしました。
こんな仕様もお楽しみいただけます。
Authlete 2.3 固有の機能です。 バックポートを含めるといろいろあります。
この中でひとつご紹介したいのは、冪等性リフレッシュトークンという機能です。 これは同じリフレッシュトークンを用いたリフレッシュトークンリクエストがに複数回来た場合、それをある期間内は許容し、同じリフレッシュトークンが来たら同じアクセストークンを返します。
クライアントによっては、同じリフレッシュトークンを 2 つ送信してしまうことがあります。1 回目のリフレッシュに成功すると、2 回目にまた新しくリフレッシュされてしまい、いろいろ「壊れてしまう」ことがあります。この機能はそれを防ぐためのものです。
この件では、いろいろなところが四苦八苦しています。オープンバンキングブラジルでは、リフレッシュトークンンリクエストのときにリフレッシュトークン自体を更新しない（リフレッシュトークンのローテートをしない）とルールを決めています。オーストラリア CDR の方ではそこらへんのルールを決めてなくて、けっこう悲惨なことになっていたりします。
また、この冪等性リフレッシュトークンの機能を重宝されている、海外のお客さまもいます。必要なお客様にとっては非常に重要な機能です。
Authlete の開発プロセスについてご紹介します。
Authlete には現行バージョン、開発バージョン、旧バージョンがあります。現在は、現行バージョンが Authlete 2.2 で、Authlete 2.3 の開発を進めています。
新機能追加にあたって、データベーススキーマの変更を伴う場合には、開発バージョンだけにしか機能を追加しません。一方、データベースに変更が発生しない場合には、現行バージョンにも新しい機能を追加します。
よって、Authlete 2.3 でサポートする予定の新しい機能が Authlete 2.2 にバックポートされることはよくあります。また、不具合が発生した場合には、旧バージョンに対しても全部修正を適用します。
Authlete の後方互換性についてです。
新しい機能を追加するときに、しばしば boolean フラグを追加します。 機能のオンオフを切り替える真偽値フラグです。 初期値は false です。Authlete のバージョンを上げても、基本的には動作が変化しないようになっています。
ただ残念ながら、標準仕様自体に変更がかかることがあります。 セキュリティの理由によりこれはこうしなくてはいけない、というようなケースです。 仕様に厳密に従うためには、Authlete もそのように実装しないといけません。 しかしそうすると、すでにデプロイ済みのシステムが壊れてしまいます。そこで、移行期間用の真偽値フラグも Authlete に用意しています。
FAPI1 Part 2 の ID2 から Final に移行する際、リクエストオブジェクトに nbf クレームを含めなくてはいけない、というルールが追加されました。それまでは、クライアントがリクエストオブジェクトを作る際、exp クレームは入れても nbf クレームはほとんどの場合入れていませんでした。
もし Authlete が、この変更を受けていきなり「nbf クレームがないからそのリクエストオブジェクトは不正です、受けつけません」と対応すると、全部動かなくなってしまいます。さらには、サーティフィケーションテスト自体も動かなくなってしまいます。
サーティフィケーション自体も準備期間が必要だったため、nbfOptional フラグを用意しました。これを true にすると、FAPI1 Part 2 の文脈でも nbf クレームをオプショナルにします。厳密には仕様違反ですけれども、移行期間中はそれを true にしておきます。
traditionalRequestObjectProcessingApplied は、リクエストオブジェクトの処理のルールに関するフラグです。
OpenID Connect Core にリクエストオブジェクトの仕様がありますが、その部分だけを引っ張り出して RFC 化した仕様があります。RFC 9101、JAR (JWT-Secured Authorization Requests) です。
OIDC Core のリクエストオブジェクトの仕様と、JAR の仕様とで、実はブレイキングチェンジがありました。 これは、気にしない人は気にしないのですが、実装者はめっちゃ気にするわけです。 大論争になって、場合によっては喧嘩腰になるぐらいの勢いでした。
処理のルールが変わってしまいましたが、ただこれも移行期の問題があるので、フラグを用意しました。 このフラグが true の場合には従来の OIDC Core 仕様のルールに基づいて、false の場合には JAR 仕様に基づいて、リクエストオブジェクトを処理します。
OAuth では「リダイレクト URI」というのを使いますが、その URI のホスト部が、たとえば localhost みたいにループバックを表している場合に、このフラグによってポート番号部分を可変にします。localhost:8080 とか localhost:8000 などのようなかたちです。
OIDC Core やその関連仕様に厳密に従うと、リダイレクト URI は完全文字列一致であり、ポート番号も含めて文字列として完全に一致しないとアウトです。ただ、その後の業界のユースケースの発展などに伴って、ポート番号はやっぱり可変にしたい、ポート番号部分はリダイレクト URI が既に登録済みのものと一致するかどうかのチェックから外してほしい、ということが出てきました。
そのチェックから外すと、新しいユースケースには対応できるようになりますが、昔の仕様上、今までアウトになっていたものが通るようになってしまいます。どちらにするか、認可サーバー運用者が選択できるように、Authlete では loopbackRedirectUriVariable フラグを用意しています。
移行するとか、それぞれの用途に合わせるとかのために、機能を on/off していただくかたちです。 Authlete では、こういうことを丁寧にやっています。 いま動いているシステムが壊れないように、ときには業界団体と議論しながら、必要に応じてやっています。
面白いのは、特定地域・特定顧客への対応があります。要望の詳細を一生懸命に聴いて、できる限り汎用機能として実装します。
たとえば dcrDuplicateSoftwareIdBlocked というフラグがあります。 動的クライアント登録 (Dynamic Client Registration) を行う際、クライアントは software_id という情報を含めることができます。software_id が含まれていた場合には、Authlete はそれを保存します。
あるときオープンバンキングブラジルにおいて、1 回使われた software_id を再度の登録に用いてはならない、というルールが追加で発効されました。
このルールに対応するためのアプローチとして、他の製品によっては「オープンバンキングブラジルプロファイル」のようなチェックボックスをつけたり、「オープンバンキングブラジル専用」の製品に分岐したりします。
一方 Authlete の場合はエッセンスだけを抜き出します。これは「software_id の重複を許さない」というフラグを立てればそのように動作する、というように作っています。
オープンバンキングブラジルでは、リクエストオブジェクトの暗号化に使う alg という値と enc という値が、ある特定のアルゴリズムに沿っていなくてはなりません。 仕様上は、仮に暗号化のアルゴリズムが設定されていても、それはオプショナルの扱いです。しかしブラジルの場合は、そこを完全一致させる動作が必要となります。
これに関しては、クライアントのメタデータに、request_object_encryption_alg と request_object_encryption_enc があって、Authlete のフラグを立てると、クライアントのメタデータが要求するアルゴリズムと実際のリクエストオブジェクトのアルゴリズムとが完全に一致するかどうかを確認します。
その他、フラグだけではなく、「パラメーター化されたスコープ」を汎用機能として作り込んでいます。
よくスコープ名として read / write / profile などの固定値がありますが、エコシステムによってはスコープ名の一部が可変になったりします。
たとえばオープンバンキングブラジルだと「コンセント ID」というのがあって、同意を取ったときに、その同意に対応する ID を発行し、それをスコープで表現します。その値は “consent” という文字列で始まり、“:” がついて、さらに可変の ID が入ります。認可サーバーとしてはこれは未知のスコープだから無視する、というのが普通の動作です。しかしそれではオープンバンキングブラジルで動作しなくなります。
Authlete では、任意のスコープに対して regex (regular expression) という属性を指定できるようにしました。そしてその属性値として正規表現を書いておくと、Authlete は、「正規表現にマッチするスコープの値はその任意のスコープである」と認識し、「これは既知のスコープだから無視せず受け入れる」と動作します。
このようなかたちで、できるだけ分岐しないように、特定地域・特定顧客への対応ではない、汎用機能として実装しています。
最後に Authlete 3.0 の話です。
Authlete 2.x 系は API キーと API シークレットを用いた API コールになっています。また、サービス管理とアプリ管理とで別々のWeb コンソールがあります。そして、管理者のログイン ID とパスワードを共有するかたちになっています。
これに対し Authlete 3.0 では、アクセストークンを用いて API アクセスするようになります。 API のパスが変わりますが、たとえば Authlete の Java のライブラリーでは下位のレイヤーでその差異を吸収するので、Java の API には変更ありません。同じような対応を、他の言語向けのライブラリーにも行っていきます。
次に Web コンソールが統一されます。アクセストークンを持って Web コンソールにアクセスしますが、そのトークンの権限の違いで、表示や機能を切り替えます。
たとえば、サーバー管理の権限を持つアクセストークンで Web コンソールにアクセスするとサーバー管理の画面が出て、クライアントアプリケーション権限しか持ってない場合はクライアントアプリケーション編集画面しか出ない、といったかたちになります。
これは内部で RAR (OAuth 2.0 Rich Authorization Requests) を使っています。 権限の細かいところは authorization_details で管理しています。 RAR は新しい仕様のひとつです。それを自分たちで実装して自分たちで使う、ドッグフーディングという感じで使っています。
まとめると、Web コンソールを統一します。ログインするユーザーごとにアクセストークンが発行されるので、ログインID・パスワードを共有しなくても良いしくみになります。
Authlete 3.0 の開発は、実はかなり長いことをやっていて、もう 1 年以上続けています。 基本的にはもう随分前から動作していますが、現在は、Web コンソールをより fancy にしようとしています。 改善していって、きれいに整ったら、Authlete 3.0 のコンソールとして提供する予定です。 まだリリース時期は決めていませんが、時期をみて出していきます。
このしくみ的にアクセストークンを発行する仕組みが必要なので、Authlete の IdP を別途立ち上げます。 そこにログインして、アクセストークンをもらって、というかたちになります。
今後です。
IETF で議論されている、HTTPのメッセージに署名するための汎用的な仕様です。Justin Richer が中心になって作っています。 FAPI2 の、Security Profileではなく Message Signing のほうで採用される可能性がある、もしかしたら採用確定済み、となっているようです。
Justin 本人の手によって Authlete 3.0 に関連機能が実装済みです。 リソースリクエストの際の、HTTP のメッセージとかに署名があったりなかったりとかの検証ができるようになっています。
あと気になっているのは Verifiable Credentials です。話がよく出ています。
OpenID for Verifiable Presentations とか Self-Issued OpenID Provider などの関連する仕様を、おそらくなにか実装することになると思います。
仕様策定作業に関して、細かいところですけど、CIBA と OIDC4IDA を同時に使うというのが、現時点の仕様ではできていません。 これは、IDA 仕様では claims リクエストパラメーターに結構依存しているところ、CIBA のバックチャネル認証エンドポイントが claims リクエストパラメーターをサポートしてないためです。
これについて、各種ワーキングループに諮って、議論開始をはたらきかけています。CIBA とIDA を組み合わせたユースケースが具体的なビジネスとして出てきていて、Authlete 社としてどうしても実現したいということでやっています。
OIDC4IDA の残りの、Advanced Syntax for Claims ですが、Selective Abort / Omit がまだ片付いてなくて、この仕様も引き続き議論して、もうそろそろ片付けたいなというところです。
以上で私の発表を終わります。ありがとうございました。
