Possible causes for "Unable to issue redirect for OAuth 2.0 transaction"?

Hi,
I’ve setup an API, a SPA client, and trying to user auth0.js with authorize():

var webAuth = new auth0.WebAuth({
  domain: 'mydomain',
  clientID: 'mySPAclientId',
  audience: 'myAPIaudience',
  responseType: 'token',
  redirectUrl: 'anURIsetInClientAsAllowedCallback'
});

I am redirected to the hosted login page, I enter my email/password credentials and I am redirected back to my redirectUri, but the hash part contains an error:

#error=server_error&error_description=Unable%20to%20issue%20redirect%20for%20OAuth%202.0%20transaction&state=0Ur4oigOFBoALFenGMjJE~9YEgk6Lmin

I am not sure what can be the cause of this.

As a side question, after login I am asked consent for my API, even if the client is marked as first party. I’ve been told that may happen when using localhost, but in my case I am using my local domain and not localhost. This part is not really clear to me.

The Auth0.js option for providing the OAuth2 callback is named redirectUri and not redirectUrl. It follows the underlying OAuth2 parameter which is redirect_uri.

In the question body you used the right name, but the code has the typo so it explains the error.

In relation to consent screen, in order to skip it have in mind that you need to:

  • use the Allow Skipping User Consent toggle in the API setting to enable this option.
  • make sure the client is flagged as first-party.
  • avoid testing with localhost.
3 Likes

That was a damn little detail. I didn’t notice it because redirection worked due to client configuration in the dashboard.

Regarding the consent I checked the first 2 points. For “avoid testing with localhost”. What’s exactly hidden behind localhost? I’m currently running the SPA locally, but I interact with it using its localdomain, i.e. http://devpc.fritz.box:3000/ and the IP address is not 127.0.0.1 but 192.168.178.115. I’d not consider this to be localhost.

Also, after giving consent, where is this stored? Can I list users’ consents, or can I or the user revoke it?

That was a damn little detail. I didn’t notice it because redirection worked due to client configuration in the dashboard.

Regarding the consent I checked the first 2 points. For “avoid testing with localhost”. What’s exactly hidden behind localhost? I’m currently running the SPA locally, but I interact with it using its localdomain, i.e. http://devpc.fritz.box:3000/ and the IP address is not 127.0.0.1 but 192.168.178.115. I’d not consider this to be localhost.

Also, after giving consent, where is this stored? Can I list users’ consents, or can I or the user revoke it?

To my knowledge, the testing with localhost means avoiding http://localhost and http://127.0.0.1 so any other host/IP would not trigger this exception, but this is unconfirmed. I personally test with https://something.localtest.me but the host you used should be okay as far as I’m aware. Is this not the case?

You (as developer) can manage the consent/grants using the Management API grant related endpoints or through the Dashboard (Authorized Applications in user profile). There’s no self-service interface for end-users although you could build one leveraging the Management API.

Thanks a lot! I’ll try to remove my grants and check consent again just to be sure I’m not reporting a false problem. I’ll let you know if my problem persists.

Thanks a lot! I’ll try to remove my grants and check consent again just to be sure I’m not reporting a false problem. I’ll let you know if my problem persists.

@mbraga on a completely unrelated note… the choice to use the answer form instead of a comment is due to it being quicker to reply as the form is already open, an habit coming from our old Discourse platform or any problem with the comment system for regular users? Mostly interested in ruling out the last option… but if it works and just has bad UX would also be interesting to know.

Sorry, I am just getting used to the new platform and I forgot there is a small “reply” button that appears on hover for each answer. Also I was still trying to understand the preferred etiquette for follow up in different cases. Also there is a limit to the number of characters so I’ll elaborate in an answer below. :slight_smile:

Hi! I have the same issue but in WebView of my app (iOS & Android), but it’s completely fine on desktop. Thoughts @ jmangelo?

Hi! I have the same issue but in WebView of my app (iOS & Android), but it’s completely fine on desktop. Thoughts @ jmangelo?

Nothing comes to mind, one thing to try given you say you have on platform where it works fine would be to try to capture the HTTPS traffic from the mobile application and try to spot any differences.

Hi @jmangelo, @r071xo and I have opened a support ticket #32894 on this issue and have included the stack traces you requested. You can clearly see we’re making a simple request to Auth0 without OAuth setup and are getting an error that says “Unable to configure verification page”.

This issue is blocking our development and testing of authentication in our app. Please advise ASAP.

Thank you.

1 Like

@rafi the unable to configure verification page is not the same as what I was thinking about and is related to something completely different to the original question. I check the ticket and it is already assigned an being handled so you should continue the discussion there as there are no SLA’s on the community forum.

In case it helps anyone else, I hit this error message after upgrade to Lock v11 without reading the migration docs carefully enough… Lock 11 needs a custom domain (still in beta) or a cross-origin fallback page (seems to only support a single domain per client while regular callback URLs can be a list of domains). I’m rolling back to v10 for now until custom domains are out of beta.

For those like me that didn’t have a redirectUri before, it seems that now this parameter is mandatory (aka not optional anymore like before and like stated in the doc) when setting up auth0.js if you have a custom (cross origin) form.

1 Like