Descrição geral dos tokens no Azure Active Directory B2C

Artigo
04/24/2023

O Azure Active Directory B2C (Azure AD B2C) emite diferentes tipos de tokens de segurança à medida que processa cada fluxo de autenticação. Este artigo descreve o formato, as características de segurança e os conteúdos de cada tipo de token.

Tipos de tokens

Azure AD B2C suporta os protocolos OAuth 2.0 e OpenID Connect, que utilizam tokens para autenticação e acesso seguro aos recursos. Todos os tokens utilizados no Azure AD B2C são tokens Web JSON (JWTs) que contêm asserções de informações sobre o portador e o assunto do token.

Os seguintes tokens são utilizados em comunicação com Azure AD B2C:

Token de ID – um JWT que contém afirmações que pode utilizar para identificar utilizadores na sua aplicação. Este token é enviado em segurança em pedidos HTTP para comunicação entre dois componentes da mesma aplicação ou serviço. Pode utilizar as afirmações num token de ID conforme entender. Normalmente, são utilizados para apresentar informações de conta ou para tomar decisões de controlo de acesso numa aplicação. Os tokens de ID emitidos pelo Azure AD B2C estão assinados, mas não estão encriptados. Quando a sua aplicação ou API recebe um token de ID, tem de validar a assinatura para provar que o token é autêntico. A sua aplicação ou API também tem de validar algumas afirmações no token para provar que é válida. Consoante os requisitos de cenário, as afirmações validadas por uma aplicação podem variar, mas a sua aplicação tem de realizar algumas validações de afirmações comuns em todos os cenários.
Token de acesso – um JWT que contém afirmações que pode utilizar para identificar as permissões concedidas às suas APIs. Os tokens de acesso estão assinados, mas não estão encriptados. Os tokens de acesso são utilizados para fornecer acesso a APIs e servidores de recursos. Quando a API recebe um token de acesso, tem de validar a assinatura para provar que o token é autêntico. A sua API também tem de validar algumas afirmações no token para provar que é válida. Consoante os requisitos de cenário, as afirmações validadas por uma aplicação podem variar, mas a sua aplicação tem de realizar algumas validações de afirmações comuns em todos os cenários.
Token de atualização – os tokens de atualização são utilizados para adquirir novos tokens de ID e tokens de acesso num fluxo OAuth 2.0. Fornecem à sua aplicação acesso a longo prazo aos recursos em nome dos utilizadores sem necessidade de interação com esses utilizadores. Os tokens de atualização são opacos para a sua aplicação. São emitidas pelo Azure AD B2C e só podem ser inspecionadas e interpretadas pelo Azure AD B2C. São de longa duração, mas a sua aplicação não deve ser escrita com a expectativa de que um token de atualização dure um período de tempo específico. Os tokens de atualização podem ser invalidados a qualquer momento por vários motivos. A única forma de a sua aplicação saber se um token de atualização é válido é tentar resgatá-lo ao fazer um pedido de token para Azure AD B2C. Quando resgatar um token de atualização para um novo token, receberá um novo token de atualização na resposta do token. Guarde o novo token de atualização. Substitui o token de atualização que utilizou anteriormente no pedido. Esta ação ajuda a garantir que os tokens de atualização permanecem válidos durante o máximo de tempo possível. As aplicações de página única que utilizam o fluxo de código de autorização com o PKCE têm sempre uma duração de token de atualização de 24 horas. Saiba mais sobre as implicações de segurança dos tokens de atualização no browser.

Pontos Finais

Uma aplicação registada recebe tokens e comunica com Azure AD B2C ao enviar pedidos para estes pontos finais:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token

Os tokens de segurança que a sua aplicação recebe do Azure AD B2C podem ser provenientes dos /authorize pontos finais ou/token. Quando os tokens de ID são adquiridos a partir de:

/authorize ponto final, é feito com o fluxo implícito, que é frequentemente utilizado para utilizadores que iniciam sessão em aplicações Web baseadas em JavaScript. No entanto, se a aplicação utilizar MSAL.js 2.0 ou posterior, não ative a concessão de fluxo implícita no registo de aplicações, uma vez que MSAL.js 2.0+ suporta o fluxo de código de autorização com o PKCE.
/token ponto final, é feito com o fluxo de código de autorização, que mantém o token oculto do browser.

Afirmações

