クライアント側のREST API認証

Question

RESTful APIを認証するためのさまざまなソリューションに関するさまざまな記事がありますが、現在のシナリオではいくつか質問があります。

ソフトウェアサービス（私たちはB2B企業）のクライアントがプログラムでリソースにアクセスできるようにするREST APIを構築しました。 APIが正しく機能するようになったので、可能な限り標準化された方法でAPIを保護したいと思います。 APIの呼び出し元に基づいて特定のリソースへのアクセスを許可する必要があります。つまり、APIのすべてのユーザーがすべてのリソースにアクセスできるわけではありません。

私は次のフォーマットで利用できるのURLています

https://mydomain/api/students 
https://mydomain/api/students/s123 
https://mydomain/api/students/s123/classes 
https://mydomain/api/students/s123/classes/c456 

これまでのところ、私はこれらの可能な解決策を作ってみた：

1. は、彼らが使用できることを各クライアントに一意のキーを提供します各REST呼び出しの終了時にGETパラメータとして渡される暗号化されたトークンを最終的に生成して、すべての単一の要求を（再）認証します。このアプローチは

   https://mydomain.com/api/students/s123?token=abc123

2. あまりにも高価であるがhere見られるようにHTTP認証ヘッダの値を提供します。これは＃1とほとんど同じですか？ （URLをブラウザに貼り付けることはできないことを除いて）人々はこれらのヘッダーをもう使用していますか？

3. OAuth 2を使用します（これはまだわかりません）。 OAuth 2は実際にログインしたユーザとしてクライアントを認証しますか？ステートレスなREST APIの精神に逆らっていませんか？私はOAuthが私のための適切な解決策であることを望んでいましたが（それは公的な基準なので）、少し読んだら、私はそれほど確信していません。 REST APIコールが過剰であるか、不適切なのですか？

私の目標は、APIを消費したいクライアントごとに変更する必要はありませんが、むしろ私は、私たちのクライアントのすべてが利用できるように、標準的なドキュメントを提供できるというAPIを提供することです。

私が不明な点がある場合は、さらに詳しい情報を投稿していただきます。

Answer 1

あなたはおそらく、あなたのAPIを用意したいクライアントの2種類があります。

• 信頼できるクライアント - あなたによって書かれています。彼らは実際のユーザーのユーザー名とパスワードを持つことができ、HTTP認証ヘッダーの可能性があるすべての要求でサーバーにそのデータを送信することができます。必要なのは、暗号化された接続だけです。

• サードパーティのクライアント - ランダムな開発者が作成したものです。サービスに登録し、それぞれに一意のAPIキーを追加することができます。その後、ユーザーがサービスを利用する場合は、サードパーティのクライアントにアクセスを許可するプロンプトを表示する必要があります。その後、サードパーティのクライアントは、指定されたアクセス許可を持つユーザーのアカウントに割り当てられ、ユーザー固有のアクセストークンが取得されます。したがって、クライアントはAPIキーとユーザー固有のトークンを要求と共に送信すると、要求をユーザー名で送信します。

OAuthは、2番目の状況を制御するのに役立ちます。

あなたのURLはクライアントにとって意味を持ちません。 RESTによって、セマンティクス（例：リンク関係）で注釈が付けられたリンクを送信することによって、URL構造からクライアントを切り離す必要があります。したがって、ドキュメントにはURL構造に関する情報が含まれている必要はありません（サーバーサイドのデバッグには役立つかもしれませんが、それ以上のものはありません）。さまざまなタイプのリンクについて話をする必要があります。サーバー側でこれらのリンクを生成することで、実際のユーザー（または第三者のクライアント）のアクセス許可を確認し、そのアクセス許可がないリンクをスキップできます。