Visão geral dos tokens no Azure Ative Directory B2C

O Azure Ative 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 o conteúdo de cada tipo de token.

Tipos de token

O Azure AD B2C dá suporte aos protocolos OAuth 2.0 e OpenID Connect, que usa tokens para autenticação e acesso seguro a recursos. Todos os tokens usados 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 usados na comunicação com o Azure AD B2C:

• ID token - Um JWT que contém declarações que você pode usar para identificar usuários em seu aplicativo. Esse token é enviado com segurança em solicitações HTTP para comunicação entre dois componentes do mesmo aplicativo ou serviço. Você pode usar as declarações em um token de ID como achar melhor. Eles são comumente usados para exibir informações da conta ou para tomar decisões de controle de acesso em um aplicativo. Os tokens de ID emitidos pelo Azure AD B2C são assinados, mas não são criptografados. Quando seu aplicativo ou API recebe um token de ID, ele deve validar a assinatura para provar que o token é autêntico. Seu aplicativo ou API também deve validar algumas declarações no token para provar que ele é válido. Dependendo dos requisitos do cenário, as declarações validadas por um aplicativo podem variar, mas seu aplicativo deve executar algumas validações de declaração comuns em cada cenário.

• Token de acesso - Um JWT que contém claims que se podem usar para identificar as permissões concedidas às suas APIs. Os tokens de acesso são assinados, mas não são criptografados. Os tokens de acesso são usados para fornecer acesso a APIs e servidores de recursos. Quando sua API recebe um token de acesso, ela deve validar a assinatura para provar que o token é autêntico. Sua API também deve validar algumas declarações no token para provar que ele é válido. Dependendo dos requisitos do cenário, as declarações validadas por um aplicativo podem variar, mas seu aplicativo deve executar algumas validações de declaração comuns em cada cenário.

• Refresh token - Os tokens de atualização são usados para adquirir novos tokens de ID e tokens de acesso em um fluxo OAuth 2.0. Eles fornecem ao seu aplicativo acesso de longo prazo a recursos em nome dos usuários sem exigir interação com esses usuários. Os tokens de atualização são opacos para seu aplicativo. Eles são emitidos pelo Azure AD B2C e podem ser inspecionados e interpretados somente pelo Azure AD B2C. Eles são de longa duração, mas seu aplicativo não deve ser escrito com a expectativa de que um token de atualização dure por um período de tempo específico. Os tokens de atualização podem ser invalidados a qualquer momento por vários motivos. A única maneira de seu aplicativo saber se um token de atualização é válido é tentar resgatá-lo fazendo uma solicitação de token para o Azure AD B2C. Ao resgatar um token de atualização para um novo token, você recebe um novo token de atualização na resposta do token. Salve o novo token de atualização. Ele substitui o token de atualização que você usou anteriormente na solicitação. Essa ação ajuda a garantir que seus tokens de atualização permaneçam válidos pelo maior tempo possível. As aplicações de página única que usam o fluxo de código de autorização com PKCE têm sempre uma validade do token de atualização de 24 horas. Saiba mais sobre as implicações de segurança dos tokens de atualização no navegador.

Pontos finais

Uma aplicação registada recebe tokens e comunica-se com o Azure AD B2C ao enviar solicitações para os seguintes pontos de extremidade:

• 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 o seu aplicativo recebe do Azure AD B2C podem vir dos pontos de extremidade /authorize ou /token. Quando os tokens de identificação são adquiridos do:

• /authorize endpoint, é realizado através do fluxo implícito , que geralmente é usado para usuários que entram em aplicativos Web baseados em JavaScript. No entanto, se a sua aplicação usa MSAL.js 2.0 ou posterior, não ative a concessão de fluxo implícito no registo da aplicação, pois o MSAL.js 2.0+ oferece suporte ao fluxo de código de autorização com PKCE.
• /token endpoint, realiza-se utilizando o fluxo de código de autorização , que mantém o token escondido do navegador.

Afirmações

