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

Um Token de Atualização Principal (PRT) é um importante artefato de autenticação do Microsoft Entra em dispositivos Windows 10 ou posteriores, Windows Server 2016 e versões posteriores, iOS e Android. Trata-se de um JWT (Token Web JSON) emitido especialmente para agentes de token internos da Microsoft para habilitar o SSO (logon único) nos aplicativos usados nesses dispositivos. Neste artigo, forneça detalhes sobre a emissão, o uso e a proteção de um PRT em dispositivos Windows 10 ou mais recentes. É recomendável usar as versões mais recentes do Windows 10, Windows 11 e Windows Server 2019+ para obter a melhor experiência de SSO.

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

Principais termos e componentes

Os componentes do Windows mostrados a seguir desempenham um papel fundamental na solicitação e no uso de um PRT:

• CloudAP (Provedor de Autenticação de Nuvem): o CloudAP é o provedor de autenticação moderno para entrada no Windows, que verifica os usuários que estão fazendo logon em um dispositivo Windows 10 ou mais recente. O CloudAP fornece uma estrutura tipo plugin que pode ser desenvolvida por provedores de identidade para habilitar a autenticação no Windows usando as credenciais do respectivo provedor de identidade.
• WAM (Gerenciador de Contas da Web): o WAM é o agente de token padrão em dispositivos Windows 10 ou mais recentes. Ele também fornece uma estrutura de plug-in que pode ser usada pelos provedores de identidade para habilitar o SSO para os aplicativos que dependem desse provedor de identidade.
• Plug-in CloudAP do Microsoft Entra: um plug-in específico do Microsoft Entra criado na estrutura do CloudAP que verifica as credenciais do usuário com Microsoft Entra ID durante a entrada do Windows.
• Plug-in WAM do Microsoft Entra: um plug-in específico do Microsoft Entra criado na estrutura do WAM que permite o SSO para aplicativos que dependem de Microsoft Entra ID para autenticação.
• Dsreg: um componente específico do Microsoft Entra no Windows 10 ou posteriores que opera o processo de registro de dispositivo em todos os estados de dispositivo.
• TPM (Trusted Platform Module): um TPM é um componente de hardware interno de um dispositivo que fornece funções de segurança baseadas em hardware para segredos de usuário e de dispositivo. Mais detalhes podem ser encontrados no artigo Visão geral da tecnologia Trusted Platform Module.

O que um PRT contém?

Um PRT contém as declarações encontradas na maioria dos tokens de atualização do Microsoft Entra ID. Além disso, o PRT também conta com algumas declarações específicas do dispositivo. Elas são as seguintes:

• ID do dispositivo: um PRT é emitido a um usuário em um dispositivo específico. A declaração de ID do dispositivo deviceID determina em qual dispositivo o PRT foi emitido ao usuário. Posteriormente, essa declaração é emitida a tokens obtidos por meio do PRT. A declaração de ID do dispositivo é usada para determinar a autorização de Acesso condicional baseada no estado ou na conformidade do dispositivo.
• Chave da sessão: a chave da sessão é uma chave simétrica criptografada que é gerada pelo serviço de autenticação do Microsoft Entra e emitida como parte do PRT. A chave da sessão atuará como a prova de posse quando um PRT for usado para obter tokens para outros aplicativos. A chave da sessão é distribuída no Windows 10 ou posteriores, em dispositivos ingressados no Microsoft Entra ou híbridos ingressados no Microsoft Entra se tiver mais de 30 dias.

Posso ver o que há dentro de um PRT?

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

Como um PRT é emitido?

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

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

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

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

