Partilhar via

O que é um token de atualização primário?

  • Artigo

Um PRT (Primary Refresh Token) é um artefato chave da autenticação do Microsoft Entra no Windows 10 ou mais recente, Windows Server 2016 e versões posteriores, dispositivos iOS e Android. É um JSON Web Token (JWT) especialmente emitido para corretores de token primários da Microsoft para habilitar o logon único (SSO) em todos os aplicativos usados nesses dispositivos. Neste artigo, forneça detalhes sobre como um PRT é emitido, usado e protegido no Windows 10 ou dispositivos mais recentes. Recomendamos usar as versões mais recentes do Windows 10, Windows 11 e Windows Server 2019+ para obter a melhor experiência de SSO.

Este artigo pressupõe que você já entenda os diferentes estados do dispositivo disponíveis no Microsoft Entra ID e como o logon único funciona no Windows 10 ou mais recente. Para obter mais informações sobre dispositivos no Microsoft Entra ID, consulte o artigo O que é o gerenciamento de dispositivos no Microsoft Entra ID?

Terminologia e componentes principais

Os seguintes componentes do Windows desempenham um papel fundamental na solicitação e uso de um PRT:

  • Provedor de autenticação na nuvem (CloudAP): o CloudAP é o provedor de autenticação moderno para login no Windows, que verifica o registro dos usuários em um dispositivo Windows 10 ou mais recente. O CloudAP fornece uma estrutura de plug-in na qual os provedores de identidade podem se basear para habilitar a autenticação no Windows usando as credenciais desse provedor de identidade.
  • Gestor de Conta Web (WAM): o WAM é o agente de token predefinido no Windows 10 ou em dispositivos mais recentes. O WAM também fornece uma estrutura de plug-in na qual os provedores de identidade podem desenvolver e habilitar o SSO para seus aplicativos que dependem desse provedor de identidade.
  • Plug-in do Microsoft Entra CloudAP: um plug-in específico do Microsoft Entra criado na estrutura do CloudAP que verifica as credenciais do usuário com o ID do Microsoft Entra durante o login do Windows.
  • Plug-in WAM do Microsoft Entra: um plug-in específico do Microsoft Entra criado na estrutura WAM que permite o SSO para aplicativos que dependem do ID do Microsoft Entra para autenticação.
  • Dsreg: um componente específico do Microsoft Entra no Windows 10 ou mais recente, que lida com o processo de registro do dispositivo para todos os estados do dispositivo.
  • TPM (Trusted Platform Module): um TPM é um componente de hardware incorporado num dispositivo que fornece funções de segurança baseadas em hardware para segredos de utilizador e dispositivo. Mais detalhes podem ser encontrados no artigo Visão geral da tecnologia do Trusted Platform Module.

O que contém o PRT?

Um PRT contém declarações encontradas na maioria dos tokens de atualização de ID do Microsoft Entra. Além disso, existem algumas reivindicações específicas do dispositivo incluídas no PRT. São os seguintes:

  • ID do dispositivo: um PRT é emitido para um usuário em um dispositivo específico. A declaração deviceID de ID do dispositivo determina o dispositivo no qual o PRT foi emitido para o usuário. Esta reivindicação é posteriormente emitida para tokens obtidos através do PRT. A declaração de ID do dispositivo é usada para determinar a autorização para Acesso Condicional com base no estado ou na conformidade do dispositivo.
  • Chave de sessão: A chave de sessão é uma chave simétrica encriptada, gerada pelo serviço de autenticação Microsoft Entra, emitida como parte do PRT. A chave de sessão atua como prova de posse quando um PRT é usado para obter tokens para outros aplicativos. A chave de sessão é rolada no Windows 10 ou em dispositivos Microsoft Entra ingressados ou híbridos do Microsoft Entra se tiver mais de 30 dias.

Posso ver o que há em um PRT?

Um PRT é um blob opaco enviado do Microsoft Entra cujo conteúdo não é conhecido por nenhum componente do cliente. Você não pode ver o que está dentro de um PRT.

Como é emitido um PRT?

