I am prototyping the “New Universal Login” / Passwordless (email only) experience in a web service.
Our current sequence is:
- construct the URL for
/authorize API, https://<my domain>/authorize?response_type=code&client_id=<my client id>&redirect_uri=<my web page>&state=yay&connection=email
- use the URL from # 1 to call the API (HTTP GET),
- get back a 302 response, with the redirect path in the
location header,
- navigate to the redirected location to see the login box.
When I paste the URL from step 1 in the browser, everything works great.
However, when I have my code (instead of the browser) perform steps 2 (send an HTTP GET) and 3 (get the redirect location from the 302 response), the redirect URL that I get back from auth0 does not work.
At a glance, the URL looks great (indistinguishable from a working redirect URL, https://<my domain>/u/login/identifier?state=<a long string>), but navigating to this URL causes auth0 to redirect to my service’s login page (instead of showing the auth0 login dialog).
What am I doing wrong? ; )
Thank you,
Mark.
PS Reading between the lines, it appears that auth0 is classifying my call to /authorize as a social login (btw, the links to subsections on the documentation site don’t seem to work), which “only support browser-based (passive) authentication”. So I am guessing that if my code simulated being a browser, it would work (I might try that next;), but how is this actually SUPPOSED to work?
Hello,
Based on the information you provided, it seems that the issue you are facing is related to the behavior of the Auth0 authentication service when accessing the /authorize endpoint programmatically instead of through a browser.
Auth0’s /authorize endpoint typically expects requests to be made from a browser context rather than from server-side code or scripts. When you perform an HTTP GET request programmatically, it may not include certain headers or behaviors that Auth0 expects from a browser.
To resolve this issue, you can try simulating a browser-like environment when making the request to the /authorize endpoint. Here are a few steps you can take:
Ensure that your code sets the necessary headers in the HTTP GET request. Include the User-Agent header to simulate a browser agent, which may be necessary for the Auth0 service to correctly handle the request.
Emulate browser behavior by handling cookies correctly. When you receive a 302 response, extract the Set-Cookie header from the response and include it in subsequent AARPMedicare requests. This ensures that session-related information is maintained throughout the authentication process.
Make sure to follow the redirect provided in the Location header of the 302 response. This is where the Auth0 login dialog is expected to be displayed.
- Some more information i will give you very soon as possible. *
Sorry for half answer please see below another half answer.
By simulating the behavior of a browser, you increase the likelihood of receiving the expected response from Auth0. However, keep in mind that relying on this approach may introduce additional maintenance and potential compatibility issues if the authentication service changes its requirements or security measures.
If simulating a browser-like environment does not resolve the issue, it would be helpful to review the Auth0 documentation or reach out to their support for specific guidance on performing programmatic authorization flows and any additional requirements or restrictions they may have.
Remember to handle any sensitive information securely and avoid exposing credentials or tokens in your code or requests.
an update / “resolution”: it doesn’t seem like there is a reasonable way to use auth0’s /authorize API from my service’s controller, so I modified the controller’s code to redirect the browser to auth0 /authorize “API”, and that seems to work fine.
ps auth0’s documentation for /authorize doesn’t explain this, but this diagram does, kind of: