Noções básicas sobre o PRT (Primary Refresh Token)

Artigo
03/11/2025

Um PRT (Primary Refresh Token) é um artefato chave da autenticação do Microsoft Entra em versões suportadas do Windows, iOS e Android. Este artigo explica como um PRT é emitido, usado e protegido no Windows 10 ou em dispositivos mais recentes, aprimorando sua segurança e habilitando o logon único (SSO) entre aplicativos.

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. Para obter mais informações sobre dispositivos no Microsoft Entra ID, consulte 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 que se encontram na maioria dos tokens de atualização do Microsoft Entra ID. Além disso, existem algumas afirmaçõ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 declaraçã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 é renovada em dispositivos com Windows 10 ou mais recentes, que estejam ingressados no Microsoft Entra ou híbridos do Microsoft Entra, caso seja mais antiga que 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 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 associado ou Microsoft Entra híbrido associado: um PRT é emitido durante o logon do Windows quando um utilizador inicia sessão com as suas credenciais da 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 plugin 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 da mensagem Permitir que a minha organização gerencie o meu dispositivo depois de fazer login em uma aplicação (por exemplo, Outlook)
- Adicionar uma conta a partir de Definições>Contas>Aceder ao Trabalho ou à Escola>Conectar

Em cenários de dispositivos registados no Microsoft Entra, o plug-in WAM do Microsoft Entra é a principal autoridade para o PRT, pois o logon do Windows não ocorre com essa conta do Microsoft Entra.

Nota

Os provedores de identidade que não são da Microsoft 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, um PRT não pode ser emitido para utilizadores em dispositivos híbridos associados ao Microsoft Entra ou associados ao 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 a entrada no Windows, os endpoints de certificatemixed são necessários. Ambos adfs/services/trust/2005/windowstransport e adfs/services/trust/13/windowstransport devem 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 através do Proxy de Aplicação Web.

Nota

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

Nota

Não oferecemos suporte a provedores de credenciais que não sejam da Microsoft 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 Microsoft Entra CloudAP: Durante o início de sessão no Windows, o plug-in Microsoft Entra CloudAP solicita um PRT do Microsoft Entra ID usando as credenciais fornecidas pelo utilizador. 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 de SSO do Firefox no Windows)

Nota

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 de duas maneiras diferentes:

Plug-in do Microsoft Entra CloudAP a cada 4 horas: O plug-in CloudAP renova o PRT a cada 4 horas durante o início de sessão 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 e um novo login do Windows for feito.
Plug-in WAM do Microsoft Entra durante solicitações de token de aplicativo: o plug-in WAM permite o SSO em dispositivos Windows 10 ou mais recentes, permitindo requisições silenciosas de token 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 os endpoints /adfs/services/trust/2005/usernamemixed e /adfs/services/trust/13/usernamemixed habilitados no proxy usando o protocolo WS-Trust.

Os endpoints 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.

Nota

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

Considerações principais

Nos dispositivos Microsoft Entra unidos e Microsoft Entra híbridos, 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 de Prova de Posse (POP) para quaisquer solicitações enviadas para o 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 estas chaves com o TPM, aumentamos a segurança do PRT contra atores mal-intencionados que tentam roubar as chaves ou reproduzir o PRT. Assim, o uso de um TPM aumenta significativamente a segurança de dispositivos associados ao Microsoft Entra, associados híbridos ao Microsoft Entra e registados no Microsoft Entra contra o 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. Após a 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 da aplicação: quando uma aplicação solicita tokens através do WAM, o Microsoft Entra ID 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 que o Microsoft Entra ID valide o dispositivo de onde se originou. 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 utilizador em um dispositivo e, ele próprio, 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 RT com uma segunda prova e uma reivindicação de Autenticação Multi-Fator 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 um dos seguintes: 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.

Nota

Ao utilizar uma senha para iniciar sessão num dispositivo com Windows 10 ou mais recente, associado ao Microsoft Entra ou híbrido com o Microsoft Entra, a autenticação multifator (MFA) durante o início de sessão interativo do WAM poderá ser necessária após a rotação da chave de sessão associada ao PRT.

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 associados ao Microsoft Entra ou registrados no Microsoft Entra, a recuperação precisa ser realizada por um utilizador 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 mencionados anteriormente são aplicados durante essas interações.

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

Nota

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 utilizador é capaz de iniciar sessão no Microsoft Entra num Windows associado a domínios híbridos depois de adquirir um TGT para iniciar sessão, enquanto a emissão do PRT ocorre 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.

Nota

Em um ambiente Windows híbrido associado ao 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
A	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 utilizador, nonce e um escopo de intermediário, assina a solicitação com a chave do Dispositivo (dkpriv) e envia-a para 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

Passo	Descrição
A	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 utilizador já tiver iniciado sessão anteriormente, o Windows iniciará a sessão em cache e validará as credenciais para efetuar o login do utilizador. 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, o Microsoft Entra ID retornará o ponto de extremidade de Metadata Exchange (MEX) 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 embutida no PRT, valida o nonce, verifica se o dispositivo é válido no inquilino 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.

Nota

Um PRT pode ser renovado externamente sem a necessidade de uma conexão VPN quando os pontos de extremidade com nomes de utilizador mistos são habilitados externamente.

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

Passo	Descrição
A	Um aplicativo, como o Microsoft Outlook, 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 de agora em diante para este aplicativo. O plug-in WAM também devolve o novo PRT ao plug-in CloudAP, que valida o PRT com o Microsoft Entra ID antes de o atualizar na sua própria 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

Passo	Descrição
A	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 utilizador abre uma URL de login do Microsoft Entra, o navegador ou a extensão valida a URL com as obtidas do registo. 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 cliente nativo host retorna este cookie PRT ao navegador, que o inclui como parte do cabeçalho da solicitação chamado x-ms-RefreshTokenCredential e solicita tokens 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.

Nota

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.

Partilhar via

Noções básicas sobre o PRT (Primary Refresh Token)

Terminologia e componentes principais