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.
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
.
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.
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.
Was this page helpful?