Visão geral de tokens e declarações

Um provedor de identidade centralizado é útil principalmente para aplicativos que têm usuários localizados em todo o mundo e cujos usuários não necessariamente se conectam a partir da rede da empresa. A plataforma de identidade da Microsoft autentica usuários e fornece tokens de segurança como tokens de acesso, tokens de atualização e tokens de ID. Tokens de segurança permitem que um aplicativo cliente acesse recursos protegidos em um servidor de recursos.

• Token de acesso - Um token de acesso é um token de segurança emitido por um servidor de autorização como parte de um fluxo OAuth 2.0. Ele contém informações sobre o usuário e o recurso para o qual o token se destina. As informações podem ser usadas para acessar APIs Web e outros recursos protegidos. Os recursos validam tokens de acesso para conceder acesso a um aplicativo cliente. Para obter mais informações, consulte Tokens de acesso no plataforma de identidade da Microsoft.
• Token de atualização - Como os tokens de acesso são válidos apenas por um breve período de tempo, os servidores de autorização às vezes emitem um token de atualização ao mesmo tempo em que o token de acesso for emitido. O aplicativo cliente pode trocar esse token de atualização por um novo token de acesso quando necessário. Para obter mais informações, consulte Atualizar tokens no plataforma de identidade da Microsoft.
• Token de ID – Os tokens de ID são enviados para o aplicativo cliente como parte de um fluxo do OpenID Connect. Eles podem ser enviados junto ou no lugar de um token de acesso. Os tokens de ID são usados pelo cliente para autenticar o usuário. Para saber mais sobre como a plataforma de identidade da Microsoft emite tokens de ID, consulte Tokens de ID na plataforma de identidade da Microsoft.

Muitos aplicativos empresariais usam o SAML para autenticar usuários. Para obter informações sobre declarações SAML, confira referência de token SAML.

Validar tokens

A validação do token cabe ao aplicativo para o qual o token foi gerado, ao aplicativo Web que fez a entrada do usuário ou à API Web que está sendo chamada. O servidor de autorização assina o token com uma chave privada. O servidor de autorização publica a chave pública correspondente. Para validar um token, o aplicativo verifica a assinatura usando a chave pública do servidor de autorização para validar que a assinatura foi criada usando a chave privada. Para obter mais informações, consulte o artigo Proteger aplicativos e APIs validando reclamações.

Recomendamos que você use as bibliotecas de autenticação da Microsoft (MSAL) sempre que possível. Isso implementa a aquisição, renovação e validação de tokens para você. Implementa também a descoberta compatível com padrões de configurações e chaves do locatário usando o documento de descoberta bem conhecido do OpenID do locatário. O MSAL dá suporte a várias arquiteturas e plataformas de aplicativos diferentes, incluindo .NET, JavaScript, Java, Python, Android e iOS.

Os tokens são válidos por apenas um período limitado de tempo, portanto, o servidor de autorização frequentemente fornece um par de tokens. Um token de acesso é fornecido, que acessa o aplicativo ou recurso protegido. Um token de atualização é fornecido, que é usado para atualizar o token de acesso quando este está perto de expirar.

Tokens de acesso são transmitidos para uma API da Web como o token de portador no cabeçalho Authorization. Um aplicativo pode fornecer um token de atualização para o servidor de autorização. Se o acesso do usuário ao aplicativo não tiver sido revogado, ele recebe um novo token de acesso e um novo token de atualização. Quando o servidor de autorização recebe o token de atualização, ele emite outro token de acesso somente se o usuário ainda estiver autorizado.

Tokens Web JSON e declarações

A plataforma de identidade da Microsoft implementa tokens de segurança como tokens Web JSON (JWTs) que contêm declarações. Como JWTs são usados como tokens de segurança, essa forma de autenticação é chamada, às vezes, de autenticação JWT.

Uma declaração fornece instruções assert sobre uma entidade, como um aplicativo cliente ou proprietário do recurso, para outra entidade, como um servidor de recursos. Uma declaração também pode ser referida como uma declaração JWT ou uma declaração de token Web JSON.

As declarações são pares de nomes ou valores que retransmitem fatos sobre o assunto do token. Por exemplo, uma declaração pode conter fatos sobre a entidade de segurança que o servidor de autorização autenticou. As declarações presentes em um token específico dependem de muitas coisas, como o tipo de token, o tipo de credencial usado para autenticar o assunto e a configuração do aplicativo.

Os aplicativos podem usar declarações para as seguintes tarefas:

• Validar o token
• Identificar o locatário do assunto do token
• Exibir informações do usuário
• Determinar a autorização da entidade

Uma declaração consiste em pares chave-valor que fornecem os seguintes tipos de informações:

• Servidor de token de segurança que gerou o token
• Data em que o token foi gerado
• Assunto (como o usuário, mas não daemons)
• Público, que é o aplicativo para o qual o token foi gerado
• Aplicativo (o cliente) que solicitou o token

Pontos de extremidade e emissores de token

O Microsoft Entra ID oferece suporte a duas configurações de locatário: uma configuração de força de trabalho que é destinada ao uso interno e gerencia funcionários e convidados de negócios e uma configuração de cliente que é otimizada para isolar consumidores e parceiros em um diretório restrito voltado para o exterior. Embora o serviço de identidade subjacente seja idêntico para as duas configurações de locatário, os domínios de logon e a autoridade de emissão de token para locatários externos são diferentes. Isso permite que os aplicativos mantenham a força de trabalho e os fluxos de trabalho de identificação externos separados, se necessário.

Os locatários da força de trabalho do Microsoft Entra se autenticam em login.microsoftonline.com com tokens emitidos pela sts.windows.net. Os tokens de locatário da força de trabalho geralmente são intercambiáveis entre locatários e aplicativos multilocatários, desde que as relações de confiança subjacentes permitam essa interoperabilidade. Os locatários externos do Microsoft Entra usam pontos de extremidade de locatários do formulário {tenantname}.ciamlogin.com. Os aplicativos registrados em locatários externos devem estar cientes dessa separação para receber e validar tokens corretamente.

Cada locatário do Microsoft Entra publica metadados conhecidos e compatíveis com os padrões. Este documento contém informações sobre o nome do emissor, os pontos de extremidade de autenticação e autorização, escopos e reclamações com suporte. Para locatários externos, o documento está disponível publicamente em: https://{tenantname}.ciamlogin.com/{tenantid}/v2.0/.well-known/openid-configuration. Este ponto de extremidade retorna um valor emissor https://{tenantid}.ciamlogin.com/{tenantid}/v2.0.

Fluxos de autorização e códigos de autenticação

Dependendo de como o cliente é criado, ele pode usar um ou vários dos fluxos de autenticação compatíveis com a plataforma de identidade da Microsoft. Os fluxos compatíveis podem produzir vários tokens e códigos de autorização e exigir diferentes tokens para que funcionem. A tabela a seguir fornece uma visão geral.

Confira também

• OAuth 2.0
• OpenID Connect

Próximas etapas

• Para saber mais sobre os conceitos básicos de autenticação e autorização, veja Autenticação versus autorização.