O registro de dispositivo é um pré-requisito para autenticação baseada em dispositivo no Microsoft Entra ID. Um PRT é emitido para usuários apenas em dispositivos registrados. Para obter detalhes mais detalhados sobre o registo de dispositivos, consulte o artigo Windows Hello para Empresas e Registo de Dispositivos. Durante o registro do dispositivo, o componente dsreg gera dois conjuntos de pares de chaves criptográficas:

  • Chave do dispositivo (dkpub/dkpriv)
  • Chave de transporte (tkpub/tkpriv)

As chaves privadas são vinculadas ao TPM do dispositivo se o dispositivo tiver um TPM válido e funcional, enquanto as chaves públicas são enviadas para o Microsoft Entra ID durante o processo de registro do dispositivo. Essas chaves são usadas para validar o estado do dispositivo durante solicitações PRT.

O PRT é emitido durante a autenticação do usuário em um dispositivo Windows 10 ou mais recente em dois cenários:

  • Microsoft Entra ingressado ou Microsoft Entra híbrido ingressado: um PRT é emitido durante o logon do Windows quando um usuário entra com suas credenciais de organização. Um PRT é emitido com todas as credenciais suportadas do Windows 10 ou mais recentes, por exemplo, palavra-passe e Windows Hello para Empresas. Nesse cenário, o plug-in Microsoft Entra CloudAP é a principal autoridade para o PRT.
  • Dispositivo registado Microsoft Entra: um PRT é emitido quando um utilizador adiciona uma conta de trabalho secundária ao seu dispositivo Windows 10 ou mais recente. Os utilizadores podem adicionar uma conta ao Windows 10 ou mais recente de duas formas diferentes -
    • Adicionar uma conta através do prompt Permitir que minha organização gerencie meu dispositivo depois de entrar em um aplicativo (por exemplo, Outlook)
    • Adicionar uma conta a partir de Definições>Contas>de Acesso Ligação Escolar ou Profissional>

Em cenários de dispositivo registrado do Microsoft Entra, o plug-in WAM do Microsoft Entra é a principal autoridade para o PRT, uma vez que o logon do Windows não está acontecendo com essa conta do Microsoft Entra.

Observação

Provedores de identidade de terceiros precisam oferecer suporte ao protocolo WS-Trust para habilitar a emissão de PRT em dispositivos Windows 10 ou mais recentes. Sem o WS-Trust, o PRT não pode ser emitido para usuários em dispositivos de ingresso híbrido do Microsoft Entra ou de ingresso do Microsoft Entra. No AD FS, apenas os pontos de extremidade mistos de nome de usuário são necessários. No AD FS, se smartcard/certificate for usado durante o Windows, os pontos de certificatemixed extremidade de entrada são necessários. Ambos adfs/services/trust/2005/windowstransport devem adfs/services/trust/13/windowstransport ser habilitados apenas como pontos de extremidade voltados para a intranet e NÃO devem ser expostos como pontos de extremidade voltados para a extranet por meio do Proxy de Aplicativo Web.

Observação

As políticas de Acesso Condicional do Microsoft Entra não são avaliadas quando PRTs são emitidas.

Observação

Não oferecemos suporte a provedores de credenciais de terceiros para emissão e renovação de PRTs do Microsoft Entra.

Qual é o tempo de vida de um PRT?

Uma vez emitido, um PRT é válido por 14 dias e é continuamente renovado, desde que o usuário use ativamente o dispositivo.

Como se utiliza um PRT?

