リバースプロキシ認証サーバーは安全なセットアップでしょうか？
私は小規模なコンサルタント会社で働いており、クライアント向けのWebアプリを頻繁に作成しています。書くのにしばしば繰り返されるウェブアプリの一部は認証システムです。多くのWebアプリでは、さまざまなプロバイダーからのOAuthログインと、メールベースの登録をサポートしたいと考えています。
ただし、すべてのWebアプリケーションでこれをプログラミングするには時間がかかります。理想的には、アプリケーションサーバーの前に配置され、認証に関連するすべて（ログイン、登録、ログアウトなど）を処理する汎用の認証プロキシサーバーが理想的です。このようなものは安全でしょうか？または、このようにしてはならないセキュリティ関連の理由がある場合はどうなりますか？
私はそれが次のようになると想像しています：
認証サーバー
- これは基本的にリバースプロキシサーバーです。認証に関連する情報（電子メールアドレス、パスワードなど）を備えた独自のデータベースがあります。
- セッション情報を含む特定のCookieの各リクエストをチェックします（たとえば、
SESSIONというCookieのJWT）。このセッション情報は、ユーザーが過去のある時点で正しくログインしたことの証明になります。セッション情報が正しい場合は、X-UserIdヘッダーをリクエストに追加し、それをアプリケーションサーバーに転送します。認証情報を含むCookieがない場合、またはセッション情報が正しくない場合は、X-UserIdヘッダーなしでリクエストをアプリケーションサーバーに転送します。 - ログイン、ログアウト、および登録のための特定のルートがあります（たとえば、
/login、/logout、および/register）。これらのリクエストは完全に独自に処理します。アプリケーションサーバーは、これらの要求を認識しません。
アプリケーションサーバー
- これは通常のWebアプリケーションサーバーです。
- 認証サーバーからの
X-UserIdヘッダーに完全に依存して、認証を実行しません。 - 外部からはアクセスできません。これにアクセスする唯一の方法は、認証サーバーを経由することです。
- 独自のデータベースもあります。アプリケーションに関連するすべての情報が含まれています（認証情報を除く）。
次に、ログインがどのように機能するか、および認証サーバーとアプリケーションサーバー間の相互作用の例を示します。
login.htmlページを取得する手順は次のとおりです。
- クライアントは
/login.htmlのリクエストを送信します。 - 認証サーバーがリクエストを受信します。認証サーバーは
SESSIONというCookieを探します。存在しないため、X-UserIdヘッダーを追加せずにリクエストをアプリケーションサーバーに転送します。 - アプリケーションサーバーがリクエストを受信します。
/login.htmlに定義されたルートがあり、X-UserIdヘッダーが存在する必要がないため、login.htmlのHTMLを返します。 - 認証サーバーは応答を受信し、ユーザーに転送します。
login.htmlページには、実際にログインするためのJSコードを含めることができます。これを行う方法の1つを次に示します。
- クライアントは、AJAXリクエストを
/login/emailに送信して、メールアドレスとパスワードを使用してログインします。 - 認証サーバーがリクエストを受信します。これは認証サーバーに対する要求であるため、要求をアプリケーションサーバーに転送しません。
- 認証サーバーは、メール本文とパスワードのリクエスト本文を調べます。認証データベースでメールアドレスとパスワードをチェックします。
- 電子メールアドレスとパスワードが正しい場合、JWTを含む
HttpOnlyというSESSIONCookieが返されます。
これが成功した後、ユーザーは/home.htmlに誘導されます。この手順は/login.htmlに似ていますが、ユーザーが実際に認証される必要がある点が異なります。
- ユーザーが
/home.htmlにリクエストを送信します。 - 認証サーバーがリクエストを受信します。認証サーバーは
SESSIONCookieをチェックし、JWTをデコードします。認証サーバーは、JWTの情報に基づいてデータベースからユーザーIDを取得します。ユーザーIDが5であるとしましょう。 - 認証サーバーは
X-UserId=5ヘッダーをリクエストに追加し、それをアプリケーションサーバーに転送します。 （SESSIONCookieが存在しない場合、またはJWTを正常にデコードできない場合、認証サーバーはX-UserIdヘッダーを追加せずにリクエストをアプリケーションサーバーに転送します。次の手順は、認証が成功し、認証サーバーが `X-UserIdヘッダーを追加することを前提としています。） - アプリケーションサーバーがリクエストを受信します。リクエストは
/home.htmlに対するものであるため、アプリケーションサーバーは有効なユーザーIDが必要であることを認識しているため、X-UserIdヘッダーを確認します。 - アプリケーションサーバーは、
X-UserIdヘッダーからユーザーIDを正常に取得し、それを使用してアプリケーションDBからデータを引き出し、home.htmlページを作成します。 - アプリケーションサーバーは、
home.htmlページを含む応答を認証サーバーに送信します。 - 認証サーバーは応答を受信し、それをユーザーに転送します。
以下は、上記に当てはまらない追加情報です。
- Auth Serverは、リクエストをアプリケーションサーバーに転送する前にユーザーが送信した場合、
X-UserIdヘッダーを削除します。 - 認証サーバーは比較的一般的で、複数の異なるプロジェクトで使用できます。アプリケーションサーバーは、認証についてまったく心配する必要はありません。
- アプリケーションサーバーは承認を担当する必要があります（たとえば、各ユーザーが自分の情報しか編集できないようにするなど）。
- 認証サーバーは新しいユーザー登録を完全に処理します。これには、OAuthフロー（OAuthをGoogle、Twitter、Facebookなどから提供されたものを使用する場合）のほか、簡単なメールベースの登録が含まれます。新しいユーザーが登録すると、認証サーバーはユーザーIDを作成し、ユーザーのメールアドレス、Googleユーザー名、Twitterユーザー名などにリンクします。アプリケーションサーバーは、このユーザーIDのみを表示します（ユーザーのメールアドレス、Googleユーザー名、 Twitterユーザー名など）。
このような設定は安全ですか？
逆プロキシは、あなたが求めているものに対してかなり一般的です。かなりの数の企業がサーバーを参考に設計しており、それを参照として使用できます。
たとえば、私は会社でWebSeal（IBM ISAM）をかなり使用しました（私の周りに何らかの理由で人気があるようです）。それらには、OAuthおよびその他のほとんどのタイプの認証用にすでに構築されたモジュールがあります。
これらのサーバーを使用して、次のことができます。
- 異なるユーザーストアを持つ複数のシステムにわたって単一の「ID」を提供します。
- 必要な機能が不足している可能性のあるレガシーシステムでは、より安全な認証方法をユーザーに提供します（例：OAuth承認をユーザーに提供する一方で、プロキシは基本認証をバックエンド呼び出しに使用します）。 ）
- 単一のポイントを介して接続を強制することによってシステムを分離する
- これらすべての組み合わせ。
デザインノート：
- OAuthはAUTHORIZATIONプロトコルであり、AUTHENTICATIONプロトコルではありません。
- IDを確立する場合は、OpenID、JWT、SAMLを確認するか、所有しているIDプロバイダーとして実行します。
リクエストを承認する場合は、OAuth 2.0またはJWTをご覧ください。
IdentityにIDトークンを使用します（例：OpenID仕様、またはJWTの独自の外観をロールする場合）
Webアプリケーションで認証トークンを使用してアクセストークンを取得します。
アクセストークンを使用して、保護されたリソースを提供します。
これは素晴らしい設定です。
ネットワークとこのタイプのアクセスについて彼らがどのように考えているかについての詳細は、グーグルのビヨンドコープのドキュメントをご覧ください。
https://cloud.google.com/beyondcorp/
自分でロールしたい場合は、duoネットワークゲートウェイなどを使用できます。ただし、リバースプロキシの問題は、すべてのDNSがリバースプロキシの同じIPをポイントし、各リソースを手動で構成する必要があることです。
別のアプローチは、認証を必要とするPACファイルとフォワードプロキシの組み合わせです。次に、フォワードプロキシを介してすべてのURLを送信するように指定できます。フォワードプロキシは認証を実行し、トラフィックをどこにでもリソースに渡します。リソースは、送信元IPアドレスのみを許可するように構成できます。