Trabalhar com tokens OAuth na autenticação do Serviço de Aplicativo do Azure
Este artigo mostra como trabalhar com tokens OAuth ao usar a autenticação e autorização internas no Serviço de Aplicativo.
Recuperar tokens no código do aplicativo
A partir do código do 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 possíveis nomes de cabeçalho de token:
| Provider | Nomes de cabeçalhos |
|---|---|
| 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 |
| Facebook Token | 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 |
Nota
Diferentes estruturas de linguagem podem apresentar esses cabeçalhos para o código do aplicativo em formatos diferentes, como minúsculas ou minúsculas.
A partir do código do cliente (como um aplicativo móvel ou JavaScript no navegador), envie uma solicitação HTTP GET para /.auth/me (o armazenamento de tokens deve estar habilitado). O JSON retornado tem os tokens específicos do provedor.
Nota
Os tokens de acesso são para acessar recursos do provedor, portanto, eles estão presentes somente se você configurar seu provedor com um segredo de cliente. Para ver como obter tokens de atualização, consulte Atualizar tokens de acesso.
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 usá-lo novamente. Você pode evitar a expiração do token fazendo uma GET chamada para o /.auth/refresh ponto de extremidade do seu aplicativo. Quando chamado, o Serviço de Aplicativo atualiza automaticamente os tokens de acesso no repositório de tokens para o usuário autenticado. As solicitações subsequentes de tokens pelo código do seu aplicativo obtêm os tokens atualizados. No entanto, para que a atualização de token funcione, o armazenamento de tokens deve conter tokens de atualização para seu provedor. A maneira de obter tokens de atualização é documentada por cada provedor, mas a lista a seguir é um breve resumo:
Google: Anexe um
access_type=offlineparâmetro de cadeia de caracteres de consulta à sua/.auth/login/googlechamada de API. Para obter mais informações, consulte Google Refresh Tokens.Facebook: não fornece tokens de atualização. Os tokens de longa duração expiram em 60 dias (consulte Expiração e extensão de tokens de acesso do Facebook).
X: Os tokens de acesso não expiram (consulte as Perguntas frequentes do OAuth).
Microsoft: No https://resources.azure.com, execute as seguintes etapas:
Na parte superior da página, selecione Leitura/Gravação.
No navegador esquerdo, navegue até assinaturas<>subscription_name>>resourceGroups><resource_group_name>>provedores>Microsoft.Web>sites<>app_name>>config>authsettingsV2.
Clique em Editar.
Modifique a seguinte propriedade.
"identityProviders": { "azureActiveDirectory": { "login": { "loginParameters": ["scope=openid profile email offline_access"] } } }Clique em Colocar.
Nota
O escopo que lhe dá um token de atualização é offline_access. Veja como ele é usado em Tutorial: 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 no repositório de tokens.
Para atualizar seu token de acesso a qualquer momento, basta ligar /.auth/refresh em qualquer idioma. O trecho a seguir usa 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 revogar as permissões concedidas ao seu aplicativo, sua chamada para /.auth/me poderá falhar com uma 403 Forbidden resposta. Para diagnosticar erros, verifique os logs do aplicativo para obter detalhes.
Estender o período de carência de expiração do token de sessão
A sessão autenticada expira após 8 horas. Depois que uma sessão autenticada expira, há um período de carência de 72 horas por padrão. Dentro desse período de carência, você tem permissão para atualizar o token de sessão com o Serviço de Aplicativo sem autenticar novamente o usuário. Você pode simplesmente ligar /.auth/refresh quando seu token de sessão se tornar inválido, e você não precisa acompanhar a expiração do token por conta própria. Quando o período de carência de 72 horas expirar, o usuário deve entrar novamente para obter um token de sessão válido.
Se 72 horas não for tempo suficiente para si, pode prolongar esta janela de expiração. Estender a expiração por um longo período pode ter implicações de segurança significativas (como quando um token de autenticação é vazado ou roubado). Portanto, você deve deixá-lo no padrão 72 horas ou definir o período de extensão para o menor valor.
Para estender a janela de expiração 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>
Nota
O período de carência só se aplica à sessão autenticada do Serviço de Aplicativo, não aos tokens dos provedores de identidade. Não há período de carência para os tokens de provedor expirados.