Quando utiliza Azure AD B2C, tem um controlo detalhado sobre o conteúdo dos seus tokens. Pode configurar fluxos de utilizador e políticas personalizadas para enviar determinados conjuntos de dados de utilizador em afirmações necessárias para a sua aplicação. Estas afirmações podem incluir propriedades padrão, como displayName e emailAddress. As suas aplicações podem utilizar estas afirmações para autenticar utilizadores e pedidos de forma segura.

As afirmações em tokens de ID não são devolvidas por nenhuma ordem específica. As novas afirmações podem ser introduzidas em tokens de ID em qualquer altura. A sua aplicação não deve quebrar à medida que são introduzidas novas afirmações. Também pode incluir atributos de utilizador personalizados nas suas afirmações.

A tabela seguinte lista as afirmações que pode esperar em tokens de ID e tokens de acesso emitidos pelo Azure AD B2C.

Name	Afirmação	Valor de exemplo	Description
Audiência	`aud`	`90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6`	Identifica o destinatário pretendido do token. Para Azure AD B2C, a audiência é o ID da aplicação. A sua aplicação deve validar este valor e rejeitar o token se não corresponder. O público é sinónimo de recurso.
Emissor	`iss`	`https://<tenant-name>.b2clogin.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0/`	Identifica o serviço de tokens de segurança (STS) que constrói e devolve o token. Também identifica o diretório no qual o utilizador foi autenticado. A sua aplicação deve validar a afirmação do emissor para se certificar de que o token veio do ponto final adequado.
Emitido em	`iat`	`1438535543`	O momento em que o token foi emitido, representado no tempo de época.
Tempo de expiração	`exp`	`1438539443`	O momento em que o token se torna inválido, representado no tempo de época. A sua aplicação deve utilizar esta afirmação para verificar a validade da duração do token.
Não antes	`nbf`	`1438535543`	O momento em que o token se torna válido, representado no tempo de época. Normalmente, esta hora é igual à hora em que o token foi emitido. A sua aplicação deve utilizar esta afirmação para verificar a validade da duração do token.
Versão	`ver`	`1.0`	A versão do token de ID, conforme definido pelo Azure AD B2C.
Hash de código	`c_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	Um hash de código incluído num token de ID apenas quando o token é emitido juntamente com um código de autorização de OAuth 2.0. Um hash de código pode ser utilizado para validar a autenticidade de um código de autorização. Para obter mais informações sobre como efetuar esta validação, veja a especificação OpenID Connect.
Hash de token de acesso	`at_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	Um hash de token de acesso incluído num token de ID apenas quando o token é emitido juntamente com um token de acesso de OAuth 2.0. Um hash de token de acesso pode ser utilizado para validar a autenticidade de um token de acesso. Para obter mais informações sobre como efetuar esta validação, veja a especificação openID Connect
Nonce	`nonce`	`12345`	Um nonce é uma estratégia utilizada para mitigar ataques de repetição de tokens. A sua aplicação pode especificar um nonce num pedido de autorização com o `nonce` parâmetro de consulta. O valor fornecido no pedido é emitido não modificado na afirmação `nonce` apenas de um token de ID. Esta afirmação permite que a aplicação verifique o valor em relação ao valor especificado no pedido. A sua aplicação deve efetuar esta validação durante o processo de validação do token de ID.
Assunto	`sub`	`884408e1-2918-4cz0-b12d-3aa027d7563b`	O principal sobre o qual o token afirma informações, como o utilizador de uma aplicação. Este valor é imutável e não pode ser reatribuído ou reutilizado. Pode ser utilizado para efetuar verificações de autorização de forma segura, como quando o token é utilizado para aceder a um recurso. Por predefinição, a afirmação do requerente é preenchida com o ID de objeto do utilizador no diretório.
Referência da classe de contexto de autenticação	`acr`	Não aplicável	Utilizado apenas com políticas mais antigas.
Política de arquitetura de confiança	`tfp`	`b2c_1_signupsignin1`	O nome da política que foi utilizada para adquirir o token de ID.
Hora da autenticação	`auth_time`	`1438535543`	A hora em que um utilizador introduziu credenciais pela última vez, representadas no tempo de época. Não há discriminação entre a autenticação ser um novo início de sessão, uma sessão de início de sessão único (SSO) ou outro tipo de início de sessão. É `auth_time` a última vez que a aplicação (ou utilizador) iniciou uma tentativa de autenticação contra Azure AD B2C. O método utilizado para autenticar não é diferenciado.
Âmbito	`scp`	`Read`	As permissões concedidas ao recurso para um token de acesso. Várias permissões concedidas são separadas por um espaço.
Parte Autorizada	`azp`	`975251ed-e4f5-4efd-abcb-5f1a8f566ab7`	O ID da aplicação cliente que iniciou o pedido.

