Trabalhar com tokens OAuth na autenticação do Serviço de Aplicativo do Azure
Este artigo mostra como trabalhar com tokens OAuth usando a autenticação e autorização internas no Serviço de Aplicativo.
Recuperar tokens no código do aplicativo
No seu código de servidor, os tokens específicos do provedor são injetados no cabeçalho da solicitação, para que você possa acessá-los facilmente. A tabela a seguir mostra os possíveis nomes de cabeçalho do token:
| Provedor | Nomes do Cabeçalho |
|---|---|
| Microsoft Entra | X-MS-TOKEN-AAD-ID-TOKEN X-MS-TOKEN-AAD-ACCESS-TOKEN X-MS-TOKEN-AAD-EXPIRES-ON X-MS-TOKEN-AAD-REFRESH-TOKEN |
| Token do Facebook | X-MS-TOKEN-FACEBOOK-ACCESS-TOKEN X-MS-TOKEN-FACEBOOK-EXPIRES-ON |
X-MS-TOKEN-GOOGLE-ID-TOKEN X-MS-TOKEN-GOOGLE-ACCESS-TOKEN X-MS-TOKEN-GOOGLE-EXPIRES-ON X-MS-TOKEN-GOOGLE-REFRESH-TOKEN |
|
| X | X-MS-TOKEN-TWITTER-ACCESS-TOKEN X-MS-TOKEN-TWITTER-ACCESS-TOKEN-SECRET |
Observação
Estruturas de linguagem diferentes podem apresentar os cabeçalhos para o código do aplicativo em diferentes formatos, como letras minúsculas ou de título.
Do seu código do cliente (por exemplo, um aplicativo móvel ou JavaScript no navegador), envie uma solicitação HTTP GET para /.auth/me (repositório de token deve estar habilitado). O JSON retornado tem os tokens específicos do provedor.
Observação
Tokens de acesso são para acessar recursos do provedor, para que eles fiquem presentes somente se você configurar o provedor com um segredo do cliente. Para saber como obter tokens de atualização, confira Tokens de acesso de atualização.
Atualizar tokens de autenticação
Quando o token de acesso do seu provedor (não o token de sessão) expirar, você precisará autenticar novamente o usuário antes de usar esse token novamente. Você pode evitar a expiração do token fazendo uma GET chamada para o /.auth/refresh ponto de extremidade de seu aplicativo. Quando chamado, o Serviço de Aplicativo atualiza automaticamente tokens de acesso no repositório de token para o usuário autenticado. As solicitações subsequentes de tokens do seu código do aplicativo obtêm tokens atualizados. No entanto, para que a atualização do token funcione, o repositório de token deve conter tokens de atualização para o seu provedor. A forma de obter tokens de atualização é documentada por cada provedor, mas a lista a seguir traz um breve resumo:
Google: anexe um
access_type=offlineparâmetro de cadeia de caracteres para consulta a sua/.auth/login/googlechamada à API. Para saber mais, confira Tokens de Atualização do Google.Facebook: não fornece tokens de atualização. Tokens de vida útil longa expiram em 60 dias (consulte Expiração e extensão de tokens de acesso do Facebook).
X: os tokens de acesso não expiram (confira Perguntas Frequentes do OAuth).
Microsoft: em https://resources.azure.com, execute as seguintes etapas:
Na parte superior da página, selecione Ler/Gravar.
No navegador à esquerda, navegue até assinaturas><subscription_name>>resourceGroups><resource_group_name>>fornecedores>Microsoft.Web>sites><app_name>>config>authsettingsV2.
Clique em Editar.
Modifique a propriedade a seguir.
"identityProviders": { "azureActiveDirectory": { "login": { "loginParameters": ["scope=openid profile email offline_access"] } } }Clique em Put.
Observação
O escopo que fornece um token de atualização é offline_access. Veja como é usado noTutorial: Autenticar e autorizar usuários de ponta a ponta no Serviço de Aplicativo do Azure. Os outros escopos já são solicitados por padrão pelo Serviço de Aplicativo. Para obter informações sobre esses escopos padrão, consulte Escopos do OpenID Connect.
Depois que seu provedor estiver configurado, você poderá encontrar o token de atualização e o tempo de expiração do token de acesso na loja do token.
Para atualizar o token de acesso a qualquer momento, basta chamar /.auth/refresh em qualquer idioma. O snippet a seguir usa o jQuery para atualizar seus tokens de acesso de um cliente JavaScript.
function refreshTokens() {
let refreshUrl = "/.auth/refresh";
$.ajax(refreshUrl) .done(function() {
console.log("Token refresh completed successfully.");
}) .fail(function() {
console.log("Token refresh failed. See application logs for details.");
});
}
Se um usuário revoga as permissões concedidas ao seu aplicativo, a chamada para /.auth/me pode falhar com um resposta 403 Forbidden. Para diagnosticar erros, verifique os logs de aplicativo para obter detalhes.
Estender o período de cortesia de término do token da sessão
A sessão autenticada expira após 8 horas. Depois que uma sessão autenticada expira, há um período de cortesia de 72 horas por padrão. Dentro desse período, você pode atualizar o token de sessão com o Serviço de Aplicativo sem reautenticar o usuário. Você pode simplesmente chamar /.auth/refresh quando o token de sessão se torna inválido e não é necessário rastrear o término do token por conta própria. Após o término do período de carência de 72 horas, o usuário deverá efetuar login novamente para obter um token de sessão válido.
Se 72 horas não for tempo suficiente, você pode estender essa janela de expiração. Estender a expiração por um longo período pode ter implicações significativas de segurança (por exemplo, quando um token de autenticação é perdido ou roubado). Portanto, você deve deixar o padrão de 72 horas ou definir o período de extensão para o menor valor.
Para estender a janela de validade padrão, execute o seguinte comando no Cloud Shell.
az webapp auth update --resource-group <group_name> --name <app_name> --token-refresh-extension-hours <hours>
Observação
O período de cortesia se aplica somente à sessão autenticada do Serviço de Aplicativo, não aos tokens de provedores de identidade. Não há um período de cortesia para os tokens de provedor expirados.