Hello!
Where I’m At
I am able to set up a React webapp that uses auth0 to authenticate. Yay! This webapp is running locally at localhost:8000, and has a route “/callback” to be called by auth0 after the user logs in.
So, in my Auth0 dashboard for this application I entered “http://localhost:8000” in the box for “Allowed Callback URLs”, “Allowed Web Origins”, and “Allowed Logout URLs”.
When I login the route at “localhost:8000/callback” does get called! Yay!
The Issue
Ok, now I have a separate nodejs backend server running at “localhost:3000” (notice the port 3000). I would like this server to be pinged at “localhost:3000/callback” and have the user redirected back to the webpage at “localhost:8000/callback”.
When I try to enter “http://localhost:3000/callback,http://localhost:8000/callback” in for any combination of the three fields in the auth0 dashboard my server side never gets called. I set up both a GET and POST route and “localhost:3000/callback” and can hit them fine from Postman, but for some reason they never get hit by auth0.
Can someone please help me understand what is the correct way to do what I’m trying to do? 
Thanks!
Hi @JimLynchCodes,
Welcome to the Community!
Can you expand on what you are trying to do with the server ping to lh:3000? It sounds like you are expecting auth0 to send a get or post request to an API after successful auth, but that wouldn’t work here.
Let me know,
Dan
1 Like
Thanks Dan!
Yes, I am expecting the server to ping to lh:3000. That seems to me to be the most logical way for things to play out. Is that not how auth0 works?
How is my server supposed to be informed of the logged in user and their token so that I can authorize client requests with it?
Thanks!
I am expecting the user to be sent to auth0 from the front-end web client, then when auth0 is successful I would like it to send that success message sent to another server and then redirect back to the frontend.
Is that not the normal way?
Maybe it’s an odd case that my front-end is hosted from static files and my backend is a totally different server altogether?
What is the recommended flow? thanks!
@JimLynchCodes
Typically your client side app will make requests to your server (API) with the user’s access token. Take a look at this doc:
Hmm that diagram would seem insecure to me because then as an attacker if learns a user’s id_token and spoof the domain can’t I then tell the server that a new access token was generated and start sending requests?
I’m not sure if I fully understand your question. If an attacker learns the user’s access token then yes, they can make calls against your API as if they were the user. This is inherent to stateless bearer tokens, and the OIDC protocol. Protecting tokens is paramount.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.