We are building an application with a React/Redux frontend and a NodeJS/Express Backend. I, not being a security expert, opted to go with Auth0 to handle Authentication.
Auth0 returns an ID Token and an Access Token when a user logs in, this access token is used to authenticate and access our backend API.
We've seen this Access token stored before in Local Storage but Auth0 then contradicts that here. Furthermore, in this answer it seems that some recommend storing in Local Storage, as does this one.
This has me terribly confused. How can we store and persist the token without storing it in memory? We could store it in Redux only but it'll clear on refresh which isn't a solution.
Here they show that the User Signs in and the Access Token is returned and that later it is to be sent along with API Requests, which I understand, but where is it to be stored in the meantime?
How are we supposed to store the access tokens so our application can access our API? Or are we not supposed to store it at all?
We decided to store access tokens in a React Context Provider. Looks like Auth0 has updated their quickstart guide to do the same.
The best way to store AT/RT is by using a distibuted cache memory for your client backend servers. By this way, you make sure that all API calls must transite by your backend application. In your frontend, you pass only the ID_Token witch has to be used to identify your end users.
User sends ID_Token --> Client (backend web app) checks the Id_Token and Get AT from cache memory --> Call the APIs with AT.
Related
I'm trying to implement Google authentication for my app and the below is the workflow I'm trying to set up.
First, user will authenticate with Google and obtain an access token.
User will make requests with this token to backend services.
Backend services will check with Google to validate these token
Once validated, backend services will send information requested by client back to users
And I have a couple question around it:
Is this the correct way to implement it?
How to avoid check with Google for every single request between Backend and Frontend?
It's sort of the correct way. It depends on the details. If I understand correctly, you are in control of the front and backend (these are both your applications). If this is the case, then you would rather use Google services only to authenticate the user (so use an OpenID Connect flow to get an ID token to verify the user's identity). After that, you would have your backend either issue an access token or establish a session with your frontend. Then you wouldn't have to ask Google for the token's validity every time someone makes a request to your backend.
An access token that you get from Google, Facebook, etc. is meant to be used with their APIs. You could use it to authorize access to your own backend, but you then have to call Google on every request to verify the token. You are also tightly coupled to Google's details of the access token usage — what scopes are available, what data is returned with the token, expiration times, etc.
If the access token is a JWT, then you can verify it on your own in your backend. You don't have to call the issuer every time. But, if I remember correctly, Google issues opaque tokens, so this is not the way to go here.
To sum up. If you're in control of the front and back end, then authenticate with Google, then start a session between your applications. This will be simpler to maintain and also safer, as you wouldn't have to handle tokens in the browser.
I'm building my authentication manually using Auth0 API's since there is no SDK for SvelteKit at the time I'm writing this question.
So far I managed to get an Access Token, send it in a cookie to the browser and send it back at every request for a check using the Auth0 API for user profiles before passing the request to an endpoint.
The problem is the lack of speed. It takes about 1s to navigate from one page to another in the browser.
I don't think I can keep Access Tokens in memory server-side (due to the nature of SvelteKit) but I want to keep things simple.
Is there an alternative to Auth0 with a faster API?
Okay, so long question ahead.
I'm working on an Angular + .NET Core app and I'm a little confused as to what is the best way to do authN & authZ for my app.
For a while before, what I would do is have a page on my frontend which requests the E-mail and Password and send it via POST to my backend, where I would generate a JWT Token. Then, I would store this token in the localStorage and use it for requests.
But, after reading some articles, I noticed that people tend to do it in another way. From what I understand, it goes something like:
Create a traditional auth app
When the user wants to log in on the SPA, redirect them to the auth app, where they log in
After logging in, redirect back to SPA and store the token in memory
Use the stored token to authenticate & authorize requests
Profit
I've also been reading and getting into using Auth0, which seems to be using the latter approach. My problem with Auth0 currently is that I need to have an Users table in my local database for things like getting additional user data (I know about the metadata that can be added in Auth0, but isn't it slower to have to get data from Auth0 everytime I need to use user metadata?) & relationships, but the Hooks don't work when my app is on localhost.
Anyways,
TL;DR
Is there a standard way of doing this that is currently recommended everyone does
Do I understand correctly how the latter approach actually works
Is the way I was doing auth that insecure? From what I understand, the insecurity comes from storing the JWT Token in localStorage, but the token actually needs a secret key to be generated, so does it matter if an ill-intentioned user can see their token? They can't tamper with it without the secret anyways
I would check out these two resources and I do agree with the conclusion to put all of the token handling in the backend, not in the SPA client.
alert‘OAuth 2 0’; // The impact of XSS on OAuth 2 0 in SPAs
SPAs are dead!?
I am looking for some advice on implementing authentication when the client and the server live in separate projects.
The Server
This API was built as an Express Server. It has routes for CRUD operations with a MySQL database. It also has a user model that utilize bcrypt to encrypt passwords. There is no Frontend, in this project.
The Client
This is a Vue project made with the vue-cli and hits the above API to get the data to display.
The Issue
I need to add authentication. I was thinking I would do this with express-session, but I am a little confused with how exactly it works. All of the tutorials I have seen use express-session in combination with passport. This seems fine, but in all the examples passport forwards to a login page that lives on the server. This is usually written in handlebars or some other templating framework. I am not sure the best way of implementing since the login page lives in the client project.
How I thought it worked (Am I missing something?)
I was originally of the impression that for a new user express-session would create a token that I would save in the users table (maybe generated at login and stored temporarily). Once the user logs in with the correct password this token is passed to the client to be stored as a cookie. When the client wants access to restricted data, it would pass the token as a Authentication header to the server to get permission.
The Questions
Since my projects are separated is passport still useful for my use case?
Is it secure to create the session cookie on the server and send the token to the client as a response to the client's login POST?
Do I need to store the session token in the database?
Is there a better option?
In my project I have almost the same setup, and I ended up with JWT to generate an access token.
The cycle begins with the user sending his/her email and password to my login endpoint.
In this stage I hash the password using some secret string, fetch the user from database and check if authentication succeed.
After that I generate an access token with an expiring time set, and I expected this access token in all protected routes.
With this approach you can easily implements refresh token to exchange at time to time, saving the refresh token in your database.
This is very simple and Is good to you understand how the process of authentication is done.
jsonwebtoken
I'm currently working on integration with Slack. The goal is to give a user the ability to share information using the Slack account right from our platform.
Since Slack uses OAuth2, we gain the access token on the backend (because of the app secret) and use it on the frontend. On the client-side, the token is stored in local storage.
Is it okay to store such tokens in local storage? The access does not expire itself, however can be revoked. P.S. the Slack application itself stores tokens in local storage.