Azure B2C user flow API connectors - configuring user flow to accept properties from API connector

Question

Azure B2C user flow API connectors - configuring user flow to accept properties from API connector

Vesa Vainio 0

My question is related to the docs page at: https://learn.microsoft.com/en-gb/azure/active-directory-b2c/add-api-connector?pivots=b2c-user-flow#continuation-response-1

I want to clarify the correctness of the following paragraph in the docs page: "To write claims to the directory on sign-up that shouldn't be collected from the user, you should still select the claims under User attributes of the user flow, which will by default ask the user for values, but you can use custom JavaScript or CSS to hide the input fields from an end user."

Is this really the recommended approach? Include some parts that are NOT meant to be set by a user in a web form, but just hide them using CSS? Is this really a robust approach?

I would expect to have an easy option to DISABLE user from inputting those values, including a case where a diligent/malicious user might tamper with the DOM contents or with HTTP requests.

I haven't yet implemented any API connector, so I haven't been able to verify if it's actually REQUIRED to include claims as User attributes of the user flow in order to be able to return the value from the API connector response. I'm hoping the docs paragraph is just a misunderstanding and technically returning the claim value would still work. Maybe there is a confusion between the User attributes of the B2C tenant and User attributes of the user flow?

I have experimented with a similar case, though. I have validated that even if I don't have a User attribute selected in the user flow, I can still make a Graph API request to set that property. That's how I think it should work. I think what makes sense is that the User attribute needs to be selected as a User attribute for the B2C tenant, but not for user flow. The User attributes for the B2C tenant determine the schema of the user directory in the B2C tenant, and the user flow is just for customizing the user flow, right?

Vesa Vainio 0 Reputation points

2025-03-04T10:43:07.6466667+00:00

Hello,

I have now created an API Connector for my purpose and experimented with it. I'm using it as a "Before creating the user" API Connector in a Sign up and sign in (Recommended) flow.

Indeed it happens that if I DO NOT have the relevant user property selected as a User attribute for the user flow, then my API Connector response does not set/store the relevant claim in the user's data in the user directory.

However, if I DO have the relevant user property selected as a User attribute for the user flow, then the API Connector response will set the relevant claim in the user directory.

So based on this experiment, it seems that the docs page is indeed correct. And BTW, I do see the same paragraph both for en-us and for en-gb, no difference.

Based on this I can confirm that the docs are correct, but I would like to voice my feedback that this is not a convenient or robust approach. And based on your response you seem to agree. I'm hoping this could be changed in how the user flow behaves.

BR, Vesa Vainio
Sakshi Devkante 1,335 Reputation points Microsoft External Staff

2025-03-04T15:09:58.99+00:00

Hello Vesa,

Yes, even we agree that the recommendation to use CSS or JavaScript to hide fields that shouldn't be collected from the user is generally not considered a secure or robust method. This approach is often seen as a "hacky" workaround, and you're right to be cautious about it.

Sure, you can raise feedback regarding this in the below forum requesting this feature. All the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.

https://feedback.azure.com/d365community/idea/ef6fe1c6-8426-ec11-b6e6-000d3a4f0789

Please remember, to click Accept Answer, this will help us and also improve searchability for others in the community who might be researching similar information.
Sakshi Devkante 1,335 Reputation points Microsoft External Staff

2025-03-06T10:00:19.1266667+00:00

Hello Vesa,

I am following up to see if the suggestion provided above was helpful to you. If you have any further questions or need additional assistance, please don’t hesitate to reach out.
Vesa Vainio 0 Reputation points

2025-03-07T13:07:00.5966667+00:00

Well, the suggestion above helped me provide my feedback about the feature. If you look at the conversation, it seems that the comment that is not suggested as the answer actually contains incorrect information that was later clarified in other comments. However, I'm not sure we should mark the comment that contains incorrect information as the accepted answer.

1 answer

Your answer

Vesa Vainio 0 Reputation points

2025-03-04T10:43:07.6466667+00:00

Hello,