Configuração

As seguintes propriedades são utilizadas para gerir durações de tokens de segurança emitidos pelo Azure AD B2C:

Access & Durações do token de ID (minutos) – a duração do token de portador do OAuth 2.0 utilizado para obter acesso a um recurso protegido. A predefinição é 60 minutos. O mínimo (inclusive) é de 5 minutos. O máximo (inclusive) é de 1440 minutos.
Duração do token de atualização (dias) – o período de tempo máximo antes do qual um token de atualização pode ser utilizado para adquirir um novo acesso ou token de ID. O período de tempo também abrange a aquisição de um novo token de atualização se o âmbito da aplicação offline_access tiver sido concedido. A predefinição é 14 dias. O mínimo (inclusive) é um dia. O máximo (inclusive) é de 90 dias.
Duração da janela deslizante do token de atualização (dias) – após este período de tempo, o utilizador é forçado a voltar a autenticar, independentemente do período de validade do token de atualização mais recente adquirido pela aplicação. Só pode ser fornecido se o comutador estiver definido como Vinculado. Tem de ser maior ou igual ao valor de duração do token de atualização (dias ). Se o parâmetro estiver definido como Sem expiração, não pode fornecer um valor específico. A predefinição é 90 dias. O mínimo (inclusive) é um dia. O máximo (inclusive) é de 365 dias.

Os seguintes casos de utilização são ativados com estas propriedades:

Permitir que um utilizador permaneça com sessão iniciada numa aplicação móvel indefinidamente, desde que o utilizador esteja continuamente ativo na aplicação. Pode definir Atualizar a duração da janela deslizante do token (dias) como Sem expiração no fluxo de utilizador de início de sessão.
Cumpra os requisitos de segurança e conformidade do seu setor ao definir as durações de tokens de acesso adequadas.

Estas definições não estão disponíveis para fluxos de utilizador de reposição de palavra-passe.

Compatibilidade

As seguintes propriedades são utilizadas para gerir a compatibilidade de tokens:

Afirmação do emissor (iss) – esta propriedade identifica o Azure AD inquilino B2C que emitiu o token. O valor predefinido é https://<domain>/{B2C tenant GUID}/v2.0/. O valor de https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ inclui IDs para o inquilino Azure AD B2C e o fluxo de utilizador que foi utilizado no pedido de token. Se a sua aplicação ou biblioteca precisar de Azure AD B2C para estar em conformidade com a especificação OpenID Connect Discovery 1.0, utilize este valor.
Afirmação de assunto (sub) – esta propriedade identifica a entidade para a qual o token afirma informações. O valor predefinido é ObjectID, que preenche a sub afirmação no token com o ID de objeto do utilizador. O valor não suportado só é fornecido para retrocompatibilidade. Recomenda-se que mude para ObjectID assim que conseguir.
Afirmação que representa o ID da política – esta propriedade identifica o tipo de afirmação no qual o nome da política utilizado no pedido de token é preenchido. O valor predefinido é tfp. O valor de acr só é fornecido para retrocompatibilidade.

Pass-through

Quando um percurso de utilizador é iniciado, Azure AD B2C recebe um token de acesso de um fornecedor de identidade. Azure AD B2C utiliza esse token para obter informações sobre o utilizador. Ativa uma afirmação no fluxo de utilizador para transmitir o token para as aplicações que registar no Azure AD B2C. A sua aplicação tem de utilizar um fluxo de utilizador recomendado para tirar partido da transmissão do token como uma afirmação.

Atualmente, o Azure AD B2C apenas suporta a transmissão do token de acesso de fornecedores de identidade OAuth 2.0, que incluem o Facebook e o Google. Para todos os outros fornecedores de identidade, a afirmação é devolvida em branco.

Validação

