[ Editor – Esta postagem descreve como usar o NGINX Plus com provedores OpenID Connect que suportam o Implicit Flow para autenticação. As informações estão tecnicamente corretas, mas algumas ações (como usar o cron
para buscar chaves públicas) não são mais necessárias devido a atualizações em nossa implementação de referência. Para a implementação atual, consulte nosso repositório GitHub .
No NGINX Plus R15 e versões posteriores, você também pode usar o NGINX Plus como a Parte Confiável no Fluxo de Código de Autorização do OpenID Connect.]
O OAuth 2.0 fez muito para transformar a flexibilidade e a experiência do usuário na autenticação de sites e aplicativos. Mas, apesar do nome, a especificação OAuth 2.0 diz muito pouco sobre a verificação da identidade do usuário final e nada sobre o logon único (SSO). É aí que entra o OpenID Connect : ele é essencialmente a peça que faltava e que carrega informações de identidade em tokens de acesso OAuth 2.0.
Os tokens de identidade OpenID Connect estão em conformidade com a especificação JSON Web Token (JWT) . Os tokens JWT (pronuncia-se “jot”) são compactos, fáceis de repassar e fornecem um esquema central comum para descrever informações de identidade. O melhor dos JWTs é que eles podem ser aplicados a quase qualquer caso de uso de identidade, desde a autenticação de clientes de API até o fornecimento de SSO para aplicativos corporativos. Na verdade, muitas organizações que usam o Google Apps podem utilizar o Google como provedor de identidade para fornecer SSO aos seus aplicativos empresariais . Dito isso, o uso do OpenID Connect e dos JWTs não impede que eles sejam usados para autenticação ou fornecimento de SSO para aplicativos web existentes.
O NGINX Plus R10 e versões posteriores incluem suporte nativo a JWT, permitindo que o NGINX Plus valide tokens e decore solicitações upstream com a identidade do usuário autenticado de uma forma que o aplicativo possa consumir facilmente. Nesta postagem do blog, demonstramos como usar o suporte JWT nativo no NGINX Plus para habilitar o SSO para aplicativos existentes sem nenhuma alteração necessária nos próprios aplicativos. Estamos usando o Google como provedor de identidade e um site simples para representar o aplicativo. O fluxo de ponta a ponta se parece com isto:
Nosso exemplo tem dois componentes: a configuração do NGINX Plus e a página de login HTML.
A configuração do NGINX Plus para validar JWTs é muito simples.
servidor { ouvir 80;
raiz /var/www/public_html;
localização /privado/ {
auth_jwt "Conta do Google" token=$cookie_auth_token;
auth_jwt_key_file /etc/nginx/google_certs.jwk;
}
}
O bloco de localização
especifica que quaisquer solicitações para URLs que começam com /private/ devem ser autenticadas. A diretiva auth_jwt
define o domínio de autenticação que será retornado (junto com um401
) se a autenticação não for bem-sucedida e onde na solicitação o NGINX Plus pode encontrar o JWT. Neste caso, ele espera encontrar o token em um cookie chamado auth_token . Por padrão, o NGINX Plus espera que os clientes apresentem o JWT como um Bearer Token , usando o cabeçalho Authorization
, como é comum em aplicativos AJAX e clientes de API , mas também pode obter o JWT de outros cabeçalhos HTTP, argumentos de string de consulta ou um cookie, como neste exemplo.
A diretiva auth_jwt_key_file
informa ao NGINX como validar o elemento de assinatura do JWT. A validação da assinatura garante que o JWT foi emitido pelo Google e não foi modificado desde então. O Google publica suas chaves públicas e as atualiza regularmente. Para manter um conjunto de chaves atualizado, use cron(8)
para buscá-las de hora em hora, como nesta entrada de exemplo do crontab
.
0 * * * * wget https://www.googleapis.com/oauth2/v3/certs -O /etc/nginx/google_certs.jwk
Para manter este exemplo simples e direto, não estamos criando um aplicativo inteiro. Em vez disso, estamos usando o seguinte HTML básico para criar uma página de login. O arquivo HTML é chamado /var/www/public_html/index.html (corresponde ao caminho raiz
que definimos na configuração do NGINX Plus).
<html>
<head>
<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="expires" content="0" />
<title>Demonstração do NGINX OpenID Connect</title>
<script src="https://apis.google.com/js/platform.js" async defer></script>
<meta name="google-signin-scope" content="profile email">
<meta nome="google-signin-client_id"
conteúdo="ID do cliente.apps.googleusercontent.com">
<script src="/js.cookie.js"></script>
</head>
<body>
<h2>Demonstração do NGINX OpenID Connect</h2>
<hr/>
<h3>Faça login com uma conta do Google e visite a <a href="/private/">área privada</a>.</h3>
<table><tr><td>
<div class="g-signin2" data-onsuccess="onSignIn" data-theme="dark"></div></td>
<script>
function onSignIn(googleUser) {
var profile = googleUser.getBasicProfile();
Cookies.set('auth_token', googleUser.getAuthResponse().id_token);
document.getElementById('google_signout').innerHTML = '<a href="#" onclick="signOut();"><img src="' + profile.getImageUrl() + '" width=32 height=32>Sair</a>';
};
function signOut() {
var auth2 = gapi.auth2.getAuthInstance();
auth2.signOut().then(function () {
Cookies.remove('auth_token');
document.getElementById('google_signout').innerHTML = '';
});
}
</script>
<td><div id="google_signout"></div></td>
</tr></table>
<hr/>
</body>
</html>
Destacamos duas dependências principais no bloco .
<meta name="google‑signin‑client_id">
tag – Estamos usando API JavaScript OAuth 2.0 do Google para executar o processo de autenticação e consentimento do usuário final OAuth 2.0. É isso que nos dá o botão de login e pode detectar se estamos logados ou não. Para que nosso site seja autenticado pelo Google, precisamos criar um ID de cliente OAuth 2.0 e fornecê-lo como atributo de conteúdo
para esta tag, substituindo o espaço reservado client-ID
. Para obter instruções sobre como criar um novo ID de cliente OAuth 2.0, consulte o Apêndice no final deste artigo.<script src="/js.cookie.js">
tag – Precisamos de um analisador de cookie que possa extrair o token de identidade do token de acesso OAuth 2.0 e criar um cookie a ser enviado ao site. A linha Cookies.set
faz isso usando a biblioteca JavaScript Cookie , que está incluída nesta tag.Com essas peças no lugar, agora temos uma página inicial pública com o mecanismo de login do Google e uma área privada protegida pelo NGINX Plus. Observe que não criamos nenhum conteúdo para nossa área privada, portanto,404
é de se esperar um erro quando tentamos acessá-lo.
Para obter detalhes sobre a funcionalidade avançada do JWT, consulte Autenticação de clientes de API com JWT e NGINX Plus . Ele explica como fazer proxy de solicitações autenticadas com informações de identidade do usuário obtidas do JWT, registrar declarações do JWT e oferecer suporte a vários provedores de identidade.
Para explorar o suporte nativo ao JWT no NGINX Plus, comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco .
[ Editor – Fizemos todos os esforços para representar com precisão a GUI das APIs do Google no momento da publicação, mas a GUI é altamente dinâmica, com opções de menu e locais sujeitos a alterações. Use estas instruções como referência e adapte-as à GUI atual conforme necessário.]
Acesse o Painel de APIs do Google em https://console.developers.google.com/apis/dashboard .
A página que abre depende do seu histórico com as APIs do Google. Talvez seja necessário criar uma conta, aceitar os termos de uso e executar outras etapas não mostradas nestas instruções.
A captura de tela a seguir mostra o canto superior esquerdo do painel. Clique na palavra à direita do logotipo das APIs do Google (se você tiver criado um projeto anteriormente, seu nome poderá aparecer em vez da palavra Projeto ). Selecione Criar projeto .
Crie um novo projeto. Aqui, nosso novo projeto é chamado NGINX OpenID . Após clicar no botão Create , pode levar vários segundos até que uma notificação apareça indicando que seu projeto foi criado.
Habilite a API do Google+ para seu projeto. Ele fornece serviços de autenticação e identidade OAuth 2.0.
(Se o painel do API Manager ainda não aparecer na parte principal da janela, clique em Painel na área de navegação à esquerda da tela.)
O primeiro passo para habilitar a API do Google+ é clicar no botão HABILITAR API .
Clique em API do Google+ (na seção APIs sociais ).
Clique no botão HABILITAR .
Para criar credenciais para seu projeto, clique em Credenciais na área de navegação à esquerda da tela e depois clique no botão Criar credenciais .
Selecione ID do cliente OAuth no menu suspenso.
Selecione o botão de opção Aplicativo Web . No campo Origens JavaScript autorizadas , especifique a URL do host onde o NGINX Plus está instalado e o número da porta que você especificou como parâmetro para a diretiva listen
em Habilitando o OpenID Connect para seu aplicativo Web (por exemplo, mydomain.example.com:80 ). Este exemplo usa localhost, mas sua entrada precisa ser o nome do host e a porta da instância real do NGINX Plus.
Clique no botão Criar (talvez seja necessário clicar nele mais de uma vez para que o processo de criação seja iniciado).
A janela do cliente OAuth é exibida para informar seu ID e segredo do cliente. Copie o ID do cliente para o contente
atributo do <meta nome="google-signin-client_id">
tag no seu aplicativo (substituindo a tag destacada ID do cliente
espaço reservado mostrado acima). Você não precisa do segredo do cliente.
Na tela principal Credenciais , clique em Tela de consentimento do OAuth . Forneça seu endereço de e-mail e um nome de produto (todos os outros campos são opcionais).
Retorne à seção sobre como criar um aplicativo de exemplo que usa as credenciais
Para explorar o suporte nativo ao JWT no NGINX Plus, comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco .
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."