User details are nil after successful authentication

Help
, , , ,
1

I have a Ruby on Rails Setup with auth0 strongly aligned with the given examples. The setup worked fine until this afternoon where auth0 as auth provider suddenly just returned empty, or nil attributes for users who are signing in regardless of the sign in method (social or database). I still get a valid token and expiration date but email, nickname, name are nil and raw_info is empty.

How come? Is there a good explanation? I double checked all settings but there is nothing which may explains this sudden change.

An example callback from auth0 after authentication looks like

{"provider"=>"auth0",
 "uid"=>nil,
 "info"=>{"name"=>nil, "nickname"=>nil, "email"=>nil, "image"=>nil},
 "credentials"=>
  {"token"=>"CoHuObjRipfGjjovZqivW7x8mIVa0gwF",
   "expires_at"=>1511454049,
   "expires"=>true,
   "id_token"=>nil,
   "token_type"=>"Bearer",
   "refresh_token"=>nil},
 "extra"=>{"raw_info"=>{}}}

for a successful social login as well as a successful login with a “normal” database user using lock with the following versions

oauth2 (1.4.0)
  faraday (>= 0.8, < 0.13)
  jwt (~> 1.0)
  multi_json (~> 1.3)
  multi_xml (~> 0.5)
  rack (>= 1.2, < 3)
omniauth (1.6.1)
  hashie (>= 3.4.6, < 3.6.0)
  rack (>= 1.6.2, < 3)
omniauth-auth0 (2.0.0)
  omniauth-oauth2 (~> 1.4)
omniauth-oauth2 (1.4.0)
  oauth2 (~> 1.0)
  omniauth (~> 1.2)

and lock with the following setup:

  <%= javascript_include_tag '//cdn.auth0.com/js/auth0/8.8/auth0.min.js' %>
    <script>
    var webAuth = new auth0.WebAuth({
      domain: '<%= Rails.application.secrets.auth0_domain %>',
      clientID: '<%= Rails.application.secrets.auth0_client_id %>',
      redirectUri: '<%= Rails.application.secrets.auth0_callback_url %>',
      audience: `https://<%= Rails.application.secrets.auth0_domain %>/userinfo`,
      responseType: 'code',
      scope: 'openid profile',
      state: '<%= get_state %>'
    });
2

If you’re performing an OIDC compliant authentication request and although you request the scopes email and profile the resulting claims in the ID token do not contain the expected properties for those scopes then some possible causes may be:

  1. the end-user in question does not have the associated properties in its user profile.
  2. you have a rule that is overriding the granted scopes and removes the email and profile scopes from the set of scopes granted as part of the authentication/authorization transaction.
  3. you customized the hosted login page in such way that the scopes sent in the initial request are being lost when continuing the authentication process. For example, not configuring Lock correctly in terms of consuming the config.internalOptions that are injected to the hosted login page.

Given that you mentioned you had this working before it’s likely that the first option is not the reason behind this unless you started making tests with different users. The second possibility is also easy to rule out if you disable all the custom rules you have and do a quick test without them.

If none of the above proves to be the issue then you need to provide additional information; ideally an HTTP trace that shows the authentication request and response. Have in mind that your should redact sensitive information from the trace and that traces (HAR) captured by browsers like Chrome tend to not include HTTP response bodies which may reduce their utility. In addition, you may provide the trace in a password protected file and use sharelock.io to share the password only to @auth0.com email addresses.

3

Thanks jmangelo for your quick response. I am using lock, so it should be OIDC compliant. I can eliminate option 1) given your argumentation. Additionally, same error occurs with social logins and even preconfigured user profiles which do have the attributes for sure.

I also double checked option 2) but I am just using sample rules without modifications (Slack notifications & Enrich profile with the locations where the user logs in).

Thanks, I will try to provide the mentioned HTTP traces and server logs

4

The HTTP traces would indeed be helpful, meanwhile I added a third possibility that just occurred to me.