1

When creating a local user with Azure B2C, the identity setup requires the following three properties: signInType, issuer and issuerAssignedId (doc). If the signInType is set to emailAddress, we are required to set the issuerAssignedId to the users email address. However, it looks like property issuerAssignedId has a 64 character limit. A valid email can be longer than this. I have attempted working around this through the federation type by splitting up the email address and setting the issuerAssignedId to the email username and issuer to the email domain, but this didn't work.

Has anyone been able to work around this artificial character limit?

Kieron MK
  • 75
  • 8

2 Answers2

0

I was able to create a user without the restriction using the Microsoft Graph API. I was able to create a user with an email length of 87 characters (local-part length of 81 characters).

In the interactive flow (i.e., running the user journey) there is a 64 character limit on the local-part of the email address. This is in line with the email specifications: The format of an email address is local-part@domain, where the local-part may be up to 64 octets long and the domain may have a maximum of 255 octets.

In this scenario, I was able to create a user with email address over 64 characters where the local-part was up to 64 characters.

bolt-io
  • 113
  • 7
  • What local account identity type did you use for this? The spec includes ```emailAddress```, ```userName``` and ```federated```. If we use ```emailAddress``` "the issuerAssignedId must be a valid email address". If this field is limited to 64 characters, we cannot enter an email address that is longer than this? Are you able to post an example of your working Graph API request? – Kieron MK Aug 22 '23 at 15:30
0

Only signInNames.emailAddress and signInNames.username have limits.

Just persist the identifier to something else: signInNames.foo, and then the limit is much larger 256/512char off memory.

Jas Suri - MSFT
  • 10,605
  • 2
  • 10
  • 20