アクセストークンを使用したAPIの設計、GETリクエストの処理方法
さまざまな部門間の使用状況を追跡したり、アクセス制御を行うために、アクセストークンを利用するAPIを構築しています。私の計画は、HTTP動詞を適切に利用することです。GETは情報を取得し、POSTは追加し、DELETEは削除します。
私の質問は、GET呼び出しでアクセストークンをどのように処理する必要があるかです。
オプション1：
クエリ文字列の一部としてアクセストークンを提供することです：/api/users/?token=ACCESSTOKEN。これで私が抱えている問題は、ACCESSTOKENがサーバーログに表示されることです。このメソッドは、本文を介してトークンが渡されるPOSTまたはDELETEリクエストとも異なります。
オプション2：
（POSTリクエストで行うように）リクエストに本文を指定します。パラメータの1つはトークンです。ここでの問題は、社内の他の開発者が、データを渡すため、これは「真のGETリクエスト」ではないと言っていることです。彼らが呼び出すURLは単純に次のようになります/api/users/とtoken=ACCESSTOKEN本体内。
オプション3：
GETを使用してドロップし、すべてをPOSTに強制します。これらのAPI呼び出しの多くでは、新しいリソースを作成していないので、このアイデアは好きではありません。私は単に、承認が必要なAPIの背後にあるデータを返すだけです。
私が見当たらない、または調整する必要があるオプションはありますか？私はオプション2が好きですが、他の部門の開発者の懸念に敏感です。
オプション4：承認ヘッダーとRFC 6750（ベアラートークン）
お探しのソリューションはすでにOAuth2標準の一部として指定されていますが、それ自体が単独であり、シナリオに役立ちます。
https://tools.ietf.org/html/rfc675
クライアントからのすべてのリクエストは無記名トークン（アクセストークン）で渡され、サーバーへの他のリクエストヘッダーのように見えます。リクエスト自体は次のようになります。
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM
これは広く実装されているパブリック標準であるため、動作の定義について心配する必要はありません。クライアント側の開発者にRFCを指示するだけです。残りの OAuth2標準 をリソースサーバーと認証サーバーの両方として実装することも検討できますが、これはかなり手間がかかります。
リクエストヘッダーを使用しないのはなぜですか？これにより、認証/承認データがリクエストの実際の意味のあるデータから分離され、あらゆるタイプのリクエストに使用できます（getでリクエストボディを使用することは、通常、行うべきではありません）。
ヘッダーに承認があると、リクエストの本文を解析する前にユーザーを認証できます。これは、システムが権限のないユーザーからのデータの解析に時間を浪費したくない場合に有利です。