Um PRT é usado por dois componentes principais no Windows:

  • Plug-in do Microsoft Entra CloudAP: Durante o login do Windows, o plug-in do Microsoft Entra CloudAP solicita um PRT do ID do Microsoft Entra usando as credenciais fornecidas pelo usuário. Ele também armazena em cache o PRT para habilitar o login em cache quando o usuário não tem acesso a uma conexão com a Internet.
  • Plug-in Microsoft Entra WAM: Quando os usuários tentam acessar aplicativos, o plug-in Microsoft Entra WAM usa o PRT para habilitar o SSO no Windows 10 ou mais recente. O plug-in WAM do Microsoft Entra usa o PRT para solicitar tokens de atualização e acesso para aplicativos que dependem do WAM para solicitações de token. Ele também permite o SSO em navegadores, injetando o PRT em solicitações do navegador. O SSO do navegador no Windows 10 ou mais recente é suportado no Microsoft Edge (nativamente), Chrome (através das Contas do Windows 10 ou Mozilla Firefox v91+ (configuração Firefox Windows SSO)

    Observação

    Nos casos em que um usuário tem duas contas do mesmo locatário do Microsoft Entra conectado a um aplicativo de navegador, a autenticação de dispositivo fornecida pelo PRT da conta principal também é aplicada automaticamente à segunda conta. Como resultado, a segunda conta também satisfaz qualquer política de Acesso Condicional baseada em dispositivo no locatário.

Como é renovada uma PRT?

Um PRT é renovado em dois métodos diferentes:

  • Plug-in do Microsoft Entra CloudAP a cada 4 horas: O plug-in CloudAP renova o PRT a cada 4 horas durante o login do Windows. Se o usuário não tiver conexão com a Internet durante esse tempo, o plug-in CloudAP renovará o PRT depois que o dispositivo estiver conectado à internet.
  • Plug-in WAM do Microsoft Entra durante solicitações de token de aplicativo: o plug-in WAM habilita o SSO em dispositivos Windows 10 ou mais recentes, habilitando solicitações de token silenciosas para aplicativos. O plug-in WAM pode renovar o PRT durante essas solicitações de token de duas maneiras diferentes:
    • Um aplicativo solicita WAM para um token de acesso silenciosamente, mas não há nenhum token de atualização disponível para esse aplicativo. Nesse caso, o WAM usa o PRT para solicitar um token para o aplicativo e recebe de volta um novo PRT na resposta.
    • Um aplicativo solicita WAM para um token de acesso, mas o PRT é inválido ou o Microsoft Entra ID requer autorização extra (por exemplo, autenticação multifator do Microsoft Entra). Nesse cenário, o WAM inicia um logon interativo exigindo que o usuário se autentique novamente ou forneça verificação extra e um novo PRT é emitido na autenticação bem-sucedida.

Em um ambiente AD FS, a linha de visão direta para o controlador de domínio não é necessária para renovar o PRT. A renovação PRT requer apenas /adfs/services/trust/2005/usernamemixed pontos de /adfs/services/trust/13/usernamemixed extremidade habilitados no proxy usando o protocolo WS-Trust.

Os pontos de extremidade de transporte do Windows são necessários para autenticação de senha somente quando uma senha é alterada, não para renovação de PRT.

Observação

As políticas de Acesso Condicional do Microsoft Entra não são avaliadas quando as PRTs são renovadas.

Principais considerações

  • Nos dispositivos Microsoft Entra unido e Microsoft Entra híbrido, o plug-in CloudAP é a principal autoridade para um PRT. Se um PRT for renovado durante uma solicitação de token baseada em WAM, o PRT será enviado de volta para o plug-in CloudAP, que verifica a validade do PRT com o Microsoft Entra ID antes de aceitá-lo.

Plataforma Android:

  • Um PRT é válido por 90 dias e é continuamente renovado enquanto o dispositivo estiver em uso. No entanto, só é válido por 14 dias se o dispositivo não estiver em uso.
  • Um PRT só é emitido e renovado durante a autenticação nativa do aplicativo. Um PRT não é renovado ou emitido durante uma sessão do navegador.
  • É possível obter um PRT sem a necessidade de registro de dispositivo (Ingresso no Local de Trabalho) e habilitar o SSO.
  • Os PRTs obtidos sem o registro do dispositivo não podem satisfazer os critérios de autorização para Acesso Condicional que dependem do status ou da conformidade do dispositivo.

Como é protegida a PRT?

Um PRT é protegido ligando-o ao dispositivo no qual o usuário entrou. O Microsoft Entra ID e o Windows 10 ou mais recente habilitam a proteção PRT através dos seguintes métodos:

  • Durante o primeiro login: Durante o primeiro login, um PRT é emitido assinando solicitações usando a chave do dispositivo gerada criptograficamente durante o registro do dispositivo. Em um dispositivo com um TPM válido e funcional, a chave do dispositivo é protegida pelo TPM impedindo qualquer acesso mal-intencionado. Um PRT não é emitido se a assinatura da chave de dispositivo correspondente não puder ser validada.
  • Durante solicitações de token e renovação: Quando um PRT é emitido, o Microsoft Entra ID também emite uma chave de sessão criptografada para o dispositivo. É encriptado com a chave de transporte público (tkpub) gerada e enviada para o Microsoft Entra ID como parte do registo do dispositivo. Esta chave de sessão só pode ser desencriptada pela chave de transporte privada (tkpriv) protegida pelo TPM. A chave de sessão é a chave POP (Proof-of-Possess) para quaisquer solicitações enviadas ao Microsoft Entra ID. A chave de sessão também é protegida pelo TPM e nenhum outro componente do sistema operacional pode acessá-la. As solicitações de token ou solicitações de renovação PRT são assinadas com segurança por essa chave de sessão através do TPM e, portanto, não podem ser adulteradas. O Microsoft Entra invalida quaisquer solicitações do dispositivo que não estejam assinadas pela chave de sessão correspondente.

Ao proteger essas chaves com o TPM, aumentamos a segurança para PRT de atores mal-intencionados que tentam roubar as chaves ou reproduzir o PRT. Assim, usar um TPM aumenta muito a segurança do Microsoft Entra juntou, Microsoft Entra híbrido juntou, e Microsoft Entra dispositivos registrados contra roubo de credenciais. Para desempenho e confiabilidade, o TPM 2.0 é a versão recomendada para todos os cenários de registro de dispositivo Microsoft Entra no Windows 10 ou mais recente. A partir da atualização do Windows 10, 1903, o Microsoft Entra ID não usa o TPM 1.2 para nenhuma das chaves acima devido a problemas de confiabilidade.

Como os tokens de aplicativos e cookies do navegador são protegidos?

Tokens de aplicativo: quando um aplicativo solicita token por meio do WAM, o ID do Microsoft Entra emite um token de atualização e um token de acesso. No entanto, o WAM retorna apenas o token de acesso ao aplicativo e protege o token de atualização em seu cache criptografando-o com a chave DPAPI (Data Protection Application Programming Interface) do usuário. O WAM usa com segurança o token de atualização assinando solicitações com a chave de sessão para emitir mais tokens de acesso. A chave DPAPI é protegida por uma chave simétrica baseada em ID do Microsoft Entra no próprio Microsoft Entra. Quando o dispositivo precisa descriptografar o perfil de usuário com a chave DPAPI, o Microsoft Entra ID fornece a chave DPAPI criptografada pela chave de sessão, que o plug-in CloudAP solicita que o TPM descriptografe. Essa funcionalidade garante consistência na proteção de tokens de atualização e evita que os aplicativos implementem seus próprios mecanismos de proteção.

Cookies do navegador: No Windows 10 ou mais recente, o Microsoft Entra ID suporta o SSO do navegador no Internet Explorer e no Microsoft Edge nativamente, no Google Chrome através da extensão de contas do Windows 10 e no Mozilla Firefox v91+ através de uma configuração do navegador. A segurança é construída não só para proteger os cookies, mas também os pontos finais para os quais os cookies são enviados. Os cookies do navegador são protegidos da mesma forma que um PRT, utilizando a chave de sessão para assinar e proteger os cookies.

Quando um usuário inicia uma interação do navegador, o navegador (ou extensão) invoca um host de cliente nativo COM. O host do cliente nativo garante que a página seja de um dos domínios permitidos. O navegador pode enviar outros parâmetros para o host do cliente nativo, incluindo um nonce, no entanto, o host do cliente nativo garante a validação do nome do host. O host do cliente nativo solicita um cookie PRT do plug-in CloudAP, que o cria e assina com a chave de sessão protegida pelo TPM. Como o cookie PRT é assinado pela chave de sessão, é difícil adulterá-lo. Este cookie PRT está incluído no cabeçalho de pedido para o Microsoft Entra ID validar o dispositivo de onde é originário. Se estiver usando o navegador Chrome, somente a extensão explicitamente definida no manifesto do host do cliente nativo poderá invocá-la, impedindo que extensões arbitrárias façam essas solicitações. Assim que o Microsoft Entra ID valida o cookie PRT, emite um cookie de sessão para o navegador. Este cookie de sessão também contém a mesma chave de sessão emitida com um PRT. Durante solicitações subsequentes, a chave de sessão é validada efetivamente vinculando o cookie ao dispositivo e impedindo repetições de outro lugar.

Quando é que um PRT recebe um pedido de AMF?

Um PRT pode obter uma declaração de autenticação multifator em cenários específicos. Quando um PRT baseado em MFA é usado para solicitar tokens para aplicativos, a declaração de MFA é transferida para esses tokens de aplicativo. Essa funcionalidade fornece uma experiência perfeita aos usuários, evitando o desafio de MFA para cada aplicativo que o exige. Um PRT pode obter uma reivindicação de MFA das seguintes maneiras:

  • Entrar com o Windows Hello for Business: o Windows Hello for Business substitui senhas e usa chaves criptográficas para fornecer autenticação forte de dois fatores. O Windows Hello for Business é específico para um usuário em um dispositivo e requer MFA para provisionamento. Quando um usuário faz login com o Windows Hello for Business, o PRT do usuário recebe uma declaração de MFA. Este cenário também se aplica aos utilizadores que iniciam sessão com cartões inteligentes se a autenticação de cartão inteligente produzir uma declaração MFA do AD FS.
    • Como o Windows Hello for Business é considerado autenticação multifator, a declaração MFA é atualizada quando o próprio PRT é atualizado, portanto, a duração do MFA se estenderá continuamente quando os usuários entrarem com o Windows Hello for Business.
  • MFA durante o login interativo do WAM: durante uma solicitação de token por meio do WAM, se um usuário for obrigado a fazer MFA para acessar o aplicativo, o PRT renovado durante essa interação será impresso com uma declaração de MFA.
    • Nesse caso, a declaração de MFA não é atualizada continuamente, portanto, a duração da MFA é baseada no tempo de vida definido no diretório.
    • Quando um PRT e RT existentes anteriormente são usados para acessar um aplicativo, o PRT e o RT são considerados como a primeira prova de autenticação. É necessário um novo IR com uma segunda prova e uma reivindicação de MFA impressa. Este processo também emite um novo PRT e RT.

O Windows 10 ou mais recente mantém uma lista particionada de PRTs para cada credencial. Portanto, há um PRT para cada Windows Hello for Business, senha ou cartão inteligente. Esse particionamento garante que as declarações de MFA sejam isoladas com base na credencial usada e não misturadas durante solicitações de token.

Observação

Ao usar a senha para entrar no Windows 10 ou mais recente Microsoft Entra ingressou ou dispositivo híbrido Microsoft Entra, MFA durante o logon interativo WAM pode ser necessário depois que a chave de sessão associada ao PRT é rolada.

Como um PRT é invalidado?

Um PRT é invalidado nos seguintes cenários:

  • Usuário inválido: Se um usuário for excluído ou desabilitado no Microsoft Entra ID, seu PRT será invalidado e não poderá ser usado para obter tokens para aplicativos. Se um usuário excluído ou desativado já tiver entrado em um dispositivo antes, o login armazenado em cache fará login nele, até que o CloudAP esteja ciente de seu estado inválido. Quando o CloudAP determina que o usuário é inválido, ele bloqueia logons subsequentes. Um usuário inválido é automaticamente impedido de entrar em novos dispositivos que não têm suas credenciais armazenadas em cache.
  • Dispositivo inválido: Se um dispositivo for excluído ou desativado no Microsoft Entra ID, o PRT obtido nesse dispositivo será invalidado e não poderá ser usado para obter tokens para outros aplicativos. Se um utilizador já tiver sessão iniciada num dispositivo inválido, pode continuar a fazê-lo. Mas todos os tokens no dispositivo são invalidados e o usuário não tem SSO para nenhum recurso desse dispositivo.
  • Alteração de senha: Se um usuário obteve o PRT com sua senha, o PRT é invalidado pelo ID do Microsoft Entra quando o usuário altera sua senha. A alteração de senha resulta na obtenção de um novo PRT pelo usuário. Esta invalidação pode acontecer de duas formas diferentes:
    • Se o usuário entrar no Windows com sua nova senha, o CloudAP descartará o PRT antigo e solicitará que o Microsoft Entra ID emita um novo PRT com sua nova senha. Se o usuário não tiver uma conexão com a Internet, a nova senha não poderá ser validada, o Windows pode exigir que o usuário insira sua senha antiga.
    • Se um utilizador tiver iniciado sessão com a sua palavra-passe antiga ou alterado a sua palavra-passe depois de iniciar sessão no Windows, o PRT antigo é utilizado para quaisquer pedidos de token baseados em WAM. Nesse cenário, o usuário é solicitado a autenticar novamente durante a solicitação de token WAM e um novo PRT é emitido.
  • Problemas de TPM: Às vezes, o TPM de um dispositivo pode vacilar ou falhar, levando à inacessibilidade das chaves protegidas pelo TPM. Neste caso, o dispositivo é incapaz de obter um PRT ou solicitar tokens usando um PRT existente, pois não pode provar a posse das chaves criptográficas. Como resultado, qualquer PRT existente é invalidado pelo Microsoft Entra ID. Quando o Windows 10 deteta uma falha, ele inicia um fluxo de recuperação para registrar novamente o dispositivo com novas chaves criptográficas. Com a junção híbrida do Microsoft Entra, assim como o registro inicial, a recuperação acontece silenciosamente sem a entrada do usuário. Para dispositivos registrados do Microsoft Entra ou do Microsoft Entra, a recuperação precisa ser executada por um usuário que tenha privilégios de administrador no dispositivo. Nesse cenário, o fluxo de recuperação é iniciado por um prompt do Windows que orienta o usuário a recuperar com êxito o dispositivo.

Fluxos detalhados

Os diagramas a seguir ilustram os detalhes subjacentes na emissão, renovação e uso de um PRT para solicitar um token de acesso para um aplicativo. Além disso, essas etapas também descrevem como os mecanismos de segurança acima mencionados são aplicados durante essas interações.

Emissão de PRT durante o primeiro login

Emissão de PRT durante o primeiro sinal no fluxo detalhado

Observação

Nos dispositivos associados do Microsoft Entra, a emissão do Microsoft Entra PRT (etapas A-F) acontece de forma síncrona antes que o usuário possa entrar no Windows. Nos dispositivos associados híbridos do Microsoft Entra, o Ative Directory local é a autoridade principal. Assim, o usuário é capaz de fazer login no Microsoft Entra híbrido do Windows depois de adquirir um TGT para fazer login, enquanto a emissão do PRT acontece de forma assíncrona. Este cenário não se aplica aos dispositivos registados do Microsoft Entra, uma vez que o início de sessão não utiliza as credenciais do Microsoft Entra.

Observação

Em um ambiente Windows híbrido do Microsoft Entra, a emissão do PRT ocorre de forma assíncrona. A emissão do PRT pode falhar devido a problemas com o provedor de federação. Essa falha pode resultar em problemas de logon quando os usuários tentam acessar recursos de nuvem. É importante solucionar esse cenário com o provedor de federação.

Passo Descrição
Um O usuário insere sua senha na interface do usuário de login. LogonUI passa as credenciais em um buffer de autenticação para LSA, que por sua vez passa internamente para o CloudAP. O CloudAP encaminha essa solicitação para o plug-in do CloudAP.
B O plug-in do CloudAP inicia uma solicitação de descoberta de território para identificar o provedor de identidade do usuário. Se o locatário do usuário tiver uma configuração de provedor de federação, a ID do Microsoft Entra retornará o ponto de extremidade MEX (Metadata Exchange) do provedor de federação. Caso contrário, a ID do Microsoft Entra retorna que o usuário é gerenciado, indicando que o usuário pode se autenticar com a ID do Microsoft Entra.
C Se o usuário for gerenciado, o CloudAP obterá o nonce do ID do Microsoft Entra. Se o usuário for federado, o plug-in do CloudAP solicitará um token SAML (Security Assertion Markup Language) do provedor de federação com as credenciais do usuário. O Nonce é solicitado antes que o token SAML seja enviado para o Microsoft Entra ID.
D O plug-in CloudAP constrói a solicitação de autenticação com as credenciais do usuário, nonce e um escopo de broker, assina a solicitação com a chave Device (dkpriv) e a envia para o Microsoft Entra ID. Em um ambiente federado, o plug-in CloudAP usa o token SAML retornado pelo provedor de federação em vez das credenciais do usuário.
E O Microsoft Entra ID valida as credenciais do usuário, o nonce e a assinatura do dispositivo, verifica se o dispositivo é válido no locatário e emite o PRT criptografado. Junto com o PRT, o Microsoft Entra ID também emite uma chave simétrica, chamada de chave de sessão criptografada pelo Microsoft Entra ID usando a chave de transporte (tkpub). Além disso, a chave Session também está incorporada no PRT. Essa chave de sessão atua como a chave de prova de posse (PoP) para solicitações subsequentes com o PRT.
F O plug-in CloudAP passa o PRT criptografado e a chave de sessão para o CloudAP. O CloudAP solicita que o TPM descriptografe a chave de sessão usando a chave de transporte (tkpriv) e criptografe-a novamente usando a própria chave do TPM. O CloudAP armazena a chave de sessão criptografada em seu cache junto com o PRT.

Renovação de PRT em logons subsequentes

Renovação de PRT em logons subsequentes

Passo Descrição
Um O usuário insere sua senha na interface do usuário de login. LogonUI passa as credenciais em um buffer de autenticação para LSA, que por sua vez passa internamente para o CloudAP. O CloudAP encaminha essa solicitação para o plug-in do CloudAP.
B Se o usuário tiver entrado anteriormente na sessão, o Windows iniciará a entrada em cache e validará as credenciais para fazer logon do usuário. A cada 4 horas, o plug-in CloudAP inicia a renovação do PRT de forma assíncrona.
C O plug-in do CloudAP inicia uma solicitação de descoberta de território para identificar o provedor de identidade do usuário. Se o locatário do usuário tiver uma configuração de provedor de federação, a ID do Microsoft Entra retornará o ponto de extremidade MEX (Metadata Exchange Point) do provedor de federação. Caso contrário, a ID do Microsoft Entra retorna que o usuário é gerenciado, indicando que o usuário pode se autenticar com a ID do Microsoft Entra.
D Se o usuário for federado, o plug-in do CloudAP solicitará um token SAML do provedor de federação com as credenciais do usuário. O Nonce é solicitado antes que o token SAML seja enviado para o Microsoft Entra ID. Se o usuário for gerenciado, o CloudAP obterá diretamente o nonce do Microsoft Entra ID.
E O plug-in CloudAP constrói a solicitação de autenticação com as credenciais do usuário, nonce e o PRT existente, assina a solicitação com a chave de sessão e a envia para o Microsoft Entra ID. Em um ambiente federado, o plug-in CloudAP usa o token SAML retornado pelo provedor de federação em vez das credenciais do usuário.
F O Microsoft Entra ID valida a assinatura da chave de sessão comparando-a com a chave de sessão incorporada no PRT, valida o nonce e verifica se o dispositivo é válido no locatário e emite um novo PRT. Como visto anteriormente, o PRT é novamente acompanhado com a chave de sessão criptografada pela chave de transporte (tkpub).
G O plug-in CloudAP passa o PRT criptografado e a chave de sessão para o CloudAP. O CloudAP solicita que o TPM descriptografe a chave de sessão usando a chave de transporte (tkpriv) e criptografe-a novamente usando a própria chave do TPM. O CloudAP armazena a chave de sessão criptografada em seu cache junto com o PRT.

Observação

Um PRT pode ser renovado externamente sem a necessidade de uma conexão VPN quando os pontos de extremidade mistos de nome de usuário são habilitados externamente.

Uso de PRT durante solicitações de token de aplicativo

Uso de PRT durante solicitações de token de aplicativo

Passo Descrição
Um Um aplicativo (por exemplo, Outlook, OneNote e assim por diante.) inicia uma solicitação de token para o WAM. O WAM, por sua vez, pede ao plug-in WAM do Microsoft Entra para atender a solicitação de token.
B Se um token de atualização para o aplicativo já estiver disponível, o plug-in Microsoft Entra WAM o usará para solicitar um token de acesso. Para fornecer prova de vinculação de dispositivo, o plug-in WAM assina a solicitação com a chave de sessão. O Microsoft Entra ID valida a chave de sessão e emite um token de acesso e um novo token de atualização para o aplicativo, criptografado pela chave de sessão. O plug-in WAM solicita o plug-in CloudAP para descriptografar os tokens, que, por sua vez, solicita que o TPM descriptografe usando a chave de sessão, resultando no plug-in WAM recebendo ambos os tokens. Em seguida, o plug-in WAM fornece apenas o token de acesso ao aplicativo, enquanto criptografa novamente o token de atualização com DPAPI e o armazena em seu próprio cache
C Se um token de atualização para o aplicativo não estiver disponível, o plug-in WAM do Microsoft Entra usará o PRT para solicitar um token de acesso. Para fornecer prova de posse, o plugin WAM assina a solicitação contendo o PRT com a chave de sessão. O Microsoft Entra ID valida a assinatura da chave de sessão comparando-a com a chave de sessão incorporada no PRT, verifica se o dispositivo é válido e emite um token de acesso e um token de atualização para o aplicativo. além disso, o Microsoft Entra ID pode emitir um novo PRT (baseado no ciclo de atualização), todos eles criptografados pela chave de sessão.
D O plug-in WAM solicita o plug-in CloudAP para descriptografar os tokens, que, por sua vez, solicita que o TPM descriptografe usando a chave de sessão, resultando no plug-in WAM recebendo ambos os tokens. Em seguida, o plug-in WAM fornece apenas o token de acesso ao aplicativo, enquanto criptografa novamente o token de atualização com DPAPI e o armazena em seu próprio cache. O plug-in WAM usa o token de atualização daqui para frente para este aplicativo. O plug-in WAM também devolve o novo plug-in PRT para CloudAP, que valida o PRT com o ID do Microsoft Entra antes de atualizá-lo em seu próprio cache. O plugin CloudAP usa o novo PRT no futuro.
E O WAM fornece o token de acesso recém-emitido para o WAM, que, por sua vez, o fornece de volta ao aplicativo de chamada

SSO do navegador usando PRT

SSO do navegador usando PRT

Passo Descrição
Um O utilizador inicia sessão no Windows com as suas credenciais para obter um PRT. Uma vez que o usuário abre o navegador, o navegador (ou extensão) carrega as URLs do registro.
B Quando um usuário abre uma URL de login do Microsoft Entra, o navegador ou extensão valida a URL com as obtidas do registro. Se corresponderem, o navegador invoca o host do cliente nativo para obter um token.
C O host do cliente nativo valida que as URLs pertencem aos provedores de identidade da Microsoft (conta da Microsoft ou ID do Microsoft Entra), extrai um nonce enviado da URL e faz uma chamada para o plug-in CloudAP para obter um cookie PRT.
D O plug-in CloudAP cria o cookie PRT, faz login com a chave de sessão vinculada ao TPM e a envia de volta para o host do cliente nativo.
E O host do cliente nativo retorna esse cookie PRT para o navegador, que o inclui como parte do cabeçalho de solicitação chamado x-ms-RefreshTokenCredential e tokens de solicitação do Microsoft Entra ID.
F O Microsoft Entra ID valida a assinatura da chave de sessão no cookie PRT, valida o nonce, verifica se o dispositivo é válido no locatário e emite um token de ID para a página da Web e um cookie de sessão criptografado para o navegador.

Observação

O fluxo de SSO do navegador descrito nas etapas anteriores não se aplica a sessões em modos privados, como InPrivate no Microsoft Edge, anônimo no Google Chrome (ao usar a extensão Contas da Microsoft) ou no modo privado no Mozilla Firefox v91+

Próximos passos

Para obter mais informações sobre como solucionar problemas relacionados ao PRT, consulte o artigo Solução de problemas do Microsoft Entra híbrido associado ao Windows 10 ou mais recente e dispositivos Windows Server 2016.