Can I specify my own objectId when adding a user in a B2C IEF technical profile?

Question

Can I specify my own objectId when adding a user in a B2C IEF technical profile?

Michel Liesmons RD 21

I need to call a backend service during signup, and pass it the objectId of the B2C user.
I would like to do this first and only then create the user in B2C using my own objectId.
If the REST call fails, I do not need to delete the user.
Gaph operations are executed async and chances are very high the user does not exist yet when I try to delete it.

Rakesh Jagatap 11 Reputation points Microsoft External Staff

2021-10-01T11:45:07.81+00:00

Hi, if the posted answer resolves your question, please mark it as the answer by clicking the check mark. Doing so helps others find answers to their questions.

Accepted answer

0 additional answers

Your answer

Rakesh Jagatap 11 Reputation points Microsoft External Staff

2021-10-01T11:45:07.81+00:00

Hi, if the posted answer resolves your question, please mark it as the answer by clicking the check mark. Doing so helps others find answers to their questions.

Answer 1

Michael Taylor 60,161

If it is the standard ObjectId you're thinking about then no that is Azure's unique ID (per tenant) and not under your control. It wouldn't really make sense to me anyway. Imagine you create your own object ID, say 1, how does that in any way tell you whether the user is already in B2C or not? A lookup table in a DB? You can do that using the ObjectID from Azure already.

What I believe the correct solution should be is that you define your own unique ID using whatever approach you choose to take. You link your unique ID to the Azure ID using a database structure. On your side of the fence you use your unique ID. When you need to call Azure you look up the Azure ID for the given unique ID. If they don't have an Azure ID yet then they aren't in Azure so you'd need to create the account first.

This linking, by the way, is how you would integrate with any OpenID provider such as Facebook or Google so it gives you flexibility down the road if you need it.

Michel Liesmons RD 21 Reputation points

2021-07-30T22:03:36.413+00:00

I should explain the context a bit better I think.

Having our own identity structure to identitfy a user, in possibly multiple ways, is our goal exactly.
My problem exists only at signup, where we must call our backend to create this identity structure of which 2 ids need to be returned and added as custom claims and made available in issued tokens.
The backend needs the objectId to optimally use the GraphAPI and manipulate the user in later use cases.
In order to send the objectId to the backend and get their ids in return, I must first create the user in B2C, and then call the backend.

The problem arises when this call would fail. We would end up with an incomplete/invalid user in B2C.
All operations to B2C are queued/async, and so is the creation of a new user. Trying to delete this incomplete user often results in an initial user not found exception.
Hence my idea to reverse the calls and first call the backend, and only create the user when this call succeeds.
I would generate the objectId myself and use it both for the backend and for B2C (instead of having it generate an objectId itself upon user creation).

A network glitch might also break this flow.

If using my own generated objectId value for B2C to use will not work, a solution would be to setup a nightly batch that deletes incomplete/invalid users...
Alternatively we could live without the objectId in our backend and have them retrieve it JIT, using the email as key, just before the first GraphAPI call.

Any other ideas/thoughts more than welcome.
Michael Taylor 60,161 Reputation points

2021-07-31T02:15:02.077+00:00

Yes your situation is common. We have the exact same challenge. In a normal flow your login will be B2C which provides the option to create an account. The user would therefore create their account before they every get to you. Once they do get back to you you'd look up their objectID (from Azure) in your system. If you don't have it then this is a new account and you'd collect the remaining data you need.

Once you've gotten the data you need you can push the data back to Azure as claims. This requires an extra call to Azure but is only for account creation (and perhaps when it is updated, if ever). The biggest challenge that we saw was that the OAuth token from Azure wouldn't have the newly added claims so you end up having to build a new Oauth token with the updated claims. But we built our solution a few years ago and things might have changed.
Michael Taylor 60,161 Reputation points

2021-07-31T02:15:15.1+00:00

B2C is pretty free with their account creation so you can create a lot of accounts without paying whereas they do charge for usage of the accounts. This was a change made to licensing a few years ago so you should probably make sure you are OK there. Nevertheless cleaning up "bad" accounts is good housekeeping. For that a backend job would likely be best. You could weekly (or whatever) query for all user accounts that have been created. Then look them up in your internal system. If you don't find them (but bear in mind the account creation could be happening while your process is running) then delete the azure user account. Again, because of licensing, you aren't actually reducing your pricing probably but it does free up the user account.
Michael Taylor 60,161 Reputation points

2021-07-31T02:16:13.117+00:00

II should also point out that you might likely have a similar process for "old" users. Old may be users that haven't been to your site in a year. In this case you might consider cleaning them up as well, but it depends upon your business model. Nevertheless the code would be the same, just the conditions differ.

Share via

Can I specify my own objectId when adding a user in a B2C IEF technical profile?

0 additional answers

Your answer