vouch proxy
1.0.0
Uma solução SSO para Nginx usando o módulo auth_request. O Vouch Proxy pode proteger todos os seus sites de uma só vez.
O Vouch Proxy oferece suporte a muitos provedores de login OAuth e OIDC e pode impor autenticação para...
GitHub
GitHub Enterprise
IndieAuth
Okta
Folga
ADFS
AzureAD
Alibaba/Aliyun iDaas
AWS Cognito
Contração muscular
Discórdia
Autenticação segura
Gitea
Capa de chave
Biblioteca de servidor OAuth2 para PHP
HomeAssistente
OpenStax
Ory Hidra
Próxima nuvem
a maioria dos outros provedores OpenID Connect (OIDC)
Informe-nos quando você implantar o Vouch Proxy com seu IdP ou biblioteca de sua preferência para que possamos atualizar a lista.
Se o Vouch estiver em execução no mesmo host que o proxy reverso Nginx, o tempo de resposta do endpoint /validate para o Nginx deverá ser inferior a 1 ms .
O que o proxy de voucher faz...
Instalação e configuração
Vouch Proxy "em um caminho"
Configurações adicionais do Nginx
Configuração via Variáveis Ambientais
Dicas, truques e configurações avançadas
Escopos e reivindicações
Executando do Docker
Entrada Nginx do Kubernetes
Compilando a partir do código-fonte e executando o binário
Redirecionamento de endpoint /login e /logout
Solução de problemas, suporte e solicitações de recursos (leia isto antes de enviar um problema no GitHub)
Estou recebendo um loop de redirecionamento infinito que me retorna ao meu IdP (Google/Okta/GitHub/...)
Ok, analisei os problemas e tentei algumas coisas com minhas configurações, mas ainda não está funcionando
Contribuindo para o Vouch Proxy
Autorização avançada usando OpenResty
O fluxo de login e autenticação usando Google Oauth
O Vouch Proxy (VP) força os visitantes a fazer login e autenticação com um IdP (como um dos serviços listados acima) antes de permitir o acesso a um site.
O VP também pode ser usado como uma solução de logon único (SSO) para proteger todos os aplicativos da web no mesmo domínio.
Após o login do visitante, o Vouch Proxy permite o acesso aos sites protegidos por várias horas. Cada solicitação é verificada pelo VP para garantir que seja válida.
O VP pode enviar o e-mail, o nome e outras informações do visitante que o IdP fornece (incluindo tokens de acesso) ao aplicativo da web como cabeçalhos HTTP. O VP pode ser usado para substituir totalmente o gerenciamento de usuários do aplicativo.
O Vouch Proxy depende da capacidade de compartilhar um cookie entre o servidor Vouch Proxy e o aplicativo que ele está protegendo. Normalmente, isso será feito executando o Vouch em um subdomínio como vouch.yourdomain.com com aplicativos em execução em app1.yourdomain.com e app2.yourdomain.com . O domínio protegido é .yourdomain.com e o cookie Vouch Proxy deve ser definido neste domínio definindo vouch.domains para incluir yourdomain.com ou às vezes definindo vouch.cookie.domain como yourdomain.com .
cp ./config/config.yml_example_$OAUTH_PROVIDER ./config/config.yml
crie credenciais OAuth para Vouch Proxy no google ou github, etc.
certifique-se de direcionar o URL de retorno de chamada para o endpoint Vouch Proxy /auth
configurar o Nginx...
A seguinte configuração do Nginx assume ..
Nginx, vouch.yourdomain.com e protectedapp.yourdomain.com estão sendo executados no mesmo servidor
ambos os domínios são servidos como https e possuem certificados válidos (caso contrário, mude para listen 80 e defina vouch.cookie.secure como false )
servidor {ouvir 443 ssl http2; nome_servidor protectedapp.seudominio.com; raiz /var/www/html/; ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem; # envia todas as solicitações para o endpoint `/validate` para autorização auth_request /validate; location = /validate { # encaminha a solicitação /validate para Vouch Proxy proxy_pass http://127.0.0.1:9090/validate; # certifique-se de passar o cabeçalho do host original proxy_set_header Host $http_host; # Vouch Proxy atua apenas nos cabeçalhos da requisição proxy_pass_request_body off; proxy_set_header Comprimento do conteúdo ""; # opcionalmente adicione X-Vouch-User conforme retornado pelo Vouch Proxy junto com a solicitação auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user; # opcionalmente, adicione reivindicações personalizadas X-Vouch-IdP-Claims-* que você está rastreando # 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; # opcionalmente adicione X-Vouch-IdP-AccessToken ou 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; # esses valores de retorno são usados pela chamada @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; # O Vouch Proxy pode ser executado atrás do mesmo proxy reverso Nginx # pode precisar obedecer à nomenclatura do servidor "upstream" # proxy_pass http://vouch.yourdomain.com/validate; # proxy_set_header Host $http_host;
} # se validar retornar `401 não autorizado` então encaminhe a solicitação para error401block error_page 401 = @error401; location @error401 { # redireciona para Vouch Proxy para retorno de login 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; # você normalmente *quer* redirecionar para o Vouch rodando atrás da mesma configuração Nginx protegida por https # mas para começar você pode simplesmente encaminhar o usuário final para a porta em que o voucher está rodando # return 302 http://vouch.seudominio.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 / { # encaminha solicitações autorizadas para seu serviço protectedapp.yourdomain.com proxy_pass http://127.0.0.1:8080; # pode ser necessário definir essas variáveis neste bloco conforme 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; # define o cabeçalho do usuário (geralmente um e-mail) proxy_set_header X-Vouch-User $auth_resp_x_vouch_user; # opcionalmente, transmita quaisquer declarações personalizadas que você esteja rastreando # 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; # opcionalmente passe o accesstoken ou idtoken # 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;
}
} Se o Vouch estiver configurado atrás do mesmo proxy reverso nginx (talvez para que você possa configurar o SSL), certifique-se de passar o cabeçalho Host corretamente, caso contrário, o cookie JWT não poderá ser definido no domínio
servidor {ouvir 443 ssl http2; nome_do_servidor voucher.seudominio.com; ssl_certificate /etc/letsencrypt/live/vouch.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/vouch.yourdomain.com/privkey.pem; localização / { proxy_pass http://127.0.0.1:9090; # certifique-se de passar o cabeçalho do host original proxy_set_header Host $http_host;
}
} A partir da v0.33.0 o Vouch Proxy pode ser servido em um local Nginx (caminho) configurando vouch.document_root: /vp_in_a_path
Isso evita a necessidade de configurar um domínio separado para o Vouch Proxy, como vouch.yourdomain.com . Por exemplo, o login do VP será servido em https://protectedapp.yourdomain.com/vp_in_a_path/login
servidor {ouvir 443 ssl http2; nome_servidor protectedapp.seudominio.com; ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem; # Este local atende todos os endpoints do Vouch Proxy como /vp_in_a_path/$uri # incluindo /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, etc location /vp_in_a_path { proxy_pass http://127.0.0.1:9090; # não deve! tem uma barra no final proxy_set_header Host $http_host; proxy_pass_request_body desativado; proxy_set_header Comprimento do conteúdo ""; # esses valores de retorno são usados pela chamada @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;
} # se /vp_in_a_path/validate retornar `401 não autorizado` então encaminhe a solicitação para error401block error_page 401 = @error401; location @error401 { # redireciona para Vouch Proxy para retorno de login 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;
} localização / {auth_request /vp_in_a_path/validate; proxy_pass http://127.0.0.1:8080; # veja a configuração do Nginx acima para cabeçalhos adicionais que podem ser definidos no Vouch Proxy
}
}Configurações adicionais do Nginx podem ser encontradas no diretório de exemplos.
Aqui está uma configuração mínima usando o OAuth do Google...
VOUCH_DOMAINS=seudominio.com OAUTH_PROVIDER=google OAUTH_CLIENT_ID=1234 OAUTH_CLIENT_SECRET=secreto segredo OAUTH_CALLBACK_URL=https://vouch.seudominio.com/auth ./vouch-proxy
Os nomes das variáveis ambientais estão documentados em config/config.yml_example
Todas as listas com vários valores devem ser separadas por vírgulas: VOUCH_DOMAINS="yourdomain.com,yourotherdomain.com"
A variável VOUCH_CONFIG pode ser usada para definir um local alternativo para o arquivo de configuração. VOUCH_ROOT pode ser usado para definir um diretório raiz alternativo para o Vouch Proxy procurar arquivos de suporte.
Todos os itens de configuração do Vouch Proxy estão documentados em config/config.yml_example
Armazenamento em cache da resposta Vouch Proxy /validate no Nginx
Lidando com solicitações OPTIONS ao proteger uma API com Vouch Proxy
Validação pela equipe GitHub ou GitHub Org
Executando VP em um Raspberry Pi usando a imagem Docker baseada em ARM
Arquitetura do Kubernetes após entrada
definir HTTP_PROXY para retransmitir solicitações de IdP do Vouch Proxy por meio de um servidor proxy de saída
Proxy reverso para serviços do Google Cloud Run
Habilitar TLS nativo no Vouch Proxy
Suporte FreeBSD
inicialização systemd do Vouch Proxy
Usando Node.js em vez de Nginx para rotear solicitações
Desenvolvendo um aplicativo de página única (SPA) enquanto consome uma API protegida por VP
Integre o Vouch Proxy em um aplicativo do lado do servidor para User Authn e Authz
Filtre por endereço IP antes da validação do VP usando satisfy any;
Por favor, ajude-nos a expandir esta lista.
Com o Vouch Proxy você pode solicitar diversos scopes (padrão e customizados) para obter mais informações sobre o usuário ou ter acesso às APIs do provedor. Internamente, o Vouch Proxy lança solicitações para user_info_url após a autenticação bem-sucedida. As claims necessárias são extraídas da resposta do provedor e armazenadas no cookie VP.
O cookie VP pode ser dividido em vários cookies para acomodar os limites de tamanho dos cookies do navegador. Mas se você precisar, você precisa. Cookies e cabeçalhos grandes exigem que o Nginx seja configurado com buffers maiores. Consulte large_client_header_buffers e proxy_buffer_size para obter mais informações.
scopes e claims no Vouch Proxy com NginxConfigure o Vouch Proxy para Nginx e seu IdP normalmente (consulte: Instalação e configuração)
Defina os scope necessários na seção oauth do vouch-proxy config.yml (exemplo de configuração)
defina idtoken: X-Vouch-IdP-IdToken na seção de headers do config.yml do voucher-proxy
faça login e chame o endpoint /validate em um navegador moderno
verifique o cabeçalho de resposta para um cabeçalho X-Vouch-IdP-IdToken
copie o valor do cabeçalho no depurador em https://jwt.io/ e certifique-se de que as declarações necessárias façam parte do jwt
se não estiverem, você precisará ajustar os scopes na seção oauth do seu config.yml ou reconfigurar seu provedor oauth
Defina as claims necessárias na seção header do voucher-proxy config.yml
faça login e chame o endpoint /validate em um navegador moderno
verifique os cabeçalhos de resposta para cabeçalhos no formato X-Vouch-IdP-Claims-<ClaimName>
Se eles não estiverem lá, limpe seus cookies e dados armazenados em cache do navegador
? Se eles ainda não estiverem lá, mas existirem no jwt (especialmente declarações personalizadas), pode haver um bug
remova o idtoken: X-Vouch-IdP-IdToken da seção de headers do config.yml do voucher-proxy se você não precisar dele
Use auth_request_set após auth_request dentro do local protegido no nginx server.conf
Consumir a declaração (exemplo de configuração do nginx)
janela de encaixe execute -d
-p9090:9090
--name comprovante-proxy
-v ${PWD}/config:/config
quay.io/vouch/vouch-proxyou
janela de encaixe execute -d
-p9090:9090
--name comprovante-proxy
-e VOUCH_DOMAINS=seudominio.com
-e OAUTH_PROVIDER=google
-e OAUTH_CLIENT_ID=1234
-e OAUTH_CLIENT_SECRET=secretsecreto
-e OAUTH_CALLBACK_URL = https://vouch.seudominio.com/auth
quay.io/vouch/vouch-proxy A partir da v0.36.0 o processo docker no contêiner é executado como vouch do usuário com UID 999 e GID 999. Pode ser necessário definir as permissões de /config/config.yml e /config/secret para que possam ser lidas por este usuário, ou use docker run --user $UID:$GID ... ou talvez construa o contêiner docker a partir da fonte e use os ARGs disponíveis para UID e GID.
Construções automatizadas de contêineres para cada versão do Vouch Proxy estão disponíveis em quay.io. Cada lançamento produz..
um contêiner binário mínimo construído a partir do Dockerfile
quay.io/vouch/vouch-proxy:latest
quay.io/vouch/vouch-proxy:xyz como quay.io/vouch/vouch-proxy:0.28.0
um contêiner baseado em alpine construído a partir de Dockerfile.alpine
quay.io/vouch/vouch-proxy:alpine-latest
quay.io/vouch/vouch-proxy:alpine-xyz
As imagens arm Vouch Proxy estão disponíveis no Docker Hub
voucher/vouch-proxy:latest-arm
Se você estiver usando kubernetes com nginx-ingress, poderá configurar sua entrada com as seguintes anotações (observe a citação da anotação 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: | # esses valores de retorno são usados pela chamada @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; # quando o VP for hospedado externamente no k8s, garanta que o certificado SSL seja válido para evitar o risco MITM # proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt; # proxy_ssl_session_reuse ativado; # proxy_ssl_verify_profundidade 2; # proxy_ssl_verify ativado;Helm Charts são mantidos por punkle, martina-if e halkeye e estão disponíveis em https://github.com/vouch/helm-charts
./do.sh goget ./do.sh compilação ./vouch-proxy
A partir da v0.29.0 todos os modelos, ativos estáticos e padrões de configuração em .defaults.yml são integrados ao binário estático usando diretivas go:embed.
A partir da v0.11.0 verificações adicionais estão em vigor para reduzir a superfície de ataque do redirecionamento de URL.
O URL passado...
deve começar com http ou https
deve ter uma sobreposição de domínio com um domínio na lista vouch.domains ou vouch.cookie.domain (se algum deles estiver configurado)
não pode ter um parâmetro que inclua uma URL para evitar ataques de encadeamento de URL
O endpoint Vouch Proxy /logout aceita um parâmetro url na string de consulta que pode ser usado para redirecionar 302 um usuário para o revocation_endpoint original do seu provedor OAuth/IDP/OIDC
https://vouch.oursites.com/logout?url=https://oauth2.googleapis.com/revoke
esta url deve estar presente no arquivo de configuração da lista vouch.post_logout_redirect_uris
# para evitar ataques de redirecionamento, todos os URLs redirecionados para /logout devem ser especificados# o URL ainda deve ser passado para o Vouch Proxy como https://vouch.yourdomain.com/logout?url=${ONE OF THE URLS BELOW}post_logout_redirect_uris : # página de login do seu aplicativo
- https://seudominio.com/login # seu logout do IdP enpoint # de https://accounts.google.com/.well-known/openid-configuration
- https://oauth2.googleapis.com/revoke # você pode estar conectado em cadeia ao seu IdP
- https://myorg.okta.com/oauth2/123serverid/v1/logout?post_logout_redirect_uri=http://myapp.yourdomain.com/login Observe que seu IdP provavelmente terá sua própria lista post_logout_redirect_uri separada.
recursos de logout..
Okta
Autor0
Fazer com que as estrelas se alinhem entre Nginx, Vouch Proxy e seu IdP pode ser complicado. Queremos ajudá-lo a começar a trabalhar o mais rápido possível. O problema mais comum é..
Verifique novamente se você está executando o Vouch Proxy e seus aplicativos em um domínio comum que pode compartilhar cookies. Por exemplo, vouch.yourdomain.com e app.yourdomain.com podem compartilhar cookies no domínio .yourdomain.com . (Não funcionará se você estiver tentando usar vouch.yourdomain.org e app.yourdomain.net .)
Talvez seja necessário definir explicitamente o domínio no qual o cookie deve ser definido. Você pode fazer isso no arquivo de configuração definindo a opção:
atestar: cookie: # forçar o domínio do cookie a definir domínio: seudominio.com
Se você continuar tendo problemas, tente o seguinte:
ative vouch.testing: true . Isso desacelerará o loop.
defina vouch.logLevel: debug .
o cabeçalho Host: na solicitação http, o oauth.callback_url e os vouch.domains configurados devem estar todos alinhados para que o cookie que carrega o JWT possa ser colocado corretamente no navegador e retornado em cada solicitação
ajuda pensar como um biscoito .
um cookie é definido em um domínio. Se você tiver siteA.yourdomain.com e siteB.yourdomain.com protegidos pelo Vouch Proxy, você deseja que o cookie Vouch Proxy seja definido como .yourdomain.com
se você se autenticar em vouch.yourdomain.com o cookie não poderá ser visto por dev.anythingelse.com
a menos que você esteja usando https, você deve definir vouch.cookie.secure: false
cookies estão disponíveis para todas as portas de um domínio
veja os problemas que foram encerrados que mencionam redirecionamento
Envie um novo problema da seguinte maneira.
TLDR:
definir vouch.testing: true
definir vouch.logLevel: debug
conduza duas viagens completas de ./vouch-proxy capturando a saída.
Inicialização do vice-presidente
/validate
/login - mesmo que o erro esteja aqui
/auth
/validate – captura tudo
coloque todos os seus logs e configurações em um gist .
./do.sh bug_report é seu amigo
ative vouch.testing: true e defina vouch.logLevel: debug .
use uma essência ou outro serviço de colagem, como hasb.in. NÃO COLOQUE SEUS LOGOS E CONFIGURAÇÃO NO PROBLEMA DO GITHUB . Usar um serviço de colagem é importante porque manterá o espaçamento e fornecerá números de linha e formatação. Estamos caçando agulhas em palheiros com configurações com diversas partes móveis, esses recursos ajudam bastante. Os serviços de colagem economizam seu e nosso tempo e nos ajudam a ajudá-lo rapidamente. É mais provável que você obtenha um bom suporte nosso em tempo hábil seguindo este conselho.
execute ./do.sh bug_report secretdomain.com secretpass [anothersecret..] que criará uma versão editada de sua configuração e logs removendo cada uma dessas strings
e siga as instruções no final para redigir sua configuração do Nginx
tudo isso entra em uma essência
então abra um novo problema neste repositório
Um relatório de bug pode ser gerado a partir de um ambiente docker usando a imagem quay.io/vouch/vouch-proxy:alpine ...
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 someothersecretAdoraríamos que você contribuísse! Consulte nossas diretrizes de contribuição para obter detalhes.
OpenResty® é uma plataforma web completa que integra o núcleo Nginx padrão, LuaJIT, muitas bibliotecas Lua cuidadosamente escritas, muitos módulos Nginx de terceiros de alta qualidade e a maioria de suas dependências externas.
Você pode substituir o nginx pelo OpenResty com bastante facilidade.
Com OpenResty e Lua é possível fornecer autorização personalizada e avançada em qualquer cabeçalho ou comprovante de reivindicação transmitido.
OpenResty e configurações para uma variedade de cenários estão disponíveis no diretório de exemplos.
Bob visita https://private.oursites.com
o proxy reverso Nginx ...
se /validate retornar...
responda a Bob com um redirecionamento 302 para https://vouch.oursites.com/login?url=https://private.oursites.com
200 OK então SUCESSO permite que Bob passe
401 Não Autorizado então
recebe a solicitação de private.oursites.com de Bob
usa o módulo auth_request configurado para o caminho /validate
/validate está configurado para solicitações proxy_pass para o serviço de autenticação em https://vouch.oursites.com/validate
Proxy de voucher https://vouch.oursites.com/validate
retorne 401 NotAuthorized para Nginx (que encaminha a solicitação para login)
retorna 200 OK para Nginx, que permitirá acesso (bob não percebe nada)
recebe a solicitação de private.oursites.com de Bob via Nginx proxy_pass
procura um cookie chamado "oursitesSSO" que contém um JWT
se o cookie for encontrado e o JWT for válido
se o cookie NÃO for encontrado ou o JWT NÃO for válido
Bob é primeiro encaminhado brevemente para https://vouch.oursites.com/login?url=https://private.oursites.com
limpa o cookie chamado "oursitesSSO" se existir
gera um nonce e o armazena na variável de sessão $STATE
armazena o URL https://private.oursites.com da string de consulta na variável de sessão $requestedURL
responda a Bob com um redirecionamento 302 para o formulário de login OAuth do Google, incluindo o nonce $STATE
Bob faz login em sua conta do Google usando Oauth
após login bem sucedido
O Google responde a Bob com um redirecionamento 302 para https://vouch.oursites.com/auth?state=$STATE
Bob é encaminhado para https://vouch.oursites.com/auth?state=$STATE
emita bob um JWT na forma de um cookie chamado "oursitesSSO"
recupere a variável de sessão $requestedURL e redirecione 302 bob de volta para https://private.oursites.com
se o nonce $STATE do URL corresponder à variável de sessão "state"
faça uma solicitação de "terceira etapa" do Google (servidor para servidor) para trocar o código OAuth pelas informações do usuário de Bob, incluindo o endereço de e-mail [email protected]
se o endereço de e-mail corresponder ao domínio oursites.com (corresponde)
Observe que, fora alguns redirecionamentos inócuos, Bob só vê https://private.oursites.com e a tela de login do Google em seu navegador. Embora o Vouch interaja com o navegador de Bob várias vezes, é apenas para definir cookies e, se os redirecionamentos 302 funcionarem corretamente, Bob fará login rapidamente.
Assim que o JWT for definido, Bob será autorizado para todos os outros sites configurados para usar https://vouch.oursites.com/validate do módulo auth_request Nginx.
Na próxima vez que Bob for encaminhado ao Google para login, como ele já autorizou o aplicativo Vouch Proxy OAuth, o Google imediatamente o encaminhará de volta e definirá o cookie e o enviará embora. Em alguns navegadores como o Chrome, Bob pode nem perceber que fez login usando o Vouch Proxy.
