Microsoft Azure AD B2C Custom Policy Snippets
Use Authsignal custom policy snippets to customize Microsoft Azure AD B2C flows.
Base Technical Profile
This is the base technical profile that is used to connect to the Authsignal Connect (OIDC) API by setting the authorization header, request body and other necessary configuration for the Azure AD B2C’s RestfulProvider. It is referenced by other technical profiles.
<TechnicalProfile Id="AuthsignalConnectApiBase">
<DisplayName>Authsignal Connect API Base</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="SendClaimsIn">Body</Item>
<Item Key="AuthenticationType">Basic</Item>
<Item Key="AllowInsecureAuthInProduction">false</Item>
<Item Key="ResolveJsonPathsInJsonTokens">true</Item>
<Item Key="ClaimUsedForRequestPayload">requestBody</Item>
<Item Key="DefaultUserMessageIfRequestFailed">Cannot process your request right now, please try again later.</Item>
</Metadata>
<CryptographicKeys>
<Key Id="BasicAuthenticationUsername" StorageReferenceId="B2C_1A_AuthsignalSecret" />
<Key Id="BasicAuthenticationPassword" StorageReferenceId="B2C_1A_AuthsignalSecret" />
</CryptographicKeys>
<InputClaims>
<InputClaim ClaimTypeReferenceId="requestBody" />
</InputClaims>
</TechnicalProfile>
OpenID Connect (OIDC) Endpoints
The following technical profiles are used to interact with the Authsignal Connect API using the OpenID Connect (OIDC) protocol.
An explanation of the integration model can be found in Authsignal’s Open ID Connect (OIDC) documentation.
Init Auth API
The POST /init-auth endpoint must be called before federating the flows to Authsignal via the OIDC Authorize technical profile.
Through the input claims, we pass in the user identifier, the Authsignal action being performed, and any other customizations such as redirectToSettings.
<OrchestrationStep Order="4" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AuthsignalOidcInitAuth" TechnicalProfileReferenceId="AuthsignalOidcInitAuth"/>
</ClaimsExchanges>
</OrchestrationStep>
Note that the Authsignal OIDC endpoints should only be called when you have
identified the user, but before the user is authenticated and is issued a
token. These snippets are dependent on objectId which is an output claim of
the default Azure AD B2C self-asserted technical profiles.
OIDC Authorize API
The GET /oidc/auth endpoint is used to begin the authentication flow with Authsignal. The token returned by the previous init-auth endpoint will be used in this endpoint.
<OrchestrationStep Order="5" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AuthsignalOidcAuth" TechnicalProfileReferenceId="AuthsignalOidcAuth"/>
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="6" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimEquals" ExecuteActionsIf="true">
<Value>isMatchingUserId</Value>
<Value>True</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="ShowUserIdMismatchErrorPage" TechnicalProfileReferenceId="SelfAsserted-Error" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="7" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimEquals" ExecuteActionsIf="true">
<Value>isChallengeSuccessful</Value>
<Value>true</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="ShowChallengeFailedPage" TechnicalProfileReferenceId="SelfAsserted-Error" />
</ClaimsExchanges>
</OrchestrationStep>
This step must always be performed after the AuthsignalOidcInitAuth
orchestration step
Utility Endpoints
These API calls extend on the above Base Technical Profile which sets the required authorization headers.
Authsignal has a core server API which can be invoked using the Azure AD B2C RESTful technical profile.
Due to Azure AD B2C technical profiles being restricted to setting input claims in either the url or body and not both, we’ve created convenience proxy endpoints to map to our key APIs.
Get user
The following code snippets map to our Get User API call.
The policies only use the isEnrolled property from the response, but you can extend this to include other claims as needed.
isEnrolled is true if the user is enrolled with at least one verification method and can be challenged.
<OrchestrationStep Order="1" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AuthsignalGetUser" TechnicalProfileReferenceId="AuthsignalGetUser" />
</ClaimsExchanges>
</OrchestrationStep>
Was this page helpful?