6

RESTful API を認証するためのさまざまなソリューションに関するさまざまな投稿を見てきましたが、この現在のシナリオを考えると、いくつか質問があります。

私のソフトウェア サービス (私たちは B2B 企業です) のクライアントがプログラムでリソースにアクセスできるようにする REST 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. ここに示されているように、HTTP 認証ヘッダーに値を指定します。#1とほぼ同じ？(ブラウザーに URL を貼り付けることはできませんが) 人々はこれらのヘッダーをもう使用していますか?

  3. OAuth 2 を使用します (これについてはまだ少しわかりません)。OAuth 2 は実際にクライアントをログイン ユーザーとして認証しますか? そして、それは REST API がステートレスであるという精神に反するのではないでしょうか? 私は OAuth が私にとって適切な解決策であることを望んでいました (それは公的な標準であるため) が、少し読んだ後ではよくわかりません。REST API 呼び出しには過剰または不適切ですか?

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

不明な点がありましたら、追加の詳細を投稿していただければ幸いです。

4

1 に答える 1

2

API を準備する必要があると思われる 2 種類のクライアントがあります。

  • 信頼できるクライアント - あなたが作成したものです。彼らは実際のユーザーのユーザー名とパスワードを持つことができ、おそらくHTTP認証ヘッダーで、すべてのリクエストでそのデータをサーバーに送信できます。必要なのは、暗号化された接続だけです。

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

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

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

于 2013-12-01T15:30:32.130 に答える