vouch proxy
1.0.0
auth_request モジュールを使用した Nginx 用の SSO ソリューション。 Vouch Proxy は、すべての Web サイトを一度に保護できます。
Vouch Proxy は多くの OAuth および OIDC ログイン プロバイダーをサポートしており、認証を強制的に行うことができます。
グーグル
GitHub
GitHub エンタープライズ
インディー認証
オクタ
スラック
ADFS
Azure AD
アリババ / アリユン iDaas
AWS コグニート
けいれん
不和
セキュア認証
ギテア
キークローク
PHP 用 OAuth2 サーバー ライブラリ
ホームアシスタント
OpenStax
オリー・ヒドラ
ネクストクラウド
他のほとんどの OpenID Connect (OIDC) プロバイダー
リストを更新できるように、優先 IdP またはライブラリを使用して Vouch Proxy をデプロイした場合は、ぜひお知らせください。
Vouch が Nginx リバース プロキシと同じホスト上で実行されている場合、 /validateエンドポイントから Nginx への応答時間は1ms 未満になるはずです。
保証プロキシの機能...
インストールと構成
「パス内」のプロキシを保証する
追加の Nginx 構成
環境変数による構成
ヒント、コツ、および高度な構成
範囲とクレーム
Dockerから実行する
Kubernetes Nginx Ingress
ソースからコンパイルしてバイナリを実行する
/login および /logout エンドポイント リダイレクト
トラブルシューティング、サポート、機能リクエスト (GitHub で問題を送信する前にこれをお読みください)
IdP (Google/Okta/GitHub/...) に戻る無限リダイレクト ループが発生します。
さて、問題を確認し、設定でいくつかのことを試しましたが、まだ機能しません
保証プロキシへの貢献
OpenRestyを使用した高度な認可
Google Oauthを利用したログインと認証の流れ
Vouch Proxy (VP) は、訪問者に Web サイトへのアクセスを許可する前に、IdP (上記のサービスの 1 つなど) にログインして認証することを強制します。
VP は、同じドメイン内のすべての Web アプリケーションを保護するシングル サインオン (SSO) ソリューションとしても使用できます。
訪問者がログインすると、Vouch Proxy により、保護された Web サイトへのアクセスが数時間許可されます。すべてのリクエストは VP によってチェックされ、有効であることが確認されます。
VP は、IdP が提供する訪問者の電子メール、名前、その他の情報 (アクセス トークンを含む) を HTTP ヘッダーとして Web アプリケーションに送信できます。 VP を使用すると、アプリケーションのユーザー管理を完全に置き換えることができます。
Vouch Proxy は、Vouch Proxy サーバーと保護対象のアプリケーションの間で Cookie を共有する機能に依存しています。通常、これは、 app1.yourdomain.comおよびapp2.yourdomain.comで実行されているアプリを使用して、 vouch.yourdomain.comなどのサブドメインで Vouch を実行することによって行われます。保護されたドメインは.yourdomain.comで、このドメインに Vouch プロキシ Cookie を設定するには、 vouch.domains を設定してyourdomain.comを含めるか、場合によっては vouch.cookie.domain をyourdomain.comに設定する必要があります。
cp ./config/config.yml_example_$OAUTH_PROVIDER ./config/config.yml
Google や github などで Vouch Proxy の OAuth 認証情報を作成します。
必ずコールバック URL を Vouch Proxy /authエンドポイントに送信してください。
Nginxを設定...
次の Nginx 構成は次のことを前提としています。
Nginx、 vouch.yourdomain.com 、 protectedapp.yourdomain.comが同じサーバー上で実行されている
どちらのドメインもhttpsとして提供され、有効な証明書があります (そうでない場合は、 listen 80に変更し、 vouch.cookie.secure をfalseに設定します)
サーバー { リッスン 443 ssl http2; サーバー名 protectedapp.yourdomain.com; ルート /var/www/html/; ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem; # 認可のためにすべてのリクエストを `/validate` エンドポイントに送信します auth_request /validate; location = /validate { # /validate リクエストを Vouch Proxy proxy_pass http://127.0.0.1:9090/validate に転送します。 # 元のホスト ヘッダーを必ず渡してください proxy_set_header Host $http_host; # Vouch Proxy はリクエスト ヘッダーにのみ作用します proxy_pass_request_body off; proxy_set_header Content-Length ""; # オプションで、要求 auth_request_set とともに Vouch Proxy によって返された X-Vouch-User を追加します $auth_resp_x_vouch_user $upstream_http_x_vouch_user; # 必要に応じて、追跡している X-Vouch-IdP-Claims-* カスタム クレームを追加します。 # auth_request_set $auth_resp_x_vouch_idp_claims_groups $upstream_http_x_vouch_idp_claims_groups; # auth_request_set $auth_resp_x_vouch_idp_claims_given_name $upstream_http_x_vouch_idp_claims_given_name; # 必要に応じて X-Vouch-IdP-AccessToken または X-Vouch-IdP-IdToken を追加します # auth_request_set $auth_resp_x_vouch_idp_accesstoken $upstream_http_x_vouch_idp_accesstoken; # auth_request_set $auth_resp_x_vouch_idp_idtoken $upstream_http_x_vouch_idp_idtoken; # これらの戻り値は @error401 呼び出しで使用されます auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt; auth_request_set $auth_resp_err $upstream_http_x_vouch_err; auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount; # Vouch Proxy は同じ Nginx リバース プロキシの背後で実行できます # 「アップストリーム」サーバーの命名に準拠する必要がある場合があります # proxy_pass http://vouch.yourdomain.com/validate; # proxy_set_header ホスト $http_host;
# validate が「401 not authors」を返した場合、リクエストを error401 ブロックに転送します error_page 401 = @error401; location @error401 { # ログイン用の Vouch Proxy にリダイレクト return 302 https://vouch.yourdomain.com/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$ auth_resp_err; # 通常は、https で保護された同じ Nginx 構成の背後で実行されている Vouch にリダイレクトしたいとします。 # しかし、最初は、vouch が実行されているポートにエンド ユーザーを転送するだけで済みます # return 302 http://vouch.yourdomain.com:9090/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$auth_resp_err;
} location / { # 承認されたリクエストをサービスに転送します protectedapp.yourdomain.com proxy_pass http://127.0.0.1:8080; # https://github.com/vouch/vouch-proxy/issues/26#issuecomment-425215810 に従って、このブロックでこれらの変数を設定する必要がある場合があります # auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user # auth_request_set $auth_resp_x_vouch_idp_claims_groups $upstream_http_x_vouch_idp_claims_groups; # auth_request_set $auth_resp_x_vouch_idp_claims_given_name $upstream_http_x_vouch_idp_claims_given_name; # ユーザーヘッダー (通常は電子メール) を設定します proxy_set_header X-Vouch-User $auth_resp_x_vouch_user; # オプションで追跡しているカスタム クレームを渡します # proxy_set_header X-Vouch-IdP-Claims-Groups $auth_resp_x_vouch_idp_claims_groups; # proxy_set_header X-Vouch-IdP-Claims-Given_Name $auth_resp_x_vouch_idp_claims_given_name; # オプションでアクセストークンまたは ID トークンを渡します # proxy_set_header X-Vouch-IdP-AccessToken $auth_resp_x_vouch_idp_accesstoken; # proxy_set_header X-Vouch-IdP-IdToken $auth_resp_x_vouch_idp_idtoken;
}
} Vouch が同じnginx リバースプロキシの背後に設定されている場合 (おそらく、SSL を設定できるように)、必ずHostヘッダーを適切に渡してください。そうしないと、JWT Cookie をドメインに設定できません。
サーバー { リッスン 443 ssl http2; サーバー名 vouch.yourdomain.com; ssl_certificate /etc/letsencrypt/live/vouch.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/vouch.yourdomain.com/privkey.pem; location / { proxy_pass http://127.0.0.1:9090; # 元のホスト ヘッダーを必ず渡してください proxy_set_header Host $http_host;
}
}v0.33.0以降、 vouch.document_root: /vp_in_a_pathを構成することで、Vouch Proxy を Nginx の場所 (パス) 内で提供できます。
これにより、 vouch.yourdomain.comなどの Vouch Proxy 用に別のドメインを設定する必要がなくなります。たとえば、VP ログインはhttps://protectedapp.yourdomain.com/vp_in_a_path/loginから提供されます。
サーバー { リッスン 443 ssl http2; サーバー名 protectedapp.yourdomain.com; ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem; # この場所は、すべての Vouch Proxy エンドポイントを /vp_in_a_path/$uri として提供します # /vp_in_a_path/validate、/vp_in_a_path/login、/vp_in_a_path/logout、/vp_in_a_path/auth、/vp_in_a_path/auth/$STATE などを含む location /vp_in_a_path { proxy_pass http://127.0.0.1:9090; ＃はいけません！末尾にスラッシュを付けます。 proxy_set_header Host $http_host; proxy_pass_request_body オフ; proxy_set_header Content-Length ""; # これらの戻り値は @error401 呼び出しで使用されます auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt; auth_request_set $auth_resp_err $upstream_http_x_vouch_err; auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount;
} # /vp_in_a_path/validate が「401 not allowed」を返した場合、リクエストを error401 ブロックに転送します error_page 401 = @error401; location @error401 { # ログイン用の Vouch Proxy にリダイレクト return 302 https://protectedapp.yourdomain.com/vp_in_a_path/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error =$auth_resp_err;
} location / { auth_request /vp_in_a_path/validate; プロキシパス http://127.0.0.1:8080; # Vouch Proxy から設定できる追加のヘッダーについては、上記の Nginx 構成を参照してください。
}
}追加の Nginx 構成は、example ディレクトリにあります。
ここでは、Google の OAuth を使用した最小限のセットアップを示します。
VOUCH_DOMAINS=あなたのドメイン.com OAUTH_PROVIDER=google OAUTH_CLIENT_ID=1234 OAUTH_CLIENT_SECRET=シークレットシークレット OAUTH_CALLBACK_URL=https://vouch.yourdomain.com/auth ./vouch-proxy
環境変数名は config/config.yml_example に文書化されています。
複数の値を含むリストはすべてカンマで区切る必要があります: VOUCH_DOMAINS="yourdomain.com,yourotherdomain.com"
変数VOUCH_CONFIG使用して、構成ファイルの別の場所を設定できます。 VOUCH_ROOT使用すると、サポート ファイルを検索するための Vouch プロキシの代替ルート ディレクトリを設定できます。
すべての Vouch Proxy 構成項目は config/config.yml_example に文書化されています。
Nginx での Vouch Proxy /validate応答のキャッシュ
Vouch Proxy で API を保護する場合のOPTIONSリクエストの処理
GitHub チームまたは GitHub 組織による検証
ARM ベースの Docker イメージを使用して Raspberry Pi 上で VP を実行する
Kubernetes アーキテクチャポスト Ingress
送信プロキシ サーバーを介して Vouch Proxy IdP リクエストを中継するようにHTTP_PROXYを設定します。
Google Cloud Run サービスのリバース プロキシ
Vouch Proxy でネイティブ TLS を有効にする
FreeBSD のサポート
Vouch Proxy のsystemd起動
Nginx の代わりに Node.js を使用してリクエストをルーティングする
VP で保護された API を使用しながらシングル ページ アプリ (SPA) を開発する
ユーザー認証および認証のためのサーバー側アプリケーションに Vouch Proxy を統合する
VP 検証の前に、 satisfy any;
このリストを拡大するためにぜひご協力ください。
Vouch Proxy を使用すると、さまざまなscopes (標準およびカスタム) をリクエストして、ユーザーに関する詳細情報を取得したり、プロバイダーの API にアクセスしたりできます。内部的には、Vouch Proxy は認証が成功した後にuser_info_urlへのリクエストを開始します。必要なclaimsプロバイダーの応答から抽出され、VP Cookie に保存されます。
VP Cookie は、ブラウザの Cookie サイズ制限に合わせて複数の Cookie に分割される場合があります。しかし、必要な場合は必要です。大きな Cookie とヘッダーを使用するには、より大きなバッファーを使用して Nginx を構成する必要があります。詳細については、「large_client_header_buffers」と「proxy_buffer_size」を参照してください。
scopesとclaimsのセットアップ通常どおり、Nginx および IdP 用の Vouch Proxy を構成します (参照: インストールと構成)
vouch-proxy config.ymlのoauthセクションで必要なscopeを設定します (設定例)
vouch-proxy のconfig.ymlのheadersセクションにidtoken: X-Vouch-IdP-IdToken設定します。
最新のブラウザでログインし、 /validateエンドポイントを呼び出します。
応答ヘッダーでX-Vouch-IdP-IdTokenヘッダーを確認してください。
https://jwt.io/ にあるデバッガーにヘッダーの値をコピーし、必要なクレームが jwt の一部であることを確認します。
そうでない場合は、 config.ymlのoauthセクションでscopesを調整するか、oauth プロバイダーを再構成する必要があります。
vouch-proxy config.ymlのheaderセクションに必要なclaimsを設定します。
最新のブラウザでログインし、 /validateエンドポイントを呼び出します。
応答ヘッダーでX-Vouch-IdP-Claims-<ClaimName>形式のヘッダーを確認してください。
そこにない場合は、Cookie とキャッシュされたブラウザ データをクリアします
?それらがまだ存在しないが、JWT (特にカスタム クレーム) に存在する場合は、バグがある可能性があります。
必要ない場合は、vouch-proxy のconfig.ymlのheadersセクションからidtoken: X-Vouch-IdP-IdTokenを削除します。
nginxのserver.conf内の保護された場所内でauth_requestの後にauth_request_setを使用します。
クレームを使用します (nginx 構成の例)
docker run -d
-p 9090:9090
--名前保証プロキシ
-v ${PWD}/config:/config
quay.io/vouch/vouch-proxyまたは
docker run -d
-p 9090:9090
--名前保証プロキシ
-e VOUCH_DOMAINS=yourdomain.com
-e OAUTH_PROVIDER=google
-e OAUTH_CLIENT_ID=1234
-e OAUTH_CLIENT_SECRET=シークレットシークレット
-e OAUTH_CALLBACK_URL=https://vouch.yourdomain.com/auth
quay.io/vouch/vouch-proxy v0.36.0以降、コンテナー内の Docker プロセスは、UID 999 および GID 999 のユーザーvouchとして実行されます。このユーザーが読み取りできるように、 /config/config.ymlおよび/config/secretの権限を設定する必要がある場合があります。または、 docker run --user $UID:$GID ...使用するか、ソースから Docker コンテナを構築し、UID と GID に使用可能な ARG を使用します。
各 Vouch Proxy リリースの自動コンテナ ビルドは quay.io から入手できます。各リリースでは、..
Dockerfileから構築された最小限の go バイナリ コンテナー
quay.io/vouch/vouch-proxy:latest
quay.io/vouch/vouch-proxy:xyz例: quay.io/vouch/vouch-proxy:0.28.0
Dockerfile.alpineから構築されたalpineベースのコンテナー
quay.io/vouch/vouch-proxy:alpine-latest
quay.io/vouch/vouch-proxy:alpine-xyz
Vouch Proxy armイメージは Docker Hub で入手できます
voucher/vouch-proxy:latest-arm
nginx-ingress で kubernetes を使用している場合は、次のアノテーションを使用して Ingress を構成できます ( auth-signinアノテーションを引用していることに注意してください)。
nginx.ingress.kubernetes.io/auth-signin: "https://vouch.yourdomain.com/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$ auth_resp_err"
nginx.ingress.kubernetes.io/auth-url: https://vouch.yourdomain.com/validate
nginx.ingress.kubernetes.io/auth-response-headers: X-Vouch-User
nginx.ingress.kubernetes.io/auth-snippet: | # これらの戻り値は @error401 呼び出しで使用されます
auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt;
auth_request_set $auth_resp_err $upstream_http_x_vouch_err;
auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount; # VP が k8s の外部でホストされている場合、MITM リスクを回避するために SSL 証明書が有効であることを確認します # proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt; # proxy_ssl_session_reuse オン; # proxy_ssl_verify_ Depth 2; # proxy_ssl_verify オン;Helm Chart は punkle、martina-if、halkeye によって管理されており、https://github.com/vouch/helm-charts から入手できます。
./do.sh ゴーゲット ./do.sh ビルド ./vouch-proxy
v0.29.0以降、 .defaults.yml内のすべてのテンプレート、静的アセット、および設定のデフォルトは、go:embed ディレクティブを使用して静的バイナリに組み込まれます。
v0.11.0では、URL リダイレクトの攻撃対象領域を減らすために追加のチェックが導入されています。
渡されたURLは…
httpまたはhttpsのいずれかで始まる必要があります
vouch.domainsリスト内のドメインまたはvouch.cookie.domain (いずれかが構成されている場合) と重複するドメインが必要です。
URL チェーン攻撃を防ぐために、URL を含むパラメータを指定することはできません
Vouch Proxy /logoutエンドポイントは、ユーザーを元の OAuth プロバイダー/IDP/OIDC プロバイダーの revocation_endpoint に302リダイレクトするために使用できるクエリ文字列内のurlパラメーターを受け入れます。
https://vouch.oursites.com/logout?url=https://oauth2.googleapis.com/revoke
この URL は、構成ファイルのリストvouch.post_logout_redirect_urisに存在する必要があります。
# リダイレクト攻撃を防ぐために、/logout にリダイレクトされるすべての URL を指定する必要があります# URL は引き続き Vouch Proxy に https://vouch.yourdomain.com/logout?url=${ONE OF THE URLS BELOW}post_logout_redirect_uris として渡す必要があります: # アプリのログイン ページ
- https://yourdomain.com/login # IdP ログアウトのポイント # https://accounts.google.com/.well-known/openid-configuration から
- https://oauth2.googleapis.com/revoke # IdP にデイジーチェーン接続している可能性があります
- https://myorg.okta.com/oauth2/123serverid/v1/logout?post_logout_redirect_uri=http://myapp.yourdomain.com/login IdP は独自の別個のpost_logout_redirect_uriリストを保持する可能性があることに注意してください。
ログアウト リソース..
グーグル
オクタ
認証0
Nginx、Vouch Proxy、IdP の間でスターを揃えるのは難しい場合があります。私たちは、お客様ができるだけ早く稼働できるようお手伝いしたいと考えています。最も一般的な問題は..
Cookie を共有できる共通のドメインで Vouch Proxy とアプリを実行していることを再確認してください。たとえば、 vouch.yourdomain.comとapp.yourdomain.com 、 .yourdomain.comドメイン上の Cookie を共有できます。 ( vouch.yourdomain.orgとapp.yourdomain.netを使用しようとしている場合は機能しません。)
場合によっては、Cookie を設定するドメインを明示的に定義する必要があります。構成ファイルで次のオプションを設定することでこれを行うことができます。
vouch: cookie: # Cookie のドメインを強制的に domain: yourdomain.com に設定します
引き続き問題が発生する場合は、次のことを試してください。
vouch.testing: trueオンにします。これにより、ループが遅くなります。
vouch.logLevel: debugを設定します。
http リクエストのHost:ヘッダー、 oauth.callback_url 、および設定されたvouch.domainsはすべて、JWT を含む Cookie がブラウザに適切に配置され、各リクエストで返されるように調整する必要があります。
クッキーのように考えると役立ちます。
Cookie がドメインに設定されます。 siteA.yourdomain.comとsiteB.yourdomain.com Vouch Proxy で保護されている場合、Vouch Proxy Cookie を.yourdomain.comに設定する必要があります。
vouch.yourdomain.comに対して認証すると、 dev.anythingelse.comは Cookie を参照できなくなります。
https を使用していない場合は、 vouch.cookie.secure: falseを設定する必要があります。
Cookie はドメインのすべてのポートで使用できます
リダイレクトについて言及しているクローズ済みの問題を参照してください。
次の方法で新しい号を送信してください。
TLDR:
vouch.testing: true
vouch.logLevel: debug
出力をキャプチャする./vouch-proxyの完全なラウンド トリップを 2 回実行します。
VP スタートアップ
/validate
/login - ここにエラーがある場合でも
/auth
/validate - すべてをキャプチャします
すべてのログと設定をgistに入れます。
./do.sh bug_reportあなたの友達です
vouch.testing: trueオンにし、 vouch.logLevel: debug設定します。
gist または hasteb.in などの別の貼り付けサービスを使用します。ログと設定を Github 問題に書き込まないでください。貼り付けサービスを使用すると、スペースが維持され、行番号と書式が提供されるため、重要です。私たちはいくつかの可動部品を備えたセットアップで干し草の山から針を探していますが、これらの機能は非常に役立ちます。貼り付けサービスはお客様と私たちの時間を節約し、迅速な対応に役立ちます。このアドバイスに従うことで、適切なサポートをタイムリーに受けられる可能性が高くなります。
./do.sh bug_report secretdomain.com secretpass [anothersecret..]を実行すると、編集されたバージョンの設定が作成され、各文字列が削除されてログが作成されます。
最後にある指示に従って、Nginx 構成を編集します。
それらはすべて要点に入ります
このリポジトリで新しい問題を開きます
バグ レポートは、 quay.io/vouch/vouch-proxy:alpine /vouch/vouch-proxy:alpine イメージを使用して Docker 環境から生成できます。
docker run --name vouch_proxy -v $PWD/config:/config -v $PWD/certs:/certs -it --rm --entrypoint /do.sh quay.io/vouch/vouch-proxy:alpine bug_report yourdomain.com anotherdomain.com someothersecret奮って投稿をお願いいたします。詳細については、投稿ガイドラインを参照してください。
OpenResty® は、標準の Nginx コア、LuaJIT、慎重に作成された多くの Lua ライブラリ、多くの高品質なサードパーティ Nginx モジュール、およびそれらの外部依存関係のほとんどを統合する本格的な Web プラットフォームです。
nginx を OpenResty に置き換えるのはかなり簡単です。
OpenResty と Lua を使用すると、ヘッダーまたはクレーム保証の受け渡しに対して、カスタマイズされた高度な承認を提供できます。
OpenResty とさまざまなシナリオの構成は、example ディレクトリで入手できます。
ボブはhttps://private.oursites.comにアクセスします
Nginxリバースプロキシ...
/validate返された場合...
https://vouch.oursites.com/login?url=https://private.oursites.comへの 302 リダイレクトで Bob に応答します。
200 OK、成功したらボブの通過を許可します
401 NotAuthorized の場合
Bob から private.oursites.com へのリクエストを受け取ります
/validateパス用に構成されたauth_requestモジュールを使用します
/validate 、 https://vouch.oursites.com/validate ://vouch.oursites.com/validate で認証サービスにリクエストproxy_passように構成されています
保証プロキシhttps://vouch.oursites.com/validate
401 NotAuthorizedを Nginx に返します (リクエストをログインに転送します)。
Nginx に200 OK返し、アクセスが許可されます (ボブは何も気づきません)
Nginx proxy_pass経由で Bob から private.oursites.com へのリクエストを受け取ります
JWT を含む「oursitesSSO」という名前の Cookie を探します。
Cookie が見つかり、JWT が有効な場合
Cookie が見つからない場合、または JWT が有効でない場合
ボブはまずhttps://vouch.oursites.com/login?url=https://private.oursites.comに短時間転送されます。
「oursitesSSO」という名前の Cookie が存在する場合はそれを消去します。
nonce を生成し、セッション変数 $STATE に格納します。
クエリ文字列からの URL https://private.oursites.comセッション変数$requestedURLに保存します
$STATEノンスを含む、Google の OAuth ログイン フォームへの 302 リダイレクトで Bob に応答します。
ボブは Oauth を使用して自分の Google アカウントにログインします
ログイン成功後
Google はhttps://vouch.oursites.com/auth?state=$STATE ://vouch.oursites.com/auth?state=$STATE への 302 リダイレクトで Bob に応答します。
ボブはhttps://vouch.oursites.com/auth?state=$STATEに転送されます
bob に「oursitesSSO」という名前の Cookie の形式で JWT を発行します。
セッション変数$requestedURLを取得し、ボブをhttps://private.oursites.comにリダイレクトします。
URL の $STATE nonce がセッション変数「state」と一致する場合
電子メール アドレス [email protected] を含む Bob のユーザー情報の OAuth コードを交換するために、Google の「第 3 段階」リクエストを (サーバー間で) 実行します。
電子メール アドレスがドメイン oursites.com と一致する場合 (一致します)
いくつかの無害なリダイレクトを除けば、ボブはブラウザでhttps://private.oursites.comと Google ログイン画面のみを参照することに注意してください。 Vouch は Bob のブラウザと何度か対話しますが、それは Cookie を設定するためだけであり、302 リダイレクトが適切に機能すれば、Bob はすぐにログインします。
JWT が設定されると、Bob は、 auth_request Nginx モジュールからhttps://vouch.oursites.com/validate使用するように構成されている他のすべてのサイトに対して認可されます。
次回、ボブがログインのために Google に転送されるとき、彼はすでに Vouch Proxy OAuth アプリを承認しているため、Google はすぐに彼を転送し、Cookie を設定して、彼を元気よく送り出します。 Chrome などの一部のブラウザでは、Bob は Vouch Proxy を使用してログインしたことにさえ気づかない可能性があります。
