Profiles created via email sign up are not returning userMetadata

[auth0]

Profiles created via email sign up are not returning userMetadata

[cocojoe]

@haydenholligan userInfo should not return user_metadata for a database connection in your example.

To request a full profile you should use the Management API as demonstrated in the Swift QuickStart

You should also be able to request user_metadata elements by adding Claims to the scope which will be returned in the idToken.

As of Auth0.swift 1.7 there is a new userInfo(withAccessToken accessToken: String) to handle OIDC profiles.

Let me check the FB side of things.

[cocojoe]

I notice in your FB webAuth you are using parameters for device id, it is not needed for OIDC. Also if OIDC was enabled userInfo would only return the sub of the user for scope openid

Check in your Client Settings Client / Advanced Settings / OAuth / OIDC Conformant Enabled

[haydenholligan]

userInfo used to return userMetadata. I still have to validate the profile with userInfo, so now I have to make a second call to the API to get the metadata? Isn't that a little redundant? I have to wait for both of those calls to come back before my app can really do anything. Either that, or now I have to jumble up the function call by manually adding all of the claims?

[haydenholligan]

So now do I use userInfo(token:) for email auth and userInfo(withAccessToken: for OIDC?

[haydenholligan]

I never saw OIDC conformant pop-up before, exactly what is it and why would I want it enabled / disabled? It isn't mentioned here so I'm guessing it's not mandatory?

[hzalaz]

@haydenholligan that is bare bones example but besides that, the OIDC option it will be highly recommended to be enabled and at one point will be the default (and only option). We are not enforcing that yet since there are customers using the old way.

This is a bit related to your other issue with the missing Grant Type since we are trying to move all our Auth to OAuth/OIDC flows.

Besides that, in your case webAuth is working in our legacy mode (we took note on this and will update our guidance and probably the library) so the result of calling userInfo will contain the full dump of the user. However OIDC only has a well defined set of claims that it can return and those depend heavily on what scopes you use (and as you saw userMetadata is not among them)

To fix this I'd recommend adding the user metadata to your id_token like this and decoding your id_token with https://github.com/auth0/JWTDecode.swift so you will have less network calls and the user metadata you might need on login for your app.

Also for webAuth please send an audience with the following value "https://${auth0Domain}/userinfo" where auth0Domain is your Auth0 Domain so it enforces the same OIDC behavior in both Auth methods. (Toggling the flag in the Dashboard also helps).

Hope that helps

[haydenholligan]

Hold on - for userInfo(withAccessToken:) as mentioned by @cocojoe, it returns UserInfo instead of Profile. Can I use that everywhere instead of profile? Is there documentation on it?

[haydenholligan]

I'm a little confused. UserInfo is returned but based on this codebase it isn't used anywhere..

Edit: UserInfo is returning an object with nothing inside of it.

[cocojoe]

@haydenholligan You can use it anywhere as long as you are using OIDC, just take a look at the class: https://github.com/auth0/Auth0.swift/blob/master/Auth0/UserInfo.swift#L61

It is a new method (and OIDC only) so it's not propagated throughout the documentation yet. However it will become the preferred way.

[haydenholligan]

I'm going to keep OIDC off now and try @hzalaz's suggestion of adding the metadata to the idToken.

Hold on - based on the code from https://auth0.com/docs/scopes/current#custom-claims

idToken is a dictionary. Isn't it just a string?

[hzalaz]

At the end its a string but it has a structure, please check https://jwt.io for more info, in a short description it can hold values and if decoded you can get them (and avoid a network request).

My recommendation is to avoid nesting objects in there and keep it simple, also i'd avoid storing like 100+ properties since will make the token really big.

Then you can decode it with https://github.com/auth0/JWTDecode.swift as I mentioned before.

Since your original issue is no longer there I will close this issue, please don't hesitate to contact us via https://support.auth0.com

[haydenholligan]

There's no documentation for constructing the idToken in Swift right? I know I'm just a lone random user but I really recommend marking functions as deprecated before you release breaking changes, and having documentation for everything new ready to go. I've struggled a great deal this past week with the changes and we were supposed to have our app released by now, but these changes pushed that back.

[hzalaz]

@haydenholligan the idToken is never constructed in Swift (and it never was). Do you mean extracting the information from it?

About the breaking changes, what are the breaking changes you mention about?

[haydenholligan]

Legacy grant types don't work for users created after june 8 (I think it was june 8, there was an article about it). We constructed our code based off of the docs in April, and as soon as we transferred over to new dev/prod accounts (formerly using my personal sandbox account) everything (other than facebook auth by luck) broke. The old methods were marked as deprecated just this Monday, nearly 20 days after the changes. After adhering to the new email auth changes, we had to change to accessToken in some places and idToken in other places. Then we learned you no longer receive metadata from .userInfo().

I understand how to deconstruct the idToken with JWTDecode, but I don't exactly understand how to add the metadata to the idToken.

[hzalaz]

@haydenholligan about

We constructed our code based off of the docs in April, and as soon as we transferred over to new dev/prod accounts (formerly using my personal sandbox account) everything (other than facebook auth by luck) broke

You should contact support about it and they could enable those legacy grants for you if you had an old dev account from that date.

To add claims/information to the id_token, you need to do this in a Rule you create in your Auth0 Dashboard, once you login, auth0 will execute that code and you could add your metadata from the token, as explained in the link I added

So if you have the following user_metadata in your user

user_metadata: {
  favorite_color: "blue",
  preferred_contact: "John"
}

Then in your Auth0 Dashboard you create a rule like

function (user, context, callback) {
  const namespace = 'https://myapp.example.com/';
  context.idToken[namespace + 'favorite_color'] = user.user_metadata.favorite_color;
  context.idToken[namespace + 'preferred_contact'] = user.user_metadata.preferred_contact;
  callback(null, user, context);
}

when you login, that rule will be executed in our server and will return an id_token, and when you decode it you will have both custom claims in there with your metadata information.

Remember that the rule runs in the server, not in your app and its JS (not Swift).

[haydenholligan]

Okay gotcha, I see. I'm trying to implement that and currently have

Just testing the water with email before adding all of the attributes.
Trying the rule produces

and in the app, email is definitely defined in the profile metadata

however it's not showing up in the idToken

Am I missing something?

[hzalaz]

In the Try you need to provide a sample user in JSON, and as far as I can see from your screenshot there is no user_metadata attribute in it

[haydenholligan]

Oh you can edit the try code... it's been a long day. Do you see anything wrong with the Swift code?

[hzalaz]

I think it looks good (If you mean the decode part)

[haydenholligan]

Hmm. So I got try working

Now with facebook auth, I tried
let claim = jwt.claim(name: "address")
and
let claim = jwt.claim(name: "https://vaundrydev.auth0.com/address")

which are both nil,

and if i try to create/sign up a user, after creating the user, Auth0.authentication().login(... is returning result.error
"Cannot read property 'address' of undefined"

[hzalaz]

When you login with FB either do this

Auth0
        .webAuth()
        .audience("https://{YOUR_ACCOUNT_NAME}.auth0.com/userinfo") // <==== Add this one
        .connection("facebook")
        .scope("openid offline_access")
        .parameters(["device": "A_UNIQUE_ID"]) // <===== This should not be needed now with audience
        .start { result in
            DispatchQueue.main.async {
                self.handleAuthResult(result)
            }
    }

Or turn your Client as OIDC Conformant in the dashboard, both approaches will have the same effect and the claim will be there. (Customization of the id_token is a feature of OIDC flows)

The other error, probably there is an error in your Rule since its trying to access an undefined attribute, i bet its user_metadata. The reason its undefined is that the Rules as our docs suggest runs on login so you only set the metadata after it. The correct way is to supply them to createUser (it should have a parameter for that)

[haydenholligan]

Okay, I think I got login working. However, from what I've found the only way I can update my idToken is by logging in again - how can I get the rest of the metadata? I still have to call .userInfo() if they relaunch the app and are still logged in - I still don't want to make 2 calls if I don't have to.

[hzalaz]

What do you mean by updating id_token ?

[haydenholligan]

We've been talking about storing userMetadata in the idToken. The flow of my app is to prompt them to enter additional information after signing up. I store the idToken in keychain and it's only updated on login - so the additional metadata I enter after creating a user is not in the idToken.

When a user starts a new session, I don't know what function I should be calling to get that metadata. Again, I usually call .userInfo() to verify the profile and get the metadata from that, but I'm not sure how I can do that and get the metadata in one step. The one step method we've been talking about only seems to involve when the user is logging in.

[hzalaz]

If you mean to start a new session is that when the app enters foreground or when X time has passed ok and the user_metadata could have mutated in some way, ok you need a way to get a fresh values. The values you get at login could be easily be outdated and, for now, userInfo won't help too much (values are not updated on every call of userInfo), so you will need to login.

Most of the times the metadata is obtained at first on login and most of the data changes are done in the app itself (maybe calling management api patch /user) so the app will know the up to date values of metadata. If the data can be updated from another sources, you are right its either login or obtaining the full user profile from our Management API.
The id_token is mostly to avoid calling userInfo right after login since you have the same info in the id_token, then its mostly to get that info again or just validate an access_token (expiration, if the signature is ok , etc).

If you really need to have up to date metadata all the time then hitting Management API is the workaround, instead of the audience I sent, you should use https://{YOUR_ACCOUNT_NAME}.auth0.com/api/v2/ and then use the access_token with https://github.com/auth0/Auth0.swift/blob/master/Auth0/Users.swift#L72