Para validar um token, a aplicação deve verificar a assinatura e as afirmações do token. Muitas bibliotecas open source estão disponíveis para validar JWTs, consoante o seu idioma preferido. Recomenda-se que explore essas opções em vez de implementar a sua própria lógica de validação.

Validar assinatura

Um JWT contém três segmentos, um cabeçalho, um corpo e uma assinatura. O segmento de assinatura pode ser utilizado para validar a autenticidade do token para que possa ser considerado fidedigno pela sua aplicação. Azure AD tokens B2C são assinados com algoritmos de encriptação assimétrica padrão da indústria, como RSA 256.

O cabeçalho do token contém informações sobre a chave e o método de encriptação utilizado para assinar o token:

{
        "typ": "JWT",
        "alg": "RS256",
        "kid": "GvnPApfWMdLRi8PDmisFn7bprKg"
}

O valor da afirmação alg é o algoritmo que foi utilizado para assinar o token. O valor da afirmação de menor é a chave pública que foi utilizada para assinar o token. A qualquer momento, o Azure AD B2C pode assinar um token com qualquer um dos pares de chaves público-privado. Azure AD B2C roda periodicamente o conjunto possível de chaves. A sua aplicação deve ser escrita para processar essas alterações de chave automaticamente. Uma frequência razoável para verificar se existem atualizações às chaves públicas utilizadas pelo Azure AD B2C é de 24 em 24 horas. Para lidar com alterações de chaves inesperadas, a aplicação deve ser escrita para recuperar novamente as chaves públicas se receber um valor de criança inesperado.

Azure AD B2C tem um ponto final de metadados do OpenID Connect. Com este ponto final, as aplicações podem pedir informações sobre Azure AD B2C no runtime. Estas informações incluem pontos finais, conteúdos de tokens e chaves de assinatura de tokens. O inquilino do Azure AD B2C contém um documento de metadados JSON para cada política. O documento de metadados é um objeto JSON que contém várias informações úteis. Os metadados contêm jwks_uri, que dá a localização do conjunto de chaves públicas que são utilizadas para assinar tokens. Essa localização é fornecida aqui, mas é melhor obter a localização dinamicamente com o documento de metadados e analisar jwks_uri:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/discovery/v2.0/keys

O documento JSON localizado neste URL contém todas as informações da chave pública em utilização num determinado momento. A sua aplicação pode utilizar a kid afirmação no cabeçalho JWT para selecionar a chave pública no documento JSON que é utilizado para assinar um token específico. Em seguida, pode efetuar a validação de assinatura com a chave pública correta e o algoritmo indicado.

O documento de metadados da B2C_1_signupsignin1 política no inquilino está localizado em contoso.onmicrosoft.com :

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration

Para determinar que política foi utilizada para assinar um token (e para onde ir para pedir os metadados), tem duas opções. Primeiro, o nome da política está incluído na tfp afirmação (predefinição) ou acr (conforme configurado) no token. Pode analisar afirmações do corpo do JWT ao descodificar o corpo em base 64 e anular a serialização da cadeia JSON resultante. A tfp afirmação ou acr é o nome da política que foi utilizada para emitir o token. A outra opção é codificar a política no valor do state parâmetro quando emitir o pedido e, em seguida, descodificá-la para determinar que política foi utilizada. Qualquer um dos métodos é válido.

Azure AD B2C utiliza o algoritmo RS256, que se baseia na especificação RFC 3447. A chave pública consiste em dois componentes: o módulo RSA (n) e o expoente público RSA (e). Pode converter n programaticamente e e valores num formato de certificado para validação de tokens.

Uma descrição de como efetuar a validação de assinaturas está fora do âmbito deste documento. Estão disponíveis muitas bibliotecas open source para o ajudar a validar um token.

Validar afirmações

Quando as suas aplicações ou API recebem um token de ID, também deve efetuar várias verificações relativamente às afirmações no token de ID. As afirmações seguintes devem ser verificadas:

audience - Verifica se o token de ID se destinava a ser atribuído à sua aplicação.
não antes e hora de expiração – verifica se o token de ID não expirou.
emissor – verifica se o token foi emitido para a sua aplicação por Azure AD B2C.
nonce – uma estratégia para a mitigação de ataques de repetição de tokens.

Para obter uma lista completa das validações que a sua aplicação deve executar, consulte a especificação OpenID Connect.

Passos seguintes

Saiba mais sobre como utilizar tokens de acesso.

Partilhar via