Hello everyone, I am really confused about which authentication flow I should follow and how to implement it.
I have a web app demo consists of a dozen of HTML page built on top of Bootstrap and some Vanilla JS inside them to fetch data. They are linked through standard <a> attribute. The datas are fetched from a .NET Core API.
I am trying to follow the Single Page App flow with the Universal Login method but I am not able to retrieve the token and the user because the loginWithRedirect() function makes a new request and then I lose everything when the browser loads back the index page (the continuation of the Promise is aborted).
In order to have access to the Auth0 Client object in every page, I tried to serialize and save the Auth0 Client object inside the localStorage but it gives me an error due to cyclic properties inside it.
Hi @B3wi
There’s no good answer here, because it depends on the way your application is architected. How do you preserve state for the app in general?
For a web application that can use cookies and has full page reloads as part of the flow, you’d usually receive the Auth0 callback at a specific endpoint, set a session (tied to a session cookie) and store whatever value you need to preserve (including the identity of the user) in the session/cookie.
For pure SPA application where’s there’s one big blog of javascript loaded into the page and there’s never a redirection outside of the app, you’d usually authenticate the user using a popup or a redirection on the first load, and then store the results of that authentication in memory. We usually don’t recommend localstorage because it makes the information more susceptible to leaking.
If you have multiple HTML pages served from a web server, it sounds as if using cookies would be feasible. Once the user is authenticated, the cookie middleware will set the User object for the request, so that you have the user information available when constructing the page.
At the moment I persist the state through the LocalStorage object only, I have two utility functions inside a common .js file that save / stringify and retrieve / parsing it at each page load to remember previous user’s choices.
For a web application that can use cookies and has full page reloads as part of the flow
If you have multiple HTML pages served from a web server, it sounds as if using cookies would be feasible
This is my case but pages aren’t served from a web server but they are simply linked together by the client-side, like static HTML pages. I am able to use the LocalStorage or set Cookies via client-side.
and then store the results of that authentication in memory
What do you mean by “in memory”? Does it reference to the client browser RAM like normal JavaScript variables and objects instead of the web storage?
Excuse me, but I am a bit newbie in web development.
EDIT: I have an idea! Since I have a .NET Core WebAPI from which I fetch the data for static pages, maybe I should only protect the WebAPI and manage the user state from there. In this way the user will try to register and log in but then I will pass those requests to the WebAPI that uses Auth0 from the server-side and replies to the user with the token. Should I follow this flow? Auth0 ASP.NET Core Web API SDK Quickstarts: Authorization
This is a hard thread to answer because it exceeds authentication and is more about web development in general, and that is of course a topic that could go on forever and with no single solution but multiple possibilities.
If you are planning to have a backend, I would use cookie authentication and avoid sending any kind of tokens to the browser. Instead of returning static pages, you can use any templating engine (like Razor pages) to make use of that session cookie information.
Essentially:
User requests a page
If the cookie middleware detects no session, it handles that to the OIDC middleware that requests an authentication from Auth0.
After the login is done, a cookie with the user session is set
Now, in the server, you know the identity of the user and every request (be it for HTML content or API) will have access to the identity of the user.