auth.md — エージェントがユーザーの代わりに登録するためのオープンプロトコル

 (workos.com)
6 ポイント 投稿者 xguru 5 시간 전 | 2件のコメント | WhatsAppで共有
  • 各サービスが自分のドメインルートでホストする auth.md ファイル標準
  • エージェントにユーザーの代わりに登録する方法を伝えることで、別個の会員登録フォームなしでエージェントがユーザーを登録可能
  • ファイルにはサポートする flow、存在する scope、サービス登録方法が含まれる
  • 3つの主体で構成
    • agent: ユーザーの代わりに動作する主体
    • agent provider: 身元アサーション ID-JAG を発行する IdP
    • service: アサーションを受け入れて認証情報を発行する主体
  • エージェントは auth.md を取得してサポートされる flow を選び、verified identity assertion を提示するか、またはユーザー向けの コード確認 claim を実行
  • 登録方式はマーケティング上は2種類として紹介されるが、実装上は anonymous を含む 3種類
    • Agent verified: エージェントの IdP がユーザーを保証し、人の介入は不要
    • User claimed: provider は不要で、エージェントが表示したコードをユーザーがログイン後に確認。RFC 8628 スタイルの claim ceremony（デバイスフロー方式）を使用
    • Anonymous Registration: エージェントが最初に pre-claim scope で動作し、その後ユーザーが所有権を主張すると post-claim トークン に昇格
    • 多くのアプリは両方式をサポートし、エージェントが状況に応じて選択
  • エージェントにはユーザーに紐づく scoped access token を発行し、寿命は短く失効可能
  • 標準 OAuth 上で発行されるため、既存の API 認証をそのまま再利用可能
    • ID-JAG 発行 → RFC 7523 JWT-bearer grant で access_token に交換、/.well-known/oauth-authorization-server ディスカバリーで動作
  • WorkOS が作成しているが、WorkOS インフラに依存しないオープンプロトコル
    • 既存の OAuth 標準（Protected Resource Metadata、ID-JAG）を組み合わせ、アカウントなしで公開・読み取り可能
  • アプリ/サービスは、どの flow を受け入れ、どの認証情報を発行するかを 直接制御 可能
  • 仕様だけでなく、agent provider・service の両側のサンプル実装 と、skill manifest の役割を果たす AUTH.md ファイル も提供されており、実際に動かして試せる
  • Cloudflare、Firecrawl、Resend、monday.com など複数のサービスがすでに導入済み
  • MIT ライセンス

関連記事

2件のコメント

 
bichi 2 시간 전

これはなぜ AUTH.md ではないのだろう？
 
laeyoung 3 시간 전

Firecrawl や Resend の auth.md。

Cloudflare はプロトコル紹介ページの最初の適用事例として出ていますが、クリックして入ってみると not found :( と表示されますね。