Ao usar o Azure AD B2C, você tem um controle refinado sobre o conteúdo de seus tokens. Você pode configurar fluxos de usuário e políticas personalizadas para enviar determinados conjuntos de dados de usuário em declarações que são necessárias para seu aplicativo. Essas declarações podem incluir propriedades padrão, como displayName e emailAddress. Seus aplicativos podem usar essas declarações para autenticar usuários e solicitações com segurança.

As declarações em tokens de ID não são retornadas em nenhuma ordem específica. Novas declarações podem ser introduzidas em tokens de ID a qualquer momento. Seu aplicativo não deve quebrar à medida que novas reivindicações são introduzidas. Você também pode incluir atributos de usuário personalizados nas suas reivindicações.

A tabela a seguir lista as declarações que você pode esperar em tokens de ID e tokens de acesso emitidos pelo Azure AD B2C.

Configuração

As propriedades a seguir são usadas para gerenciar tempos de vida dos tokens de segurança emitidos pelo Azure AD B2C:

• Tempo de vida do token de ID de acesso & (minutos) - O tempo de vida do token de portador OAuth 2.0 usado para aceder a um recurso protegido. O padrão é 60 minutos. O mínimo (inclusive) é de 5 minutos. O máximo (inclusive) é de 1.440 minutos.

• Tempo de vida do token de atualização (dias) - O período de tempo máximo antes do qual um token de atualização pode ser usado para adquirir um novo token de acesso ou ID. O período de tempo também abrange a aquisição de um novo token de atualização se o seu aplicativo tiver recebido o escopo offline_access. O padrão é 14 dias. O mínimo (inclusive) é de um dia. O máximo (inclusive) é de 90 dias.

• Tempo de vida da janela deslizante do token de atualização (dias) - Após esse período de tempo, o usuário é forçado a se autenticar novamente, independentemente do período de validade do token de atualização mais recente adquirido pelo aplicativo. Ele só pode ser fornecido se o interruptor estiver definido como Bounded. Ele precisa ser maior ou igual ao valor do tempo de vida do token de atualização (dias). Se o switch estiver definido como Sem expiração, você não poderá fornecer um valor específico. O padrão é 90 dias. O mínimo (inclusive) é de um dia. O máximo (inclusive) é de 365 dias.

Os seguintes casos de uso são habilitados usando estas propriedades:

• Permitir que um usuário permaneça conectado a um aplicativo móvel indefinidamente, desde que o usuário esteja continuamente ativo no aplicativo. Você pode definir tempo de vida da janela deslizante do token de atualização (dias) como Sem de expiração no fluxo de usuário de login.
• Atenda aos requisitos de segurança e conformidade do seu setor definindo os tempos de vida de token de acesso apropriados.

Essas configurações não estão disponíveis para fluxos de usuário de redefinição de senha.

Compatibilidade

As propriedades a seguir são usadas para gerenciar a compatibilidade de token:

• Declaração do Emissor (iss) - Esta propriedade identifica o locatário do Azure AD 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 do Azure AD B2C e o fluxo de utilizador que foi usado na solicitação de token. Se a sua aplicação ou biblioteca precisar que o Azure AD B2C seja compatível com a especificação OpenID Connect Discovery 1.0, use este valor.

• Subject (sub) claim - Esta propriedade identifica a entidade para a qual o token afirma informações. O valor padrão é ObjectID, que preenche a declaração de sub no token com a ID do objeto do usuário. O valor de Não suportado é fornecido apenas para compatibilidade com versões anteriores. É recomendável que você mude para ObjectID assim que puder.

• Declaração que representa a ID da política - Esta propriedade identifica o tipo de declaração no qual o nome da política usado na solicitação de token é preenchido. O valor predefinido é tfp. O valor de acr é fornecido apenas para compatibilidade com versões anteriores.

Repercussão

Quando uma jornada do usuário é iniciada, o Azure AD B2C recebe um token de acesso de um provedor de identidade. O Azure AD B2C usa esse token para recuperar informações sobre o usuário. Você ativa uma declaração no seu fluxo de utilizador para passar o token através de para as aplicações registadas no Azure AD B2C. Seu aplicativo deve estar usando um fluxo de usuário recomendado para aproveitar a passagem do token como uma declaração.