• Ingressado no Microsoft Entra ou híbrido ingressado no Microsoft Entra: um PRT é emitido durante o logon do Windows quando um usuário entra com suas credenciais da organização. Um PRT é emitido com todas as credenciais do Windows 10 ou mais recente compatíveis, como senhas e o Windows Hello para Empresas. Nesse cenário, o plug-in CloudAP do Microsoft Entra é considerado a autoridade principal pelo PRT.
• Dispositivo registrado no Microsoft Entra: um PRT é emitido quando um usuário adiciona uma conta corporativa secundária no dispositivo Windows 10 ou posteriores. Os usuários podem adicionar uma conta ao Windows 10 ou mais recente de duas formas:
  • Adicionando uma conta usando o prompt Permitir que minha organização gerencie meu dispositivo depois de entrar em um aplicativo (por exemplo, Outlook)
  • Adicionando uma conta pelo caminho Configurações>Contas>Acesso corporativo ou de estudante>Conectar

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

Observação

Os terceiros provedores de identidade precisam dar suporte ao protocolo WS-Trust para habilitar a emissão do PRT em dispositivos Windows 10 ou mais recentes. Sem o WS-Trust, o PRT não pode ser emitido aos usuários em dispositivos híbridos ingressados no Microsoft Entra ou ingressados no Microsoft Entra. No AD FS, apenas os pontos de extremidade usernamemixed são necessários. No AD FS, se smartcard/certificate for usado durante o login no Windows, serão necessários os pontos de extremidade certificatemixed. Tanto adfs/services/trust/2005/windowstransport quanto 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 por meio do Proxy de Aplicativo Web.

Observação

As políticas de acesso condicional do Microsoft Entra não são avaliadas quando os PRTs são emitidos.

Observação

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

Qual é o tempo de vida de um PRT?

Depois de emitido, um PRT é válido por 14 dias, mas será renovado continuamente desde que o usuário use o dispositivo ativamente.

Como um PRT é usado?

Um PRT é usado por dois componentes fundamentais no Windows:

