web-dev-qa-db-ja.com

OAuth2のアーキテクチャ-BackendServer-FrontendServer

OAuth2プロバイダー、バックエンドサーバー、フロントエンドサーバーでエコシステム全体を開発しています。

  • OAuth2プロバイダー：ユーザーの認証/承認とその他のいくつかの汎用サービスのみを提供します。
  • バックエンドサーバー：特定のコンテキストのすべてのロジックとモデルを実装し、OAuth2クライアントです。プロバイダーに登録されており、そのAPIを使用するすべての権利を持っています。
  • フロントエンドサーバー：インターネット上でWeb GUIを公開し、バックエンドサーバーからすべてのデータを取得します。

現在、OAuthプロセスは適切に機能しており、認証後、バックエンドサーバーはプロバイダーからユーザーデータを取得できます。

しかし、フロントエンドとバックエンドから分離しておく必要があるので、フロントエンドからのみアクセス可能なRESTful APIサービスを提供します。私の問題は、これを正しく安全な方法で行う方法です。

OAuthプロバイダーセッションを使用してフロントエンドでユーザーを認証し、データにアクセスさせようとしているときに問題が発生しました。

これはいくつかの要件です：

  • フロントエンドは、バックエンドAPIを介してOAuth2ユーザーデータにアクセスする必要があります。
  • フロントエンドとバックエンドは異なるサーバー上にある必要があり、異なるホスト上にある可能性があります。
  • 将来的には、OAuthサービスを使用するサーバーをさらに紹介します。

このニーズに最適なアーキテクチャは何ですか？

更新2016年12月10日

HTTPSの部分は明確です。私は確かにそれを使用します。

OAuth2フローは知っていますが、あなたの例が私のニーズに合っているかどうかはわかりません。実際のユースケースの非常にシンプルなフローを次に示します。ユーザーがすでにログインしていて、「バックエンドサーバー」をすでに承認していると仮定します（C）。 enter image description here HTMLプロフィールページBへのリクエスト、BはREST APIを使用してCからAの情報を取得する必要があります。CはOAuthクライアント、データを読み取るには、Aから承認を受ける必要があります。そのため、CはD（OAuthプロバイダー）に情報を要求します。すべてのデータがBに返され、htmlプロファイルページが生成されます。 。

私の大きな疑問（およびこの質問の理由）は次のとおりです。Cは、要求を管理する前に、認証されたユーザーとのセッションがアクティブかどうかを確認するRoRサーバーです。しかし、リクエストがサーバーからのものである場合、リクエストにはセッションがなく、BがヘッダーをCに移動しても、Cがエラーで応答すると、セッションが「クリア」であることがわかります。

私の疑いは、B-C通信を処理する正しい方法が欠けていることです。

web-servicesclient-serveroauth2
1
RikyTres

まず、** HTTPS **が必要です。

HTTPS = HTTP + SSL/TLS.

HTTPの上にセキュリティレイヤーを作成し、多くの攻撃を防ぎます。その層が機能するためには、証明書の形式で資格情報を送信および受信する必要があります。 HTTPSを参照

HTTPSは、一方向または双方向で構成できます。

一方向：一方向のシナリオでは、サーバー証明書をクライアントに送信するだけです。それを確認し、問題がなければ、すぐにコミュニケーションを開始します。

One-Way SSL

双方向：これは一方向の後に発生しますが、クライアントは自分の証明書をサーバーに送信して、確認できるようにします。証明書を信頼すると応答した場合にのみ、通信が開始されます。

Two-Way SSL

これは、サーバーで行う構成です。アプリケーション/ APIは、サーバーでHTTPSを使用して情報を送受信します。

次に、すべてのステップを含むOAuth2の完全なフローを示します。

OAuth2 flux complete

上の画像では：

  • User：ホスト（エンドユーザーまたはサーバー）は、アプリケーションサーバーでユーザーに何かを要求しています。
  • Client：認証サーバーに接続されているアプリケーションサーバーです。
  • Auth Server：サーバーOAuth Authentication Server is running。
  • Resource Server：ユーザーの情報へのアクセスに使用されるAPIサーバーです。

このフローが完了すると、「ユーザー」が認証され、トークンを取得します。 「ユーザー」とは、アプリケーションのユーザーまたはのAPIを意味します。

「ユーザー」は、トークンの有効期限が切れるまで、すべてのリクエストでトークンを使用します。

あなたの場合、

Rest APIは、HTTPリクエストのAuthorizationヘッダーでトークンを受け取ります rfc scpec link セクション14.8Authorization。

Authorization: Bearer mF_9.B5f-4.1JqM <- (token is here)

次に、OAuthサーバーでトークンを確認して、トークンを検証する必要があります。

これは、上の画像のクライアントとリソースサーバー間の最後のリクエストで発生しています。

GET /resource(access_toke)
200: response <- (token is valid)

トークンが有効な場合は、リクエストされたリソースにアクセス権を付与できます。そうでない場合は、401（無許可）のhttpステータスコードを返すことでリクエストを拒否します stackOverflowに関するディスカッション を参照してください。

3番目に、サーバーをリプレイ攻撃から保護する必要があります。

securityExchangeに関するディスカッション を参照してください。

8
linuxunil