3

2 つのノード サーバーがあります。1 つは Web サイトを提供し、もう 1 つは Web サイトの背後にあるデータを強化する RESTful API を提供します。

ユーザーが Web サイトにログインすると、セッションが作成されます。これにより、ユーザーがログインしているかどうかに応じて、正しい HTML をユーザーに提供できます。

私の API は、一部のエンドポイントのユーザーを識別して承認する必要もあります。ただし、API は (ログイン セッションが作成されたサーバーとは) 別のサーバーで提供されるため、そのセッション データを再利用することはできません。さらに、RESTful API を公開したいのですが、この方法でセッション データを再利用すると、それが妨げられる可能性があります。パブリックとは、長期的には、外部の開発者が API リクエストとやり取りして承認できるようにしたいという意味です。PUT一部のエンドポイントは (リソース上などで) 承認する必要がありますが、一部のエンドポイントUserはすべての人が自由に見ることができるようにする必要があります (パブリックGET、リソース上などUser)。

これは初めての RESTful API であり、この方法で認証を扱ったことはありません。これらの詳細を念頭に置いて、認証レイヤーをどのように正確に設計する必要がありますか?

私はセッション トークンと OAuth について非常に簡単に理解していますが、これらのいずれかを含むソリューションをお持ちの場合は、これらがどのように連携して認証レイヤーを作成するかについて詳しく説明していただければ幸いです。さまざまなテクニックを学ぶのに役立つリソースへのリンクもいただければ幸いです。

4

2 に答える 2

0

可能な限り、2 つの認証方法を別々にしておく必要があります。API へのほとんどの呼び出しはブラウザ経由ではなく、コードで HTTP クライアントのセッションを管理するのは非常に面倒です。ブラウザー経由の Web アプリの場合、セッション ベースのアプローチが適切です。

API の場合、認証を追加する一般的な方法が 2 つあります。SSL を介した HTTP 基本認証と OAuth 2です。あなたの状況では、特定のエンドポイントに対して選択的に有効化された単純な HTTP 基本認証 (必ず SSL を使用してください) のように思えますが、おそらく進むべき道です。ユーザーが通常の資格情報でログインできるようにすることもできます (ブラウザーはキャッシュを行い、Cookie を使用せずにセッションの残りの最初の認証が成功した後に自動的に送信します)。 Web サイトの各消費者。OAuth を使用しない一般的なパブリック API の多くは、このアプローチを採用しています (Twilio など)。

于 2013-06-17T06:07:46.930 に答える
0

Web サーバー A とデータサービス B を呼び出します。簡単なスキームは、秘密鍵を使用して A を B に登録することです。A から B への (https 経由の) リクエストには、API の「プライベート」機能のロックを解除するプライベート キーを含む認証ヘッダー ( http://en.wikipedia.org/wiki/HTTP_header ) を含めることができます。偽の秘密鍵なしで、または偽の秘密鍵で呼び出された場合、これらの関数は HTTP 403 Forbidden または何か ( http://en.wikipedia.org/wiki/HTTP_403 ) を返します。

于 2013-06-16T09:59:15.743 に答える