• Plug-in CloudAP do Microsoft Entra: ao entrar no Windows, o plug-in CloudAP do Microsoft Entra solicita um PRT do Microsoft Entra ID usando as credenciais fornecidas pelo usuário. Ele também armazena o PRT em cache para habilitar a entrada armazenada em cache quando o usuário não tem acesso a uma conexão com a Internet.
• Plug-in WAM do Microsoft Entra: quando usuários tentam acessar aplicativos, o plug-in WAM do Microsoft Entra usa o PRT para habilitar o SSO no Windows 10 ou posteriores. O plug-in WAM do Microsoft Entra usa o PRT para solicitar tokens de atualização e de acesso para aplicativos que dependem do WAM para solicitações de token. Ele também injeta o PRT nas solicitações do navegador para habilitar o SSO em navegadores. O SSO do navegador no Windows 10 ou mais recente é compatível com Microsoft Edge (nativamente), Chrome (por meio de Contas do Windows 10 ou Mozilla Firefox v91+ (Configuração de SSO do Windows para Firefox)

  Observação

  Em instâncias 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 primária 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 um PRT é renovado?

Um PRT é renovado por meio de dois métodos:

• Plug-in CloudAP do Microsoft Entra a cada 4 horas: o plug-in CloudAP renova o PRT a cada 4 horas durante o início da sessão no Windows. Se o usuário não tiver conexão com a internet durante esse período, o plug-in CloudAP renovará o PRT após o dispositivo se conectar à internet e uma nova entrada no Windows for concluída.
• Plug-in WAM do Microsoft Entra durante solicitações de token do aplicativo: o plugin WAM habilita o SSO em dispositivos Windows 10 ou posteriores 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:
  • Um aplicativo solicita o WAM para um token de acesso silenciosamente, mas não existe um token de atualização disponível para esse aplicativo. Nesse caso, o WAM usa o PRT para solicitar um token para o aplicativo e retorna um novo PRT na resposta.
  • Um aplicativo solicita um token de acesso ao WAM, mas o PRT é inválido ou o Microsoft Entra ID exige autorização adicional (por exemplo, Autenticação Multifator do Microsoft Entra). Nesse cenário, o WAM inicia um logon interativo que exige que o usuário seja autenticado de novo ou forneça uma verificação extra, e um novo PRT é emitido após a autenticação bem-sucedida.

Em um ambiente de AD FS, uma linha direta de visão para o controlador de domínio não é necessária para renovar o PRT. A renovação do PRT requer apenas pontos de extremidade /adfs/services/trust/2005/usernamemixed e /adfs/services/trust/13/usernamemixed habilitados no proxy ao usar 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 os PRTs são renovados.

Considerações-chave

• Nos dispositivos ingressados no Microsoft Entra e híbridos ingressados no Microsoft Entra, o plug-in CloudAP é considerado a autoridade principal para um PRT. Caso um PRT seja renovado durante uma solicitação de token baseada em WAM, o PRT será enviado de volta para o plug-in CloudAP, o qual verificará sua validade com o Microsoft Entra ID antes de aceitá-lo.

Plataforma Android:

• Um PRT é válido por 90 dias e é renovado continuamente desde que o dispositivo esteja em uso. No entanto, ele só será válido por 14 dias se o dispositivo não estiver em uso.
• Um PRT só é emitido e renovado durante uma autenticação de aplicativo nativo. Um PRT não é renovado nem emitido durante uma sessão do navegador.
• É possível obter um PRT sem a necessidade de registro de dispositivo (ingressar no local de trabalho) e habilitar o SSO.
• Os PRTs obtidos sem o registro do dispositivo não podem atender aos critérios de autorização do acesso condicional que dependem do status ou da conformidade do dispositivo.

Como o PRT é protegido?

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

• Durante a primeira entrada: durante a primeira entrada, um PRT é emitido por meio de solicitações de assinatura usando a chave do dispositivo gerada criptograficamente durante o registro do dispositivo. Em um dispositivo com um TPM válido e em funcionamento, a chave do dispositivo é protegida pelo TPM, o que impede qualquer acesso mal-intencionado. Um PRT não é emitido se não é possível validar a assinatura da chave de dispositivo correspondente.
• Durante solicitações e renovações de token: quando um PRT é emitido, o Microsoft Entra ID também emite uma chave da sessão criptografada para o dispositivo. Ele é criptografado com a tkpub (chave de transporte pública) gerada e enviada ao Microsoft Entra ID como parte do registro do dispositivo. Essa chave da sessão só pode ser descriptografada pela chave de transporte privada (tkpriv) protegida pelo TPM. A chave da sessão é a chave POP (Prova de posse) para qualquer solicitação enviada ao Microsoft Entra ID. A chave da sessão também é protegida pelo TPM, e nenhum outro componente do sistema operacional pode acessá-la. As solicitações de token ou de renovação de PRT são assinadas com segurança por essa chave da sessão por meio do TPM e, portanto, não podem ser adulteradas. O Microsoft Entra invalida qualquer solicitação do dispositivo que não esteja assinada pela chave da sessão correspondente.

Ao proteger essas chaves com o TPM, aprimoramos a segurança para PRT de atores mal-intencionados que tentam roubar as chaves ou repetir o PRT. Portanto, o uso de um TPM aumenta muito a segurança de ingressados no Microsoft Entra, dispositivos híbridos ingressados no Microsoft Entra e registrados no Microsoft Entra contra roubo de credenciais. Para melhor desempenho e confiabilidade, o TPM 2.0 é a versão recomendada para todos os cenários de registro de dispositivos do Microsoft Entra no Windows 10 ou posteriores. A partir do Windows 10 atualização 1903, o Microsoft Entra ID não usa o TPM 1.2 para nenhuma das chaves acima devido a problemas de confiabilidade.

Como tokens de aplicativo e cookies de navegador são protegidos?

Tokens de aplicativo: quando um aplicativo solicita um token por meio do WAM, o Microsoft Entra ID emite um token de atualização e um token de acesso. O WAM, porém, retorna apenas o token de acesso para o aplicativo e protege o token de atualização em seu cache ao criptografá-lo com a chave de interface de programação de aplicativos de proteção de dados (DPAPI) do usuário. O WAM usa o token de atualização de modo seguro por meio da assinatura de solicitações com a chave da sessão para emitir mais tokens de acesso. A chave de API de Proteção de Dados é protegida por uma chave simétrica baseada no Microsoft Entra ID e no próprio Microsoft Entra. Quando o dispositivo precisa descriptografar o perfil do usuário com a chave DPAPI, o Microsoft Entra ID a fornece criptografada pela chave da sessão, e o plug-in CloudAP solicitará o TPM para descriptografá-la. Essa funcionalidade garante a 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 posteriores, o Microsoft Entra ID tem suporte nativo ao SSO do navegador no Internet Explorer e no Microsoft Edge. No Google Chrome, esse suporte se dá por meio da extensão de contas do Windows 10 e no Mozilla Firefox v91 e posteriores através de uma configuração do navegador. A segurança é criada para proteger os cookies e também os pontos de extremidade para os quais eles são enviados. Os cookies do navegador são protegidos da mesma maneira que um PRT, ou seja, usando a chave da sessão para assiná-los e protegê-los.

Quando um usuário inicia uma interação com o navegador, o navegador (ou a extensão) invoca um host cliente nativo do COM. O host do cliente nativo garante que a página seja oriunda de um dos domínios permitidos. O navegador poderia enviar outros parâmetros para o host do cliente nativo, inclusive um nonce, porém, o host do cliente nativo garante a validação do nome do host. O host do cliente nativo solicita um cookie do PRT do plug-in CloudAP, o qual o cria e o assina com a chave da sessão protegida do TPM. Como o cookie do PRT é assinado pela chave da sessão, ele é muito difícil de ser adulterado. Esse cookie do PRT é incluído no cabeçalho da solicitação do Microsoft Entra ID para validar o dispositivo do qual ele se origina. Se estiver usando o navegador Chrome, apenas a extensão explicitamente definida no manifesto do host do cliente nativo poderá invocá-lo, impedindo que extensões arbitrárias façam essas solicitações. Depois que o Microsoft Entra ID validar o cookie do PRT, ele emitirá um cookie de sessão para o navegador. Esse cookie de sessão também contém a mesma chave da sessão emitida com um PRT. Durante as solicitações subsequentes, a chave da sessão será validada, associando efetivamente o cookie ao dispositivo e impedindo reproduções de outros locais.

Quando um PRT obtém uma declaração de MFA?

Um PRT consegue obter uma declaração de autenticação multifator em cenários específicos. Quando um PRT baseado na MFA é usado para solicitar tokens para aplicativos, a declaração de MFA é transferida para esses tokens de aplicativo. Essa funcionalidade fornece uma experiência sem contratempos aos usuários ao evitar o desafio de MFA para cada aplicativo que o exigir. Um PRT consegue obter uma declaração de MFA das maneiras a seguir:

• Entrar com o Windows Hello para Empresas: O Windows Hello para Empresas substitui senhas e usa chaves criptográficas para fornecer uma autenticação forte de dois fatores. O Windows Hello para Empresas é específico a um usuário em um dispositivo e ele mesmo requer a MFA para provisionar. Quando um usuário faz login usando o Windows Hello para Empresas, o PRT do usuário recebe uma declaração de MFA. Esse cenário também se aplica aos usuários que fazem login com cartões inteligentes se a autenticação de cartões inteligentes produzir uma declaração de MFA do AD FS.
  • Como o Windows Hello para Empresas é considerado uma autenticação multifator, a declaração de MFA é atualizada quando o próprio PRT é atualizado. Portanto, a duração da MFA se estenderá continuamente quando os usuários se conectarem usando o Windows Hello para Empresas.
• MFA durante uma entrada interativa do WAM: durante uma solicitação de token por meio do WAM, caso um usuário seja solicitado a usar a 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 dela é baseada no tempo de vida definido no diretório.
  • Quando um PRT e um RT já existentes são usados para o acesso a um aplicativo, eles são considerados a primeira prova de autenticação. Um novo RT é obrigatório com uma segunda prova e uma declaração de MFA impressa. Esse 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. Consequentemente, existe um PRT para cada Windows Hello para Empresas, senha ou cartão inteligente. Esse particionamento garante que as declarações de MFA sejam isoladas com base na credencial usada e que não sejam misturadas durante solicitações de token.

Observação

Ao usar uma senha para fazer login no Windows 10 ou mais recente em dispositivos ingressados no Microsoft Entra ou dispositivos híbridos ingressados no Microsoft Entra, a MFA poderá ser obrigatória durante o login interativo no WAM depois que a chave da sessão associada ao PRT for renovada.

Como um PRT é invalidado?

Um PRT é invalidado nos seguintes cenários:

• Usuário inválido: se um usuário é excluído ou desabilitado no Microsoft Entra ID, o PRT dele é invalidado e não pode ser usado para obtenção de tokens para aplicativos. Se um usuário excluído ou desabilitado já tiver entrado em um dispositivo antes, a entrada armazenada em cache faria o logon até que CloudAP ficasse ciente do seu estado inválido. Assim que CloudAP determinar que o usuário é inválido, ele bloqueará logons subsequentes. Um usuário inválido será automaticamente impedido de fazer login em novos dispositivos que não tenham suas credenciais armazenadas em cache.
• Dispositivo inválido: se um dispositivo é excluído ou desabilitado no Microsoft Entra ID, o PRT obtido no dispositivo é invalidado e não pode ser usado para obtenção de tokens para outros aplicativos. Se um usuário estiver conectado em um dispositivo inválido, ele poderá continuar fazendo isso. No entanto, todos os tokens no dispositivo são invalidados, e o usuário não tem o SSO para nenhum recurso desse dispositivo.
• Alteração de senha: se um usuário obteve o PRT com sua senha, o PRT é invalidado pelo Microsoft Entra ID quando o usuário altera sua senha. Ao alterar a senha, o usuário receberá um novo PRT. Essa invalidação pode ocorrer de duas maneiras:
  • Caso o usuário entre no Windows com sua nova senha, o CloudAP descartará o PRT antigo e solicitará que o Microsoft Entra ID emita um novo PRT com a nova senha. Caso o usuário não tenha uma conexão com a Internet, a nova senha não pode ser validada, e o Windows pode exigir que o usuário insira a senha antiga.
  • Se um usuário tiver feito login com sua senha antiga ou alterado sua senha depois de entrar no Windows, o PRT antigo será usado para qualquer solicitação de token baseada em WAM. Nesse cenário, o usuário é solicitado a fazer a reautenticação durante a solicitação de token do WAM, e um novo PRT é emitido.
• Problemas do TPM: às vezes, o TPM de um dispositivo pode apresentar problemas ou falhar, resultando em inacessibilidade das chaves protegidas pelo TPM. Nesse caso, o dispositivo não consegue obter um PRT nem solicitar tokens usando um PRT existente, pois ele não pode provar a posse das chaves de criptografia. Como resultado, todos os PRTs existentes são invalidados pelo Microsoft Entra ID. Ao detectar uma falha, o Windows 10 inicia um fluxo de recuperação para registrar novamente o dispositivo com novas chaves de criptografia. Com o ingresso híbrido no Microsoft Entra, assim como o registro inicial, a recuperação ocorre silenciosamente, sem a entrada de usuário. Para dispositivos ingressados ou registrados no 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 guia o usuário a recuperar o dispositivo com sucesso.

Fluxos detalhados

Os diagramas a seguir ilustram os detalhes subjacentes na emissão, na renovação e no 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 supramencionados são aplicados durante essas interações.

Emissão de PRT durante a primeira entrada

Observação

Em dispositivos ingressados no Microsoft Entra, a emissão de PRT do Microsoft Entra (etapas A-F) ocorre de forma síncrona antes que o usuário possa fazer logon no Windows. Em dispositivos híbridos ingressados no Azure AD, o Active Directory local é a autoridade principal. Portanto, o usuário pode fazer logon no dispositivo Windows híbrido ingressado no Microsoft Entra depois de adquirir um TGT para fazer logon, enquanto a emissão de PRT ocorre de forma assíncrona. Esse cenário não se aplica a dispositivos registrados no Microsoft Entra, pois o logon não usa as credenciais do Microsoft Entra.

Observação

Em um ambiente Windows híbrido ingressado no 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 da nuvem. É importante solucionar esse cenário com o provedor de federação.

Etapa	Descrição
Um	O usuário insere sua senha na interface do usuário de entrada. A LogonUI passa as credenciais em um buffer de autenticação para o LSA, que, por sua vez, passa-as internamente para o CloudAP. O CloudAP encaminha essa solicitação ao plug-in CloudAP.
B	O plug-in CloudAP inicia uma solicitação de descoberta de realm 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 Troca de Metadados (MEX) do provedor de federação. Caso contrário, o Microsoft Entra ID retorna que o usuário é gerenciado indicando que o usuário pode autenticar com Microsoft Entra ID.
C	Caso o usuário seja gerenciado, o CloudAP recebe o nonce do Microsoft Entra ID. Se o usuário for federado, o plugin do CloudAP solicitará um token do tipo Security Assertion Markup Language (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.
D	O plugin do CloudAP constrói a solicitação de autenticação com as credenciais do usuário, o nonce e um escopo do agente, assina a solicitação com a chave do Dispositivo (dkpriv) e a envia para o Microsoft Entra ID. Em um ambiente federado, o plugin do 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, depois verifica se o dispositivo é válido no locatário e emite o PRT criptografado. Juntamente com o PRT, o Microsoft Entra ID também emite uma chave simétrica, chamada Chave da sessão criptografada pelo Microsoft Entra ID usando a chave de transporte (tkpub). Além disso, a chave da sessão também é inserida no PRT. Essa chave da sessão atua como a chave PoP para solicitações subsequentes com o PRT.
F	O plug-in CloudAP passa o PRT criptografado e a chave da sessão para o CloudAP. O CloudAP solicita ao TPM que descriptografe a chave da sessão usando a chave de transporte (tkpriv) e a recriptografe usando a própria chave do TPM. O CloudAP armazena a chave da sessão criptografada em seu cache, junto com o PRT.

Renovação do PRT em logons subsequentes

Etapa	Descrição
Um	O usuário insere sua senha na interface do usuário de entrada. A LogonUI passa as credenciais em um buffer de autenticação para o LSA, que, por sua vez, passa-as internamente para o CloudAP. O CloudAP encaminha essa solicitação ao plug-in CloudAP.
B	Se o usuário tiver entrado no usuário anteriormente, o Windows irá iniciar o login armazenado em cache e validar as credenciais para fazer o login 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 CloudAP inicia uma solicitação de descoberta de realm 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 Troca de Metadados (MEX) do provedor de federação. Caso contrário, o Microsoft Entra ID retorna que o usuário é gerenciado indicando que o usuário pode autenticar com Microsoft Entra ID.
D	Se o usuário for federado, o plugin 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. Caso o usuário seja gerenciado, o CloudAP receberá diretamente o nonce do Microsoft Entra ID.
E	O plugin do CloudAP constrói a solicitação de autenticação com as credenciais do usuário, o nonce e o PRT existente, assina a solicitação com a chave da Sessão e a envia para o Microsoft Entra ID. Em um ambiente federado, o plugin do 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 da sessão comparando-a com a chave da sessão inserida no PRT, valida o nonce e, depois, verifica se o dispositivo é válido no locatário e emite um novo PRT. Como visto anteriormente, o PRT é novamente acompanhado pela chave da sessão criptografada pela chave de transporte (tkpub).
G	O plug-in CloudAP passa o PRT criptografado e a chave da sessão para o CloudAP. O CloudAP solicita ao TPM que descriptografe a chave da Sessão usando a chave de Transporte (tkpriv) e a recriptografe usando a chave do próprio TPM. O CloudAP armazena a chave da 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 com nomes de usuário são habilitados externamente.

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

Etapa	Descrição
Um	Um aplicativo (por exemplo, Outlook, OneNote etc.) inicia uma solicitação de token para o WAM. O WAM, por sua vez, solicita ao plug-in WAM do Microsoft Entra que atenda à solicitação de token.
B	Caso um token de atualização do aplicativo já esteja disponível, o plug-in WAM do Microsoft Entra o usará para solicitar um token de acesso. Para fornecer uma prova de associação ao dispositivo, o plug-in WAM assinará a solicitação com a chave da sessão. O Microsoft Entra ID valida a chave da sessão e emite um token de acesso e um novo token de atualização para o aplicativo, criptografados pela chave da sessão. O plug-in WAM solicita que o plug-in CloudAP descriptografe os tokens, o qual, por sua vez, solicita que o TPM descriptografe usando a chave da sessão, o que resulta no plug-in WAM obtendo ambos os tokens. Em seguida, o plugin do WAM fornece apenas o token de acesso para o aplicativo, enquanto recriptografa o token de atualização com a DPAPI e o armazena em seu próprio cache
C	Caso um token de atualização do aplicativo não esteja disponível, o plug-in WAM do Microsoft Entra usa o PRT para solicitar um token de acesso. Para fornecer uma prova de posse, o plug-in WAM assinará a solicitação contendo o PRT com a chave da sessão. O Microsoft Entra ID valida a assinatura da Chave da sessão comparando-a com a chave da sessão inserida 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 novos PRTs (baseados no ciclo de atualização), todos eles criptografados pela Chave da sessão.
D	O plug-in WAM solicita que o plug-in CloudAP descriptografe os tokens, o qual, por sua vez, solicita que o TPM descriptografe usando a chave da sessão, o que resulta no plug-in WAM obtendo ambos os tokens. Em seguida, o plugin do WAM fornece apenas o token de acesso para o aplicativo, enquanto recriptografa o token de atualização com a DPAPI e o armazena em seu próprio cache. O plug-in WAM usa o token de atualização nesse aplicativo desse momento em diante. O plug-in WAM também retorna o novo PRT ao plug-in CloudAP, o qual valida o PRT com o Microsoft Entra ID antes de atualizá-lo em seu próprio cache. O plug-in CloudAP usa o novo PRT desse momento em diante.
E	O WAM fornece o token de acesso emitido recentemente ao WAM, o qual, por sua vez, o fornece de volta para o aplicativo de chamada.

SSO do navegador usando o PRT

Etapa	Descrição
Um	O usuário faz logon no Windows com suas próprias credenciais para obter um PRT. Assim que o usuário abrir o navegador, o navegador (ou extensão) carregará as URLs a partir do registro.
B	Quando um usuário abre um URL de logon do Microsoft Entra, o navegador ou a extensão valida o URL com aqueles obtidos a partir do registro. Caso elas sejam correspondentes, o navegador invocará o host do cliente nativo para obter um token.
C	O host de cliente nativo valida que os URLs pertencem aos provedores de identidade da Microsoft (conta Microsoft ou Microsoft Entra ID), extrai um nonce enviado a partir do URL e faz uma chamada para o plug-in CloudAP para obter um cookie do PRT.
D	O plug-in CloudAP cria o cookie do PRT, se conecta com a chave da sessão associada ao TPM e a envia de volta para o host do cliente nativo.
E	O host do cliente nativo retorna esse cookie do 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 da sessão no cookie do 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 SSO do navegador descrito nas etapas anteriores não se aplica a sessões em modos privados, como InPrivate no Microsoft Edge, Incognito no Google Chrome (ao usar a extensão Contas da Microsoft) ou em modo privado no Mozilla Firefox v91+

Próximas etapas

Para obter mais informações sobre como solucionar problemas relacionados ao PRT, confira o artigo Solucionar problemas de dispositivos híbridos Windows 10 ou posteriores e Windows Server 2016 ingressados no Microsoft Entra.