When users employ my custom provider to create a new account, they’re able to authenticate with the social login provider and are redirected back to Hosted Login. However, none of the information on the Complete Your Registration screen is filled in for them.
Let’s see if we’ve got this straight. A user logs on to the social login provider, is redirected back to Hosted Login, and sees a Complete Your Registration screen that looks like this:
That’s the correct screen, but, ideally, the values for the Display Name and the Email Address fields should be filled in with information pulled from the user’s profile on the social login provider. So what happened to that information?
It’s a pretty good bet that problem lies with your custom provider and with the attribute_map parameter: either you didn’t include this parameter or you didn’t format the parameter correctly. When Hosted Login renders the Complete Your Registration screen, it looks for two attribute values returned from the social login identity provider: displayName and email.
Admittedly, the social login provider might not use the names displayName and email address; for example, it might use the names username and emailAddress. Because there’s no way for Hosted Login to know the attribute names used by a social login provider, the attribute_map parameter is employed to give Hosted Login a hand with mapping these names. In this case, and for this IdP, that means telling Hosted Login that username is equivalent to the Identity Cloud’s displayName attribute, and that emailAddress is the same thing as the Identity Cloud’s email attribute.
We won’t explain how to create an attribute map here; that’s what this article is for. But adding an attribute map usually fixes the problem:
Here’s another tip. It’s possible that your custom provider has the attribute_map parameter, and yet the Complete your registration fields are still coming up empty. In that case, check the formatting of your parameter values very carefully. In particular, be sure to use the proper letter casing for your attribute names (it’s displayName, not DisplayName or displayname), and be sure that all those names are prefaced with a forward slash (e.g., /displayName).
Oh, and one more thing. Some social IdPs might not return certain attribute values; for example, a provider might not return a user's email address. Needless to say, with cases like that you'll never be able to get the user's email address, attribute map or not attribute map.