I have now created an API Connector for my purpose and experimented with it. I'm using it as a "Before creating the user" API Connector in a Sign up and sign in (Recommended) flow.

Indeed it happens that if I DO NOT have the relevant user property selected as a User attribute for the user flow, then my API Connector response does not set/store the relevant claim in the user's data in the user directory.

However, if I DO have the relevant user property selected as a User attribute for the user flow, then the API Connector response will set the relevant claim in the user directory.

So based on this experiment, it seems that the docs page is indeed correct. And BTW, I do see the same paragraph both for en-us and for en-gb, no difference.

Based on this I can confirm that the docs are correct, but I would like to voice my feedback that this is not a convenient or robust approach. And based on your response you seem to agree. I'm hoping this could be changed in how the user flow behaves.

BR, Vesa Vainio
Sakshi Devkante 1,335 Reputation points Microsoft External Staff

2025-03-04T15:09:58.99+00:00

Hello Vesa,

Yes, even we agree that the recommendation to use CSS or JavaScript to hide fields that shouldn't be collected from the user is generally not considered a secure or robust method. This approach is often seen as a "hacky" workaround, and you're right to be cautious about it.

Sure, you can raise feedback regarding this in the below forum requesting this feature. All the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.

https://feedback.azure.com/d365community/idea/ef6fe1c6-8426-ec11-b6e6-000d3a4f0789

Please remember, to click Accept Answer, this will help us and also improve searchability for others in the community who might be researching similar information.
Sakshi Devkante 1,335 Reputation points Microsoft External Staff

2025-03-06T10:00:19.1266667+00:00

Hello Vesa,

I am following up to see if the suggestion provided above was helpful to you. If you have any further questions or need additional assistance, please don’t hesitate to reach out.
Vesa Vainio 0 Reputation points

2025-03-07T13:07:00.5966667+00:00

Well, the suggestion above helped me provide my feedback about the feature. If you look at the conversation, it seems that the comment that is not suggested as the answer actually contains incorrect information that was later clarified in other comments. However, I'm not sure we should mark the comment that contains incorrect information as the accepted answer.

Answer 1

Hello Vesa,

Thank you for reaching out to Microsoft Q&A.

This is not a secure or robust approach. It introduces the risk of tampering and could lead to unexpected behavior. CSS or JavaScript to hide fields that shouldn't be collected from the user is not recommended.

Instead of hiding input fields with CSS/JavaScript, a better approach would be to not include the claim in the user flow at all. If a claim is not meant to be set by the user, it should not be part of the user flow. You can use API connectors to set these claims programmatically without relying on user input.

You are correct that you don't need to have a claim included in the user flow in order to set it via an API connector. The claims that are part of the user flow (those visible to the user) are primarily for gathering user input. However, an API connector can return values for any claim, including ones that are not explicitly part of the user flow.

As you mentioned, you have confirmed through experimentation that even if a claim is not selected in the user flow, you can still make a Graph API request to set that property for the user. This behavior suggests that the user flow attributes are just about customizing the UI and don't necessarily define the entire set of attributes that can be managed in the B2C tenant's directory.

About API connectors in Azure AD B2C | Microsoft Learn

These API connectors can only be used to alter the sign-up part of a sign up and sign in or sign-up user flows.

These API connectors cannot be used to:

add claims to a token during sign in

add additional information not collected from the user to the user information stored in the directory

API connectors allow to specify an APIs endpoint to call from a user flow. The request and response to the API endpoint are strictly defined: we send information in a certain format and expect it in a certain format. This will often entail the user developing an Azure Function or other web API service to accept and respond to API calls.

At this time, only 'Basic authentication' of the API call is supported. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#basic_authentication_scheme to learn more about basic auth. A customer has to specify basic auth - API calls can't be unauthenticated. If they don't want to implement basic auth, then they can pass 'dummy' username and password that their API can just ignore.

All API calls are of the HTTP 'POST' method.

I hope this clarifies things.

Share via

Azure B2C user flow API connectors - configuring user flow to accept properties from API connector

1 answer

Your answer