Atualmente, o Azure AD B2C suporta apenas a passagem do token de acesso dos provedores de identidade OAuth 2.0, que incluem o Facebook e o Google. Para todos os outros provedores de identidade, a declaração é retornada em branco.

Validação

Para validar um token, seu aplicativo deve verificar a assinatura e as declarações do token. Muitas bibliotecas de código aberto estão disponíveis para validar JWTs, dependendo do seu idioma preferido. É recomendável que você explore essas opções em vez de implementar sua própria lógica de validação.

Validar assinatura

Um JWT contém três segmentos, um cabeçalho, um corpoe uma assinatura. O segmento de assinatura pode ser usado para validar a autenticidade do token para que ele possa ser confiável pelo seu aplicativo. Os tokens B2C do Azure AD são assinados usando algoritmos de criptografia assimétrica padrão do setor, como RSA 256.

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

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

O valor da declaração alg é o algoritmo que foi usado para assinar o token. O valor da reivindicação da criança é a chave pública que foi usada para assinar o token. A qualquer momento, o Azure AD B2C pode assinar um token usando qualquer um de um conjunto de pares de chaves público-privado. O Azure AD B2C alterna periodicamente o conjunto possível de chaves. Seu aplicativo deve ser escrito para lidar com essas alterações de chave automaticamente. Uma frequência razoável para verificar se há atualizações para as chaves públicas usadas pelo Azure AD B2C é a cada 24 horas. Para lidar com alterações de chave inesperadas, a sua aplicação deve ser programada para voltar a obter as chaves públicas se receber um valor inesperado de kid .

O Azure AD B2C tem um endpoint de metadados do OpenID Connect. Usando este ponto final, as aplicações podem solicitar informações sobre o Azure AD B2C durante o tempo de execução. Essas informações incluem pontos de extremidade, conteúdos de tokens e chaves de assinatura de token. Seu locatário 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 fornece a localização do conjunto de chaves públicas que são usadas para assinar tokens. Esse local é fornecido aqui, mas é melhor buscá-lo dinamicamente usando o documento de metadados e analisando 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 de chave pública em uso em um determinado momento. Seu aplicativo pode usar a declaração kid no cabeçalho JWT para selecionar a chave pública no documento JSON que é usada para assinar um token específico. Em seguida, ele pode executar a validação de assinatura usando a chave pública correta e o algoritmo indicado.

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

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

Para determinar qual política foi usada para assinar um token (e onde solicitar os metadados), você tem duas opções. Primeiro, o nome da política é incluído na declaração tfp (padrão) ou acr (conforme configurado) no token. Pode extrair declarações do corpo do JWT decodificando-o em base-64 e desserializando a string JSON resultante. A declaração tfp ou acr é o nome da política que foi usada para emitir o token. A outra opção é codificar a política no valor do parâmetro state quando você emite a solicitação e, em seguida, decodificá-la para determinar qual política foi usada. Qualquer um dos métodos é válido.

O Azure AD B2C usa 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). Você pode converter programaticamente n e e valores em um formato de certificado para validação de token.

Uma descrição de como executar a validação de assinatura está fora do escopo deste documento. Muitas bibliotecas de código aberto estão disponíveis para ajudá-lo a validar um token.

Validar declarações

Quando seus aplicativos ou API recebem um token de ID, ele também deve executar várias verificações em relação às declarações no token de ID. As seguintes reivindicações devem ser verificadas:

• destinatário - Verifica se o token de ID foi destinado a ser dado à sua aplicação.
• não antes de e o tempo de expiração de - Verifica se o token de ID não expirou.
• emissor - Verifica se o token foi emitido para a sua aplicação pelo Azure AD B2C.
• nonce - Estratégia para a mitigação de ataques de repetição de tokens.

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

Conteúdo relacionado

Saiba mais sobre como usar tokens de acesso.