Apidays Paris 2025 - From AuthN to AuthZ: The Future of Identity By Dick Hardt
Dick Hardt: では、ボンジュール。私が知っているフランス語は、ほかに4語くらいしかありません。まあ、これは知っています。
Dick Hardt: Paris の API Days に来られてうれしいです。先ほど紹介がありましたが、私は Dick Hardt です。1週間ほど前に Paris に引っ越してきました。夏の終わりまでここにいるので、Paris に住んでいてコーヒーでも飲みながら話したいという方がいれば、ぜひ連絡してください。
Dick Hardt: 私は連続起業家です。Microsoft と Amazon の両方で何度か働いたことがあり、OAuth 2.0 と JSON Web Tokens のもとになった設計を主導しました。今は、これから出てくる新しい仕様にいくつも取り組んでいます。
Dick Hardt: 今日は、identity の未来について話します。特に B2B、B2C、Agent Identity の話をします。最後にできれば質疑応答の時間も取りたいと思います。
Dick Hardt: では、auth について話しましょう。AuthN、つまり authentication があります。OpenID Connect と SAML はそのためのプロトコルです。AuthZ、つまり authorization もあります。access control や OAuth 2.0 です。人々はこれらをよく混同して、「OAuth でログインする」と言ったりします。でも、OAuth は本来そのために作られたものではありません。
Dick Hardt: そして、AuthN と AuthZ と言う代わりに、みんな単に「auth」と言います。「auth を入れよう」という感じです。Better Auth というパッケージもあります。これは AuthN でも AuthZ でもありません。私たち業界の多くは、「AuthN のことですか、それとも AuthZ のことですか」と細かく指摘してきました。でも、もう auth と呼べばよいのではないかと思っています。
Dick Hardt: 企業向けの identity and access management、つまり IAM は、略語だらけの世界です。SAML があり、OpenID Connect があり、SSO、つまり single sign-on の定番プロトコルがあります。directory sync があり、SCIM があります。そして、ここで少し話す新しいプロトコルとして、OPC、OpenID Provider Commands があります。
Dick Hardt: 企業向け SSO では、設定すればいろいろなことができます。望めば何でもできるようにできます。
Dick Hardt: しかし実際には、全体を導入し始めると複雑です。そして、動くだけでうれしくなります。いったん動くようになると、「触るな。今は動いているんだから」となります。安全かどうかは分かりません。でも動いてはいます。
Dick Hardt: 企業顧客は、よく独自で分断されたセキュリティ要件を持っています。「こう設定されていなければならない」と考えているものがたくさんあります。
Dick Hardt: しかし、それを構築して導入するための要件には抜けがあることが多く、そのせいで構築も導入も難しくなります。抜けている部分について、こちらが推測しなければならないからです。そして、何らかの値や設定を選んで進めることになります。
Dick Hardt: また、SAML は枠組みとしては適合性試験がありません。「本当に本来の動きをしているのか」は分かりません。
Dick Hardt: そのため SSO では、システム間や業務手順の間にあるこうした隙間が、しばしば「やらかし」につながります。
Dick Hardt: 侵害が起きたり、本来アクセスすべきでない人が何かにアクセスできてしまったりするのです。
Dick Hardt: 業界として、私たちはこうしたやらかしを IPSIE、Interoperable Profiling for Secure Identity in the Enterprise で直したいと考えてきました。
Dick Hardt: これらのプロファイルは、かなり方針が明確な仕様です。「こうやる」と定めます。そうすることで適合性試験が可能になり、期待どおりに動いていることを確認できます。認定もできます。そして、そのための成熟度レベルもあります。session lifecycle のレベル1から3、account lifecycle のレベル1から3があります。
Dick Hardt: account lifecycle について、もう少し話します。なじみのない方のために説明すると、企業向け IAM では、ディレクトリで変更を行うと、それがすべてのアプリケーションに反映されることが目標です。オフボーディングは、実は価値の80パーセントを占めています。ある人をディレクトリから外すと、その人がすべてのアプリからも外される、ということです。
Dick Hardt: 現在、account lifecycle を行う最も一般的な方法は SCIM です。これは REST API です。リソースがスキーマを定義します。つまり、動くように設定するときには、自分たちの提供者が identity をどのように管理しているかと、アプリ側がそれをどのように表現することにしたかを対応付けなければなりません。手動設定が必要です。認証の仕組みは仕様で定められていないので、アクセスのために OAuth サーバーを設定する必要があります。非常に強力で、複雑な directory sync のために設計されていますが、Fortune 5000 以外では広く導入されていません。
Dick Hardt: 私はそこに問題があると考えました。同僚の Karl McGuinness は、以前 Okta の最高製品アーキテクトでした。彼と私は、OpenID Foundation で標準化を進めている新しいプロトコルを作りました。OpenID Provider Commands、OPC です。これは OP からアプリケーションへ直接送られるコマンドです。ほかの auth は必要ありません。ID token と同じような署名付きトークンです。そして、ISO lifecycle 全体を支えます。delete や active だけでなく、アプリが変更したいさまざまな状態を扱えるようにします。
Dick Hardt: そのため私は、将来 IPSIE によって、単に「SSO をやってください。SSO を設定しています」と言うのではなくなると見ています。これは曖昧で個別対応になりがちです。一方で IPSIE は明確なレベルを提供します。私の期待は、企業顧客が「SSO が欲しい」「SAML が欲しい」と言う代わりに、「IPSIE の session level 2 が欲しい」と言い始めることです。そうなれば導入はずっと簡単になります。最初から安全なものになります。つまり IPSIE によって、やらかしは少なくなるはずです。
Dick Hardt: 同じように、OPC は account lifecycle、特にオフボーディングを行うための障壁を大きく下げ、多くの組織がそれを利用できるようにすると考えています。
Dick Hardt: account lifecycle の話が出たので、ここで少し宣伝です。私たちが Hello で作っていて、無料で提供する予定のものがあります。GitHub offboarding です。ユーザーが個人の GitHub アカウントを仕事用アカウントにひも付けます。そうすると、その人がディレクトリから外されたときに、GitHub からもすぐにプロビジョニング解除されます。
Dick Hardt: これは企業における大きなセキュリティ課題の1つです。人々は個人アカウントを使いたがります。そのため、どのアカウントを外せばよいのか本当には分かりません。退職時には、その人を GitHub から外すことを覚えておかなければなりません。GitHub offboarding はそれを自動化します。
Dick Hardt: 次に B2C に移ります。選択肢はたくさんあります。パスワード、magic link、social login、passkey、そしてオンライン上で自分が誰であるかを証明する B2C identity です。
Dick Hardt: 米国には mobile driver’s license がありますが、実際の利用はほとんどありません。各州がそれぞれ独自のやり方を持っています。EU では、利用頻度は高くありません。この点で EU は米国より優に10年は進んでいますが、法域ごとに違います。それぞれの法域が独自の仕組みを導入しています。
Dick Hardt: eIDAS がそれらすべてを解決するという期待がありますが、私は違う見方をしています。identity 標準が増えていく流れを見ると、EU では人々がログインできる方法がさらに1つ増えるだけだと思います。ドイツの人たちは eIDAS にとても期待しています。なぜなら、うまく機能するものがないからです。だからドイツではそれが起きるでしょう。しかし France や、私がつい最近まで住んでいた Portugal では、すでに広く導入された仕組みがあります。なぜそれを変えるのでしょうか。
Dick Hardt: では、未来としての digital wallet はどうでしょうか。普及には多くの課題があります。credential 標準にはさまざまな違いがあります。ウェブサイトからオンラインで呼び出す方法も解決されていません。ウェブページから「この人について知りたい」と簡単に言える方法がないのです。
Dick Hardt: そしてもちろん、EU は Apple Wallet や Google Wallet を懸念しています。それらはプラットフォームに組み込まれ、利用可能になるからです。そのため競合する wallet があります。開発者にとっては、「どうやって wallet から何かを取り出せばよいのか」を理解するのが非常に難しくなります。ですから私は、近いうちに広く普及するとは思っていません。
Dick Hardt: passkey はどうでしょうか。多くの意味で、passkey はログイン方法がもう1つ増えたにすぎません。利用者体験には多くの引っかかりがあります。ウェブサイト側からは、「この人はすでに登録済みなのかどうか」が分かりません。そのため、余分な登録が発生しがちです。
Dick Hardt: Apple は passkey をパスワードに近づけようとして、同期することにしました。その結果、デバイスに結び付くのではなく、keychain に結び付くようになりました。攻撃者が keychain にアクセスできれば、すべての passkey にアクセスできてしまいます。また、登録の問題も解決していません。そこを解決しようとはしていますが。ですから私は、passkey はパスワードや social login と共存し、さらに分断を生むものになると思っています。
Dick Hardt: 皆さんはおそらく、ここに来るときに API Days のウェブサイトでログインしたと思います。ログインのためにメールアドレスを入力しました。magic link のようなものですが、これは OTP でした。クリックすると、理想的には自動入力が出てきます。登録に使ったメールアドレスを選び、それを入力します。すると「メールボックスを確認してください」と表示されます。そこでメールアプリに切り替え、コードを取得します。そのコードはコピーできるかもしれないし、できないかもしれません。そしてアプリに戻って貼り付けると、ログインできます。
Dick Hardt: 私は Chrome の同僚たちと EVP、Email Verification Protocol という新しいものに取り組んでいます。これは魔法のような体験を提供します。同じページに行き、クリックします。自動補完と自動入力が表示されます。使いたいメールアドレスを選ぶと、それだけでログインできます。本当にそういう動きです。今は Hello で動いていますし、Chrome でもいくつかのフラグの背後で入っています。試したい方がいれば、LinkedIn に投稿する予定です。自分で試して設定できるようにするつもりです。将来のメール確認において、良い変化になると思います。
Dick Hardt: 写真を撮らなくても大丈夫です。最後に QR コードを出します。
Dick Hardt: social login はどうでしょうか。ログインと登録ができます。これは最も優れたアカウント保護です。大手提供者には、異常検知に取り組む技術者が何十人もいます。どのようにログインするかのパターンを作り、悪意ある人たちがアカウントをどう攻撃するかのパターンを作っています。これは、ほぼどのサイトよりもはるかに優れています。そして、ウェブでもモバイルでもうまく機能します。
Dick Hardt: 課題は、人々が特にここ Europe では、大手テック企業によるプライバシーや囲い込みを懸念していることです。Hello がそれを解決しようとしている方法の1つは、すべての提供者とすべてのアプリの間に入る交換基盤、プライバシーの層、抽象化の層になることです。アプリは Hello に接続するだけで、ユーザーは好きなログイン方法を選べます。残念ながら、EU 発の良い提供者はまだあまりありません。いつかそこを変えられればと思っています。
Dick Hardt: 次は Agent Identity です。大企業にいるなら、mutual TLS、SPIFFE、あるいは何らかの workload identity を使って自前で作るかもしれません。各プラットフォームは、Agent Identity をどう管理するかについて、それぞれ独自仕様を展開しています。
Dick Hardt: MCP は OAuth 2.1 と dynamic client registration を選びました。そして今は client metadata という方法があります。agent-to-agent は CIBA を推しています。これは、agent がユーザーに対して何かを確認し、承認してもらうためのリクエストを送れる仕組みです。Okta を使っていれば、おそらくうまく機能するでしょう。そして、Web Bot Auth という新しい IETF 作業部会があります。そこでは HTTP Message Signatures を使っています。私は、これらはいくつもありますが、すべて関連していると見ています。
Dick Hardt: また、client、server、agent、MCP server の動き方は非常に違うとも思っています。一般的な client が API を呼ぶ場合、その client は1つまたは複数の特定の API を呼ぶために書かれています。事前に分かっていました。静的で、あらかじめ設定されていました。
Dick Hardt: agent の場合は、任意の MCP server を渡すことができます。agent はそれを理解します。先ほど、agent が呼び出し方を理解しやすい良い MCP server をどう書くか、という話もありました。しかし、それは実行時に起こります。そして、呼び出している agent が誰なのかを必ずしも事前には知りません。
Dick Hardt: そのため、私たちがリソースをどのように保護するかについて持っていた多くの前提は、もはや成り立ちません。
Dick Hardt: 私が最近オンラインで述べた、やや議論を呼ぶ主張の1つは、OAuth 2.0 は MCP にあまり適していない、というものです。事前登録ができません。公開インターネット上では、dynamic client registration を好む人はいません。それが使われてきた唯一の場所は、企業内でした。
Dick Hardt: モデルとしては、agent が「私はこういう者です」と言います。しかし、それが本当にその特定のサーバーであると、どうやって分かるのでしょうか。URL を示す client metadata があっても、それは「これが私の URL です」と言っているだけです。ほかの agent も「それは私の URL です」と言えてしまいます。
Dick Hardt: 従来の OAuth では、resource と authorization server は常に強く結び付いていました。resource server は、authorization server が持つ scope を知っていました。この特定の scope はこういう意味だ、ということが分かっていました。この新しい世界では、それが崩れ始めます。OAuth は、動的な client と resource の関係のためには設計されていませんでした。
Dick Hardt: agent には identity が必要です。そして delegation も必要だと思います。呼び出しを行っているのが agent のどのインスタンスなのかを知りたいのです。単に Anthropic だとか ChatGPT だとか分かるだけでは足りません。公開され、注意深く扱われ、検証可能な identity が必要です。すべてが企業内にあるわけではないからです。インターネットのどこか別の場所から、あなたの MCP server にサービスが呼び出してくることがあります。そのため、URL のようなものが必要です。私たちはもはや共有秘密を望んでいません。署名によって示す proof-of-possession 型の認証が欲しいのです。署名していれば、相手側はその URL に戻って鍵を取得し、あなたがその identity であることを確認できます。あなたが署名したからです。
Dick Hardt: そして、独立した委任先が必要です。スライドにある小さな子どもたち、私の小さな赤ちゃんロボットたち、それぞれが自分の鍵を持っている必要があります。
Dick Hardt: agent についてもう1つ言えるのは、連鎖させたり、異なる層を持たせたりする必要性を強く生んでいることです。agent が MCP server を呼び、その MCP server が resource を呼ぶ、という形です。関係者が2者だけということは、ほとんどありません。では、下流の authorization をどう得るのでしょうか。
Dick Hardt: また、下流で人間を処理に入れ、何かを承認してもらう必要があるかもしれない、という課題もあります。agent が「2万ドル分の航空券を買いたい」と言い出したとします。MCP server は、「agent にそれを許す前に、ユーザーが本当にそれを望んでいることを確認したい」と言います。どうやってユーザーを処理に入れるのでしょうか。こうしたサービスを連鎖させ始めると、access control と監査は非常に複雑になります。
Dick Hardt: Agent Auth、AAuth 提案というものがあります。これは私が最近書いた提案です。公の場で話すのは、これが最初に近い機会です。知っている人たち何人か、そして agent auth の課題を解こうとしている複数の企業に回覧し、多くの良い意見をもらいました。
Dick Hardt: agent ID は URL です。すべてが HTTP Message Signatures を使います。agent についてどれくらい分かっているかには段階があります。単なる素の鍵だけである anonymous から、identified、authorized、そして authorized by a user までです。ユーザーとのやり取りは連鎖全体を上に伝わることができます。また、ユーザーを処理に入れる必要がなければ、どの resource も独立して自律的に自分のトークンを取得できます。
Dick Hardt: これは framework である OAuth とは違い、protocol です。そのため、本来の動きに適合しているかどうかを試験できます。また、人々は access token と ID token をいつも混同するので、私は単に auth token と呼ぶことにしています。それは両方の役割を果たせます。
Dick Hardt: では、B2B identity の未来はどうなるのでしょうか。IPSIE によって、やらかしを減らせることを期待しています。そして OPC によって、人々が account lifecycle をずっと簡単に行えるようになり、それが Fortune 5000 だけのものではなくなることを期待しています。
Dick Hardt: passkey がパスワードを置き換えるとは思いません。passkey はログイン方法がもう1つ増えるだけです。mobile digital wallet が一般的に使われるようになるとも思いません。eIDAS がすべてを支配する標準になるとも思いません。EVP によってメール確認が簡単になることを期待しています。そして Hello の交換基盤が、ユーザーにログイン方法の選択肢を増やす手段になることを期待しています。
Dick Hardt: Agent Identity については、agent が server を呼び出すというのは、これまで存在しなかった本当に新しいモデルです。OAuth 2.0 は適していないと思います。必要なのは auth であって、AuthN だけでも AuthZ だけでもありません。Agent Auth は、その答えの1つになるかもしれません。
Dick Hardt: そこに座っている Lynn Sun が、今日の4時半から MCP と auth について、より深い話をします。ぜひ聞いてみてください。では、質問を受け付けます。LinkedIn で私をフォローしたい方は、そのための QR コードがあります。そこに投稿していく予定です。以前ほど Twitter に投稿するのが好きではなくなったので、LinkedIn に投稿しています。
Dick Hardt: ありがとうございました。
Unknown Speaker: ありがとうございます。質問はありますか。どうぞ。みんな全部理解したんですか。本当に。あ、そこに1人いますね。はい。マイクを回します。
Audience Member: 難しい質問です。いや、少し難しめの質問かもしれません。もし今、新しい API を作っていて、過去のしがらみが何もないとしたら、agent が私のサービスを使えて、サービスが人気になるようにするには、authentication をどう考えればよいでしょうか。
Dick Hardt: B2B SaaS の未来は、ウェブ画面ではなく agent 向けのインターフェースを作ることになると思います。それをどう行うかは、まだ決まっていません。agent 向けインターフェースの正しい設計パターンが何なのか、私たちはまだ分かっていないと思います。MCP はまだ1年しか経っていません。プロトコルはバージョン3か4くらいだったと思います。
Dick Hardt: 単なる普通の API であれば、既存の OAuth の枠組みは authorization に問題なく使えます。
Audience Member: 分かりました。ありがとうございます。
Unknown Speaker: ほかに質問はありますか。1つありますね。
Audience Member: 発表を聞きました。とても良かったです。質問したいのですが、Hello はウェブサイト上で identity を扱う新しい方法なのでしょうか。それとも中央集権化のようなものなのでしょうか。質問が伝わっているか分かりませんが。
Dick Hardt: そうです。Hello はサイト上で ID を扱う新しい方法です。そうですね。Hello は、さまざまなログイン方法とアプリの間に入る交換基盤として機能します。私たちは、identity における Visa のようなものだと考えています。
Dick Hardt: Visa の前は、各店舗と関係を持つ必要がありました。各店舗から信用を得ていました。店舗で現金を払うか、その店舗ごとに信用を得る必要がありました。信用取引があれば、毎月それぞれの店舗に行かなければならず、それぞれの店舗が回収しに来なければなりませんでした。
Dick Hardt: Visa は交換基盤になりました。Visa を受け付けるところならどこでも Visa を使えるようになりました。銀行から得た信用を再利用し、ほかの場所でもすぐに信用を使えるようになったのです。
Dick Hardt: 私たちは Hello を、そのような交換基盤だと見ています。アプリを作っているなら、Hello に接続できます。私たちは、そのユーザーが誰なのかを判断します。それが B2C であっても B2B であってもです。
Dick Hardt: たとえば B2B アプリを作っているとします。それぞれの企業に対して federation を設定するのは、毎回大きな負担です。Hello なら、Hello に接続すれば終わりです。そして私たちが企業側に接続し、企業側もそれで終わりです。
Dick Hardt: これは DNS のような中央サービスです。そのため Hello 自体は協同組合によって管理されるようにしています。また、内部には技術的な工夫があり、私たちがデータを見ることはできません。どの政府も私たちのところに来てデータを見ることはできません。中央サービスに必要な、適切なプライバシー、制御、統治をかなり提供できると考えています。
Dick Hardt: 宣伝として答えられる質問をしてくれて、ありがとうございます。
Unknown Speaker: ありがとうございます。ほかに質問はありますか。もう1つ。
Audience Member: 素晴らしい発表でした。それから、4時半の私の発表に触れていただきありがとうございます。Agent Auth について簡単に質問があります。Agent Identity は delegation を伴う URL だとおっしゃっていました。識別の標準としての SPIFFE についてはどう考えていますか。Agent Auth で使える可能性はあると思いますか。
Dick Hardt: SPIFFE は少し違う層にあります。SPIFFE は、workload が何かから identity を取得できるようにします。そして通常、それは企業内の閉じた信頼環境の中で使われます。
Dick Hardt: 設計上、Agent Auth では workload が agent server とやり取りし、その workload の SPIFFE key を agent server の identity に結び付ける token を取得できます。その agent server の identity は外部の identity です。そして、その workload はインターネット上のほかの場所へ呼び出しを行えます。呼び出し先は、その1つの workload がその agent server の委任先として動いていることを知ることができます。ですから、はい、両者は一緒に機能します。
Audience Member: agent を特別な workload と考えることもできるでしょうか。
Dick Hardt: 特別ではあります。ただ、どのくらい特別なのか、という話です。分かりません。あなたの発表を聞きに行きます。そうすれば、あなたがそれをどう特別だと考えているのか、何か学べるかもしれません。
Dick Hardt: Google、Microsoft、Amazon のような大規模なクラウド提供者は皆、agent は何らかの点で特別だと考えています。私も、より良く管理したいという点では特別だと思います。ただし、これまで workload における access control の管理について深く考えなくても済んでいた多くのことやパターンについて、今は考えざるを得なくなっています。本当は最初からやるべきだったことを、今になって workload 管理で行う必要が出てきているのかもしれません。
Dick Hardt: ですから、今存在している多くの技術は、以前よりも広く導入される必要があると思います。ありがとうございます。
Unknown Speaker: やった、もう1つ質問です。
Audience Member: MCP に OAuth を使うことについて話されていました。その問題は何なのか説明してもらえますか。単に実用上難しいということなのでしょうか。それとも、明らかに安全ではないということなのでしょうか。
Dick Hardt: 公開向けの OAuth server はすべて、client の事前登録を必要とします。そのため resource owner、たとえば Google、Apple、Flickr は、どの user がその app を所有しているかを知ることができます。これは静的に事前設定されたモデルで、client-server ではうまく機能していました。
Dick Hardt: agent モデルでは、agent は任意の MCP server を呼べるようにしたいのです。そのため、すべての agent がすべての resource に事前登録するのは現実的ではありません。client 登録を動的に管理したくなります。しかしその場合の課題は、resource 側が誰に呼ばれているのかを実質的に分からないことです。そのため、何らかの制御を行うのがずっと難しくなります。どの user が関与しているのかも分かりません。
Dick Hardt: そのため、MCP が MCP server を安全にする方法として OAuth 2.1 を指定しているにもかかわらず、実際に dynamic client registration を導入しているインターネット上の主要サービスを、私は1つしか知りません。ほとんどのところは、その仕組みを回避しています。私が Hello 用の MCP server を書いたときも、それを見て、DCR が想定するモデルを避けました。固定の agent を作り、いろいろなものをまとめて単純化し、起こり得る範囲を狭めました。開きっぱなしにしたくなかったからです。
Audience Member: 分かりました。ありがとうございます。
Unknown Speaker: ありがとうございます。ほかに質問がなければ、後ほど個別に話せると思います。あ、1つあります。残り30秒なので、本当に短い質問でお願いします。どうぞ。
Audience Member: ありがとうございます。そんなに短くはならないと思いますが、続きの質問です。私の理解する限り、MCP はそれほど動的ではありません。session を開く必要がありますし、agent に「この URL、この URL、この URL に接続したい」と伝える必要があります。危険なのは、最終的にたくさんの MCP server とたくさんの MCP client があり得ることだと思います。それでも、手動で行う部分はまだあります。その手動の部分で、role を使って「この URL にはこの role で接続する、この URL にはこの role で接続する」と言うことができます。ですから私には、今日 authentication をどう行うのかがあまり明確ではありません。曖昧だと思います。
Dick Hardt: 私は強く反対します。確かに agent は、自分が何に接続したいのか、その identity を知っています。そこは問題ではありません。問題は、接続される側が、誰に呼ばれているのかという identity を知らないことです。なぜなら、すべての agent が、それらの resource を管理している authorization server に事前登録されているわけではないからです。
Dick Hardt: そこで MCP spec では、「dynamic client registration を支えよう」と言っています。しかし、公開インターネット上では誰も dynamic client registration を支えていません。これまで使われてきた唯一の場所は、管理された環境である企業内です。
Dick Hardt: 次に出ている提案は client metadata を使うことです。そこには URL があり、それが agent の identity かもしれないという感触を少し与えます。しかし、その agent が本当にその特定の identity であることを証明する仕組みはありません。解決可能な識別子があるだけです。
Dick Hardt: ですから問題は、MCP server の URL そのものではありません。そこはうまく機能します。よければ、このあともっと詳しく話しましょう。