Definir um perfil técnico para um emissor de token JWT em uma política personalizada do Azure Ative Directory B2C
Nota
No Azure Ative Directory B2C, as políticas personalizadas são projetadas principalmente para lidar com cenários complexos. Para a maioria dos cenários, recomendamos que você use fluxos de usuário internos. Se você não tiver feito isso, saiba mais sobre o pacote inicial de políticas personalizadas em Introdução às políticas personalizadas no Ative Directory B2C.
O Azure Ative Directory B2C (Azure AD B2C) emite vários tipos de tokens de segurança à medida que processa cada fluxo de autenticação. Um perfil técnico para um emissor de token JWT emite um token JWT que é retornado ao aplicativo de terceira parte confiável. Normalmente, esse perfil técnico é a última etapa de orquestração na jornada 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>
Declarações de entrada, saída e persistência
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 | Description |
|---|---|---|
| issuer_refresh_token_user_identity_claim_type | Sim | A declaração que deve ser usada como a declaração de identidade do usuário dentro dos códigos de autorização OAuth2 e tokens de atualização. Por padrão, você deve defini-lo como , a objectIdmenos que especifique um tipo de declaração SubjectNamingInfo diferente. |
| SendTokenResponseBodyWithJsonNumbers | Não | Sempre definido como true. Para o formato herdado 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 dependeram de uma implementação anterior que retornou propriedades como cadeias de caracteres. |
| token_lifetime_secs | Não | Tempo de vida do token de acesso. O tempo de vida do token 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) é de 300 segundos (5 minutos). O máximo (inclusive) é de 86.400 segundos (24 horas). |
| id_token_lifetime_secs | Não | Tempo de vida do token de ID. O padrão é 3.600 segundos (1 hora). O mínimo (inclusive) é de 300 segundos (5 minutos). O máximo (inclusive) é de segundos 86.400 (24 horas). |
| refresh_token_lifetime_secs | Não | Atualize o tempo de vida do token. 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, se seu aplicativo tiver recebido o escopo offline_access. O padrão é 120.9600 segundos (14 dias). O mínimo (inclusive) é de 86.400 segundos (24 horas). O máximo (inclusive) é de 7.776.000 segundos (90 dias). |
| rolling_refresh_token_lifetime_secs | Não | Atualize o tempo de vida da janela deslizante do token. 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. Se 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) é de 86.400 segundos (24 horas). O máximo (inclusive) é de 31.536.000 segundos (365 dias). |
| allow_infinite_rolling_refresh_token | Não | Se definido como true, o tempo de vida da janela deslizante do token de atualização nunca expira. |
| IssuanceClaimPattern | Não | Controla a declaração do Emissor (iss). Um dos valores:
|
| AuthenticationContextReferenceClaimPattern | Não | Controla o valor da acr declaração.
<Item> Key="AuthenticationContextReferenceClaimPattern" valor é None. Na sua política de terceira parte confiável, adicione item, adicione <OutputClaims> este elemento <OutputClaim ClaimTypeReferenceId="trustFrameworkPolicy" Required="true" DefaultValue="{policy}" PartnerClaimType="tfp"/>. Certifique-se também de que a sua apólice contém o tipo de reclamação <ClaimType Id="trustFrameworkPolicy"> <DisplayName>trustFrameworkPolicy</DisplayName> <DataType>string</DataType> </ClaimType> |
| RefreshTokenUserJourneyId | Não | O identificador de uma jornada do usuário que deve ser executada durante a atualização de uma solicitação POST de token de acesso para o /token ponto de extremidade. |
Chaves criptográficas
O elemento CryptographicKeys contém os seguintes atributos:
| Atributo | Obrigatório | Description |
|---|---|---|
| issuer_secret | Sim | O certificado X509 (conjunto de chaves RSA) a ser usado para assinar o token JWT. Essa é a B2C_1A_TokenSigningKeyContainer chave que você configura em Introdução às políticas personalizadas. |
| issuer_refresh_token_key | Sim | O certificado X509 (conjunto de chaves RSA) a ser usado para criptografar o token de atualização. Você configurou a B2C_1A_TokenEncryptionKeyContainer chave em Introdução às políticas personalizadas |
Gestão de sessões
Para configurar as sessões do Azure AD B2C entre o Azure AD B2C e um aplicativo de terceira parte confiável, no atributo do UseTechnicalProfileForSessionManagement elemento , adicione uma referência à sessão SSO OAuthSSOSessionProvider .