User profile not updated when user login (custom connection OAuth2)

I created a custom connection (generic OAuth2 connection), and the profile data is being populated correctly on the user’s first login, but it is not being updated when the user login again.

Here’s Fetch User Profile Script of the custom connection

function(accessToken, ctx, cb) {
    url: ' ',
    headers: {
      'Authorization': 'Bearer ' + accessToken
  }, function(err, resp, body) {
    if (err) return cb(err);
    if (resp.statusCode !== 200) return cb(new Error(body));

    var data = JSON.parse(body);

    var profile = data.result;

    profile"organization_id"] = "sn_" + profile.instance_id;
    profile"tenant_id"] = profile.organization_id;

    cb(null, profile);

In webtask log I’m seeing the updated profile being fetched from . (from console.log call)
This is the profile JSON object i call the callback with.

    "name": "Some User",
    "username": "",
    "user_id": "...",
    "resource_id": "resource_id_new",
    "email": "...",
    "roles": ],
    "instance_name": "...",
    "instance_id": "...",
    "instance_url": "...",
    "organization_id": "...",
    "tenant_id": "..."

However in my rules if I call console.log(JSON.stringify(user)) I can see that user.resource_id is still the old one (from when they first signed up) -
it hasn’t been updated to resource_id_new

Since the profile object i return from Get User Profile Script has the updated data, but the user object in Rules doesn’t have the updated data,
I am quite certain that the user profile isn’t being updated correctly.

Is this a known issue? According to the docs the user profile should be updated everytime the user logs in

I did a test with a custom OAuth2 connection that returned an incremented sequence number each time the user profile was requested and could not reproduce this situation. Checking the user profile through the Dashboard showed the last sequence number generated and rules execution also had access to the updated information.

Have in mind that under certain situation the downstream identity provider (your custom OAuth2 connection) may not get called. For example, if the user previously authenticated and a client application performs a prompt=none request (aka silent authentication) then the response may be provided automatically by Auth0 due to an already existing session and the downstream IdP would not be called (hence no update in the profile).

Confirm if the above could explain the situation (which I don’t think it is assuming the webtask log you mention proves the IdP is getting called) or update the question with more information about how the authentication requests that don’t trigger a profile update are being performed.

I managed to find the cause of this issue.
According to this doc, any custom user fields should be placed in the “user_profile” field in the returned profile object. Therefore in my Get Profile Script instead of returning

  "resource_id": "..."

I need to return

  "user_profile": {
    "resource_id": "..."

and my rules can now seeing the updated values in user.user_profile.resource_id.

I think this behaviour is very confusing for two reasons:

  1. When the user first logs in, any top level fields returned from Get Profile Script will be recorded in the User object. However, subsequent logins WILL NOT update these fields (apart from some fields like name). This is what tripped me up - thinking that since the fields are being recorded on user creation, they must be updated everytime the user logs in
  2. Other default connections such as Salesforce all use top level fields on the user object for connection-specific fields (instead of putting them in user.user_profile) and they update correctly when you modify them in Salesforce! (For example, if I change the timezone of the user in Salesforce and login again, the ‘timezone’ field of the user is updated successfully, despite it not being a default field according to the documentation)

I want to suggest some improvements for Auth0 to make to avoid confusing other users in the future.

  1. When handling profile updates (after Get Profile Script returns), remove any fields that are not supported and log a warning in the webtask recommending them to put those fields in user_profile.
  2. For officially supported connections, put the connection-specific fields inside user_profile, for consistency sake.
1 Like

Please see the answer I just posted. There are some suggestions for Auth0 to avoid this problem tripping others in the future. Thanks for your help.