WorkOS、OAuth標準に基づくオープンエージェント登録プロトコル「auth.md」を公開

長年にわたり、Web認証は1つの設計前提に従ってきました。人間がブラウザの前に座り、ボタンをクリックし、フォームに記入し、メールを確認し、APIキーをコピーして別の場所に貼り付けるというものです。しかし、ユーザーがエージェントに作業を委任する場合、このモデルは機能しません。エージェントはすでにコードを書き、プルリクエストを開き、チケットをトリアージし、システムに問い合わせ、レコードを更新していますが、ほとんどの製品にはエージェントが登録するための構造化された方法がまだありません。現在の回避策——エージェントに生のAPIキーやセッショントークンを与えること——は、スコープがなく、セッションごとの監査が難しく、選択的に失効させることができない資格情報を生み出します。WorkOSは構造化された代替案を提案しています。それがauth.md、オープンなエージェント登録プロトコルです。

auth.mdとは何か？ auth.mdは、アプリケーションが既知の場所（通常はhttps://service.com/auth.md）に公開する小さなMarkdownファイルです。このファイルは、エージェントにそのサービスへの登録方法を伝えます。サポートされているフロー、存在するスコープ、資格情報の発行、監査、失効の方法などです。プレーンテキストのMarkdownであるため、同じファイルが人間の開発者向けのドキュメントとしても、エージェントがプログラムで読み取るランタイム成果物としても機能します。エージェントはファイルを取得し、構造化されたセクションを読み、適切なフローを選択し、登録します。人間がフォームに記入する必要はありません。

検出は2段階で行われます。機械可読な情報源は/.well-known/oauth-protected-resource (Protected Resource Metadata, PRM) にあり、リソースを宣伝し、認可サーバーを指します。/.well-known/oauth-authorization-serverにある認可サーバーメタデータは、agent_authブロック——サポートされるフロー、register_uri、claim_uri、revocation_uri、identity_types_supportedの値をエージェントに伝える構造化オブジェクト——を保持します。auth.mdファイルは、エージェントをこの検出パスに導く散文形式のコンパニオンです。APIからの401応答ごとに、サービスはWWW-Authenticate: Bearer resource_metadata="..."ヘッダーを返すべきであり、エージェントはドキュメントを読むことなく検出をブートストラップできます。

2つの登録フロー auth.mdは2つの主要なフローを定義します。アプリケーションはどちらか一方または両方をサポートできます。

エージェント確認フロー：エージェントのアイデンティティプロバイダー（OpenAI、Anthropic、Cursor、または任意の信頼できるプラットフォーム）が登録時にユーザーの身元を証明します。エージェントはプロバイダーからオーディエンス固有のID-JAGを要求し、それをアプリの/agent/authエンドポイントにPOSTします。アプリはID-JAGヘッダーをデコードしてkidとalgを取得し、信頼するプロバイダーのリストから発行者を検索し、プロバイダーのJWKSを取得し、署名を検証し、クレーム（aud、exp、iat、jti、client_id）を検証し、同期的に資格情報を返します。OTPもメールの往復も人間の操作も必要ありません。結果は(iss, sub, aud)ごとの委任レコードであり、プロバイダーはいつでもサービスのrevocation_uriにログアウトトークンをPOSTすることで失効させることができます。すでにOIDCまたはSAMLからユーザーをJITプロビジョニングしているアプリは、このパターンを認識するでしょう。異なる発行者を持つ同じ形状です。重要な制約：ID-JAG検証から発行されたアクセストークンにはリフレッシュトークンを含めてはなりません。エージェントはアクセスを延長するために新しいID-JAGを提示する必要があります。

ユーザークレームフロー：これはOTPベースのパスであり、エージェントプロバイダーの参加を必要としません。エージェントはアプリに登録し、ユーザーはメールから受け取ったワンタイムコードをエージェントに読み戻すことで登録をバインドします。2つのクレームエンドポイントは/agent/auth/claim（OTPメールをトリガー）と/agent/auth/claim/complete（コードを送信）です。このフローには2つの開始形状があります。匿名開始バリアントでは、エージェントは身元を明かさずに自己登録し、即座に資格情報を受け取り、アプリが定義する事前クレーム権限にスコープされます。登録が期限切れになる前の任意の時点で、エージェントはOTP儀式を実行して資格情報を実際のユーザーにバインドし、スコープをアップグレードします。APIキーはクレーム時にローテーションされず、スコープがその場でアップグレードされます。メール必須バリアントでは、エージェントは登録時にユーザーのメールを提供します。資格情報はOTP儀式が完了するまで完全に保留されます。事前クレームの使用が許容されない場合にこれを使用します。

ユーザーマッチングと監査 資格情報が発行されると、サービスは登録を既存のユーザーにマッチングするか、新しいユーザーをプロビジョニングする必要があります。推奨される解決順序は以下の通りです。まず、同じ(iss, sub)ペアの以前の委任レコードにマッチングします。次に、確認済みメールにマッチングします。最後に、アプリのポリシーに従ってJITプロビジョニングするか、手動オンボーディングが必要な場合は拒否します。観測可能性とインシデント対応のために、一連の標準監査イベントを記録することを推奨します：registration.created、claim.requested、otp.generated、claim.confirmed、registration.expired、registration.revoked。ID-JAGフローの場合は、iss、sub、agent_platformを含め、オペレーターがプロバイダー側のログと相関できるようにします。

（原文のビジュアル解説部分は図解が中心であるため、ここでは重要な情報をテキストで保持するように再構成しました。）

重要なポイント auth.mdはオープンプロトコルです。アプリはservice.com/auth.mdにMarkdownファイルをホストし、エージェントがどのように登録し、スコープ付き資格情報を取得するかを記述します。2つのフローをサポートします。エージェント確認（ID-JAGベース、同期、人間の操作なし）とユーザークレーム（OTPベース、プロバイダー統合不要）です。検出は2段階：PRMが認可サーバーを指し、そのメタデータにagent_authブロックが含まれます。このプロトコルは既存のOAuth標準（RFC 9728、ID-JAG）を再利用し、WorkOSインフラに依存しません。

詳細はリポジトリと技術文書を参照してください。