web-dev-qa-db-ja.com

REST API Securityに決定

APIを開発しました。私は混乱し、何日も記事を読んでいます。実際、私の質問はこれらに近いですが正確ではありません（多分それらの組み合わせ）。
セキュリティ保護RESTさまざまなクライアントからアクセスされるAPI
安全なログインなしRESTごく少数のクライアント用のAPI

APIに安全性を提供する必要があります。 APIは、クライアントのサードパーティアプリケーションで使用されます。以下のスキーマを添付しました。

私は何をすべきか？

SSL\TLSを使用したHTTP-Basic、SSL\TLSを使用したHTTP-Digest、OAuth 2.0またはその他の必要条件

schema

編集（2015-03-25）：
この部分はあきらめました。下記の「編集（2015-04-01）」をご覧ください

SSLを実装することにしました+ OAuth 2.0（ Resource Owner Password Credentials Grant ）。）。シナリオに都合が悪いと思われる場合は、お知らせください。

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      v
      |    Resource Owner
     (A) Password Credentials
      |
      v
 +---------+                                  +---------------+
 |         |>--(B)---- Resource Owner ------->|               |
 |         |         Password Credentials     | Authorization |
 | Client  |                                  |     Server    |
 |         |<--(C)---- Access Token ---------<|               |
 |         |    (w/ Optional Refresh Token)   |               |
 +---------+                                  +---------------+

        Figure 5: Resource Owner Password Credentials Flow

図5に示されているフローには、以下のステップが含まれています。

（A）リソース所有者は、クライアントにユーザー名とパスワードを提供します。

（B）クライアントは、リソース所有者から受け取った資格情報を含めることにより、認証サーバーのトークンエンドポイントにアクセストークンを要求します。要求を行うとき、クライアントは許可サーバーで認証します。

（C）許可サーバーはクライアントを認証し、リソース所有者の資格情報を検証し、有効な場合はアクセストークンを発行します。

編集（2015-04-01）：

私は OAuth 2.0クライアント資格情報 を実装しました。そして今、クライアントのAPIリクエストにSSL証明書を実装する方法を探しています。

クライアント資格情報付与タイプは、機密クライアントのみが使用する必要があります。

 +---------+                                  +---------------+
 |         |                                  |               |
 |         |>--(A)- Client Authentication --->| Authorization |
 | Client  |                                  |     Server    |
 |         |<--(B)---- Access Token ---------<|               |
 |         |                                  |               |
 +---------+                                  +---------------+

                 Figure 6: Client Credentials Flow

図6に示すフローには、以下のステップが含まれています。

（A）クライアントは承認サーバーで認証し、トークンエンドポイントにアクセストークンを要求します。

（B）許可サーバーはクライアントを認証し、有効な場合はアクセストークンを発行します。

tlsoauthrestauthorizationnode.js
6
efkan

あなたが概説しているオプションについて私が言うことは、SSLを使用したHTTP Authはより単純ですが柔軟性が低いオプションであり、Oauth2はより複雑ですが、それを使用して実現できることにおいてより柔軟性があります。

ASCIIアート図で説明したように、OAuth2を使用すると、リクエストの認証にパスワードの代わりに使用できるトークンを作成できます。これは、 HTTP Basic/Digestよりも有利です。つまり、ユーザーのパスワードをクライアントに保存する必要がなく、トークンを保存するだけで済みます。

したがって、一般的にOAuth2を適切に実装できる場合は、それでうまくいくと思います...

6
Rory McCune

OAuth 2.0トークンが危険にさらされている場合は、トークンのTTLを気にするだけで十分です。

HTTP基本認証ヘッダーが危険にさらされた場合、資格情報は期限切れになりません。 client_idとsecretを手動で変更する必要があります。それは、それらが危険にさらされていることを知っていたり、考えていたりする場合です。そして、これに対応するために毎回クライアントコードを変更する必要があるでしょう。

これら2つのオプションの主な違いは、OAuth 2.0トークンミンティングにはclient_idとシークレットが交換される1つの重要なステップが含まれることです。HTTPBasic Authでは、すべてのAPI呼び出しで同じ交換が行われます。

この観点から、OAuth 2.0ははるかに安全なオプションです。

5
akoo1010