Universal Login returns a Opaque token and not a JWT token

Help
, ,
1

I am using universal login for my react native project. I can login with a username and password but I keep receiving an opaque token. I expect to receive a JWT token when a user authenticates successfully to pass to my NodeJS API. I believe something could be misconfigured in my params.

        var params = Object.assign(
      {
        /* additional configuration needed for use of custom domains
    overrides: {
      __tenant: config.auth0Tenant,
      __token_issuer: 'YOUR_CUSTOM_DOMAIN'
    }, */
        domain: config.auth0Domain,
        clientID: config.clientID,
        redirectUri: config.callbackURL,
        responseType: "token",
        audience: "https://MY_API_IDENTIFIER",
        scope: "openid profile email",
      },
      config.internalOptions
    );

    var webAuth = new auth0.WebAuth(params);
2

Hi gdorrea7,

That is odd. You have the audience. Can you post the call made with webAuth?

John

3

Hi John,

I call it with the default login function. Also, I found that if I pass “token” to the responseType, the SSO calls fail so I updated it to be responseType: "code" and now the SSO calls work but the username and password call is still returning an opaque token. My current workaround to get the username and password call to return a JWT token is to set the the default audience under Tenant Settings.

var databaseConnection = "Username-Password-Authentication";

    function login(e) {
      e.preventDefault();
      var username = document.getElementById("email").value;
      var password = document.getElementById("password").value;
      webAuth.login(
        {
          realm: databaseConnection,
          username: username,
          password: password,
        },
        function (err) {
          if (err) displayError(err);
        }
      );
    }

    function signup() {
      var email = document.getElementById("email").value;
      var password = document.getElementById("password").value;

      webAuth.redirect.signupAndLogin(
        {
          connection: databaseConnection,
          email: email,
          password: password,
        },
        function (err) {
          if (err) displayError(err);
        }
      );
    }

    function loginWithGoogle() {
      webAuth.authorize(
        {
          connection: "google-oauth2",
        },
        function (err) {
          if (err) displayError(err);
        }
      );
    }

    function loginWithFacebook() {
      webAuth.authorize(
        {
          connection: "facebook",
        },
        function (err) {
          if (err) displayError(err);
        }
      );
    }
4

Hi John, gd,

we are actually experiencing very similar situation - we have an /authorize request in which we do supply the audience in the request parameters, the user gets redirected to login, logs in correctly, authorized service gets the code issued correctly but when it exchanges the code for token, instead of a JWT token it receives an opaque token.

The suggested solution to use a default audience did not solve our issue. Moreover, the issue seems to happen “sometimes” - all our customers are using the same mobile application that has the actual parameters for the authorization request hard-coded inside it. For some customers it works just fine (i.e. they do login and the authorized service then does receive the JWT token correctly), for some we noticed on the authorized service side that we receive an opaque token.

The only thing we were able to find in the Auth0 logs is that for a failed-case (opaque token issued in the end), the login log for the affected user is “details/prompt/name:authorizationless” whereas for the successful case it is "details/prompt/name:“lock-password-authenticate”.

We do have a support case open for this and are trying to figure out what’s the cause. But for the general question - if anyone might have an idea how an authorization request could end in this “authorizationless” flow despite the audience being specified in the request and the default audience for the tenant being defined, it will be highly appreciated.

Thanks,
Jan

5

Hi John, gd, everyone interested,
we solved our issue with the big help of support. Sharing the details of our problem for future, might help someone.

Our issue was caused by two principal issues:
1/ our application was set as not OIDC-conformant (i.e. OIDC-conformant switch in app settings was disabled) - this causes the fact that old pipeline can be used and one can end up in the “authorizationless” success login state
2/ we used a wkwebview in our iOS mobile app - there is a known as-of-yet-unfixed bug in the wkwebview that causes the cookies not to be sent properly during initial connection (for more information see Issue Navigator - ASF JIRA)

Due to 2/ the mobile app did not send cookies when invoking Auth0 /authorize (and the subsequent redirect to /login) leading to the login to “succeed as authorizationless” and thus when we used the obtained result code to fetch a token, we got an opaque one and not the expected correct JWT.

So, in case you are getting “authorizationless” in login logs and getting opaque token instead of expected JWT, check the cookies your client sends when calling /authorize (and /login) ;).

Best wishes,
Jan