アクセストークンを使用した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/rfc6750

クライアントからのすべてのリクエストは、ベアラートークン（アクセストークン）で渡され、サーバーへの他のリクエストヘッダーのように見えます。リクエスト自体は次のようになります。

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

これは広く実装されているパブリック標準であるため、動作の定義について心配する必要はありません。クライアント側の開発者にRFCを指示するだけです。残りのOAuth2標準をリソースサーバーと承認サーバーの両方として実装することも検討できますが、これはかなり手間がかかります。

リクエストヘッダーを使用しないのはなぜですか？これにより、リクエストの実際の意味のあるデータから認証/承認データが分離され、あらゆるタイプのリクエストに使用できます（getでリクエストボディを使用することは、通常、行うべきではありません）。

ヘッダーに承認があると、リクエストの本文を解析する前にユーザーを認証できます。これは、システムが権限のないユーザーからのデータの解析に時間を浪費したくない場合に有利です。