Visão geral de tokens e declarações

  • Artigo

Um provedor de identidade centralizado é especialmente útil para aplicativos que têm usuários em todo o mundo que não necessariamente entram na 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. Os 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 da 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 na plataforma de identidade da Microsoft.
  • Token de atualização - Como os tokens de acesso são válidos apenas por um curto 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 é emitido. O aplicativo cliente pode então trocar esse token de atualização por um novo token de acesso quando necessário. Para obter mais informações, consulte Atualizar tokens na 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 ao lado ou em vez 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 corporativos usam SAML para autenticar usuários. Para obter informações sobre asserções SAML, consulte Referência de token SAML.

Validar tokens

Cabe ao aplicativo para o qual o token foi gerado, ao aplicativo Web que entrou no usuário ou à API da Web que está sendo chamada para validar o token. 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 Aplicativos seguros e APIs validando declarações .

Recomendamos que utilize as Bibliotecas de Autenticação da Microsoft (MSAL) suportadas sempre que possível. Isso implementa a aquisição, atualização e validação de tokens para você. Ele também implementa a descoberta compatível com os padrões de configurações e chaves do locatário usando o documento de descoberta bem conhecido do OpenID do locatário. O MSAL suporta muitas arquiteturas e plataformas de aplicativos diferentes, incluindo .NET, JavaScript, Java, Python, Android e iOS.

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

Os tokens de acesso são passados para uma API da Web como o token de portador no Authorization cabeçalho. 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 foi revogado, ele receberá 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.

JSON Web Tokens e declarações

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

Uma declaração fornece asserções sobre uma entidade, como um aplicativo cliente ou proprietário de 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 JSON Web Token.

As declarações são pares de nome ou valor que transmitem fatos sobre o assunto do token. Por exemplo, uma declaração pode conter fatos sobre a entidade de segurança autenticada pelo servidor de autorização. As declarações presentes em um token específico dependem de muitas coisas, como o tipo de token, o tipo de credencial usada 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 sujeito do token
  • Apresentar informações de utilizador
  • Determinar a autorização do requerente

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)
  • Audiência, que é o aplicativo para o qual o token foi gerado
  • Aplicativo (o cliente) que pediu o token

Pontos finais 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 destinada ao uso interno e gerencia funcionários e convidados de negócios, e uma configuração de cliente otimizada para isolar consumidores e parceiros em um diretório externo restrito. Embora o serviço de identidade subjacente seja idêntico para ambas as configurações de locatário, os domínios de login e a autoridade emissora de token para locatários externos são diferentes. Isso permite que os aplicativos mantenham os fluxos de trabalho da força de trabalho e da ID externa separados, se necessário.

Os locatários da força de trabalho do Microsoft Entra são autenticados no 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ário, desde que as relações de confiança subjacentes permitam essa interoperabilidade. Os locatários externos do Microsoft Entra usam pontos de extremidade locatários do formato {tenantname}.ciamlogin.com. Os aplicativos registrados para locatários externos devem estar cientes dessa separação para receber e validar tokens corretamente.

Cada locatário do Microsoft Entra publica metadados conhecidos em conformidade 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 suportados e declarações. Para locatários externos, o documento está disponível publicamente em: https://{tenantname}.ciamlogin.com/{tenantid}/v2.0/.well-known/openid-configuration. Esse ponto de extremidade retorna um valor de 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 suportados pela plataforma de identidade da Microsoft. Os fluxos suportados podem produzir vários tokens e códigos de autorização e exigem tokens diferentes para fazê-los funcionar. A tabela a seguir fornece uma visão geral.

Fluxo Requer Token de identificação Token de acesso Atualizar token Código de autorização
Fluxo de código de autorização x x x x
Fluxo implícito x x
Fluxo OIDC híbrido x x
Atualizar resgate de token Atualizar token x x x
Fluxo em-nome-de Token de acesso x x x
Credenciais de cliente x (Apenas aplicação)

Os tokens emitidos usando o fluxo implícito têm uma limitação de comprimento porque são passados de volta para o navegador usando a URL, onde response_mode está query ou fragment. Alguns navegadores têm um limite no tamanho do URL que pode ser colocado na barra do navegador e falhar quando é muito longo. Como resultado, esses tokens não têm groups ou wids reivindicam.

Consulte também

Próximos passos