Definir um perfil técnico para um emissor de token JWT em uma política personalizada do Azure Active Directory B2C
Observação
No Azure Active Directory B2C, as políticas personalizadas são projetadas principalmente para tratar de cenários complexos. Para a maioria dos cenários, recomendamos que você use fluxos de usuários predefinidos. Se você ainda não fez isso, saiba mais sobre o pacote de início de política personalizado em Introdução às políticas personalizadas no Active Directory B2C.
O Azure AD B2C (Azure Active Directory B2C) emite vários tipos de tokens de segurança ao processar cada fluxo de autenticação. Um perfil técnico para um emissor de token JWT emite um token JWT que é retornado para o aplicativo de terceira parte confiável. Normalmente, esse perfil técnico é a última etapa de orquestração no percurso do usuário.
Protocolo
O atributo Name do elemento Protocol precisa ser definido como OpenIdConnect. Defina o elemento OutputTokenFormat como JWT.
O exemplo a seguir mostra um perfil técnico para JwtIssuer:
<TechnicalProfile Id="JwtIssuer">
<DisplayName>JWT Issuer</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputTokenFormat>JWT</OutputTokenFormat>
<Metadata>
<Item Key="client_id">{service:te}</Item>
<Item Key="issuer_refresh_token_user_identity_claim_type">objectId</Item>
<Item Key="SendTokenResponseBodyWithJsonNumbers">true</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
<Key Id="issuer_refresh_token_key" StorageReferenceId="B2C_1A_TokenEncryptionKeyContainer" />
</CryptographicKeys>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
</TechnicalProfile>
Entrada, saída e manter declarações
Os elementos InputClaims, OutputClaims e PersistClaims estão vazios ou ausentes. Os elementos InutputClaimsTransformations e OutputClaimsTransformations também estão ausentes.
Metadados
| Atributo | Obrigatório | Descrição |
|---|---|---|
| issuer_refresh_token_user_identity_claim_type | Yes | A declaração que deve ser usada como a declaração de identidade do usuário nos códigos de autorização OAuth2 e tokens de atualização. Por padrão, você deve defini-la como objectId, a menos que especifique um tipo de declaração SubjectNamingInfo diferente. |
| SendTokenResponseBodyWithJsonNumbers | No | Sempre defina como true. Para formatos herdados em que os valores numéricos são fornecidos como cadeias de caracteres em vez de números JSON, defina como false. Esse atributo é necessário para clientes que adotaram uma dependência em uma implementação anterior que retornou propriedades como cadeias de caracteres. |
| token_lifetime_secs | No | Tempos de vida do token de acesso. O tempo de vida do token de portador do OAuth 2.0 usado para obter acesso a um recurso protegido. O padrão é 3.600 segundos (1 hora). O mínimo (inclusive) é 300 segundos (5 minutos). O máximo (inclusive) é 86.400 segundos (24 horas). |
| id_token_lifetime_secs | No | Tempos de vida do token de ID. O padrão é 3.600 segundos (1 hora). O mínimo (inclusive) é 300 segundos (5 minutos). O máximo (inclusive) é 86.400 segundos (24 horas). |
| refresh_token_lifetime_secs | No | Tempos de vida do token de atualização. O período de tempo máximo que um token de atualização poderá ser usado para adquirir um novo token de acesso se o aplicativo tiver recebido o escopo offline_access. O padrão é 120,9600 segundos (14 dias). O mínimo (inclusive) é 86.400 segundos (24 horas). O máximo (inclusive) é 7.776.000 segundos (90 dias). |
| rolling_refresh_token_lifetime_secs | No | Tempo de vida da janela deslizante do token de atualização. Após a passagem desse período, o usuário será forçado a autenticar-se novamente, independentemente do período de validade do token de atualização mais recente adquirido pelo aplicativo. Se você não quiser impor um tempo de vida de janela deslizante, defina o valor de allow_infinite_rolling_refresh_token como true. O padrão é 7.776.000 segundos (90 dias). O mínimo (inclusive) é 86.400 segundos (24 horas). O máximo (inclusive) é 31.536.000 segundos (365 dias). |
| allow_infinite_rolling_refresh_token | No | Se definido como true, o tempo de vida da janela deslizante do token de atualização nunca expira. |
| IssuanceClaimPattern | No | Controla a declaração do emissor (iss). Um dos valores:
|
| AuthenticationContextReferenceClaimPattern | No | Controla o valor da declaração acr.
<Item> com o Key="AuthenticationContextReferenceClaimPattern" existe e o valor é None. Em sua política de terceira parte confiável, adicione o item <OutputClaims> e este elemento <OutputClaim ClaimTypeReferenceId="trustFrameworkPolicy" Required="true" DefaultValue="{policy}" PartnerClaimType="tfp"/>. Além disso, verifique se a sua política contém o tipo de declaração <ClaimType Id="trustFrameworkPolicy"> <DisplayName>trustFrameworkPolicy</DisplayName> <DataType>string</DataType> </ClaimType> |
| RefreshTokenUserJourneyId | No | O identificador de um percurso do usuário que deve ser executado durante a solicitação POST atualizar na token de acesso para o ponto de extremidade /token. |
Chaves de criptografia
O elemento CryptographicKeys contém os seguintes atributos:
| Atributo | Obrigatório | Descrição |
|---|---|---|
| issuer_secret | Sim | O certificado X509 (conjunto de chaves RSA) a ser usado para assinar o token JWT. Use a chave B2C_1A_TokenSigningKeyContainer que você configurou em Introdução às políticas personalizadas. |
| issuer_refresh_token_key | Yes | O certificado X509 (conjunto de chaves RSA) a ser usado para criptografar o token de atualização. Você configurou a chave B2C_1A_TokenEncryptionKeyContainer em Introdução às políticas personalizadas |
Gerenciamento da sessão
Para configurar as sessões do Azure AD B2C entre um aplicativo de terceira parte confiável e o Azure AD B2C, no atributo do elemento UseTechnicalProfileForSessionManagement, confira a sessão de SSO OAuthSSOSessionProvider.