I have some questions about the login process in LoopBack 3 and modern SPA
The access token generated from users/login is JWT?
How to properly (safely) store a token generated from users/login on the modern SPA side? Just save them in localStorage or Cookies and after reading, attach them to API queries?
The accessToken generated by Loopback is not a JWT. It does not contain encrypted user data.
You could store it as a cookie on the browser and attach it to subsequent API queries.
Usually I use Redis to store my accesstokens so that the server can be stateless. This is a better solution if you have autoscaling configured.
Related
For a webapp which kind of Auth? Pros/Cons?
The app should be a webapp for FE we plan to use Angular, for BE we plan to use NodeJS.
The app will have public routes and private routes depending by role of user, and we plan to develop also an Android and iOS app too.
I see there are two approaches:
JSON Web Token
Session
I read some post that did not recommend the JWT instead of Session.
some consideration:
JWT
cons
needs a server side check for invalidate some token (so the approach are not stateles)
user information: if I put them inside the payload could generate an heavy headers and, if user information change (i.e. role) I need to change the token (and invalidate the previous). If I use only User ID inside Payload I have to load everytime from DB or cache system (i.e. Redis).
pro
API with JWT Auth seems easy to be used via web or native mobile app
Session (i.e. Express Session with Redis)
cons
session set a cookie with the session ID, it seems to be difficult to use this approach in mobile native app.
Could you confirm or add other pros/cons and suggest the best approach?
Using Socket.io (With server session/cache) instead REST API could be a valid alternative to the previous approaches?
I've been developing RESTful API server communicating with cross-platform clients such as Android, iOS, Web browser, and so on.
When a user login successfully by username and password, this server issue an access token(JWT, 5 minutes) and a refresh token(GUID, 20 days).
When we develop Android client app communicating with server, we just can store this tokens in mobile device and I believe it will not be a problem in terms of security( using SharedPreferences).
But when it comes to Web browsers, (React App) I had to tackle where to store these tokens. Finally, I decided HttpOnly Cookie, because I can manage easily CSRF attacks rather than XSS.
Soon, I doubt this is a typical design. For example, web browser users cannot logout whenever they want. So I determinate change the wrapper server(Node.js) between the React app and the RESTful API server.
In my second design, the React App and the wrapper server authenticate session-cookie model, using passport.js for exmaple. And when the wrapper recognize the request is authenticated, then the wrapper issue a short term access token(1 minute JWT) and reorganize the request by inserting the access token just issued in the header sent to the RESTful API server.
Is this reasonable process? Thank you in advance.
You could simplify your solution by removing the JWT access token altogether. The refresh token could be used as a session id. Every time a client issues an API call to the server the session id is sent in an HTTP header, so you can check if the request is legitimate.
Your approach of using a JWT token with a short expiration time is ok, but it brings some complexity to your system. In my opinion this approach is best suited for systems where you have an authentication service and a resource owner service. So the client would request an access token to the authentication service and use that token to communicate with the resource owner service. Then the resource owner can check the validity of the access token by just checking whether the signature matches the authentication service's.
I hope this helps you, let me know if I'm missing something.
For multiple AngularJS services that makes it's own Web API calls, we need to store the authentication token in a centralized place and it shouldn't be repeated. Where should we save the authentication token? I guess we need to write a authentication AngularJS service that would be responsible for log-in/log-out and it stores the generated token in client local storage so this token can be sent with each request to access secure resources on the back-end API. Kindly answer me if my understanding in correct.
After getting the access token with hybrid or authorization code flow to keep them from the browser it seems stupid to use SaveTokens = true in the (ASP.NET Core) OpenIdConnect middleware so that they end up in the browser again.
What is a better way to store the access token using the middleware?
Using SaveTokens the middleware stores the tokens in the cookie along with a users claims. Whilst this cookie might be stored in a browser it's protected so only that application can read it. The browser or client side code cannot read the cookie. So they're not really ending up in the browser (like they would using the implicit grant type).
Otherwise what you would need to do is create a token store, looking up tokens either by authenticated user or by session.
ASP.NET Core Identity has a table for storing tokens for a user you could look into using, but then this would mean all of your applications have to integrate with the ASP.NET Identity library and a token could be accessed by any app.
There are a couple of key differences compared to the implicit flow which makes this significantly more secure:
They end up in the browser as Secure and HttpOnly cookies, which means they are:
Only sent over encrypted requests over HTTPS.
They are inaccessible to JavaScript.
The cookies are encrypted as well, and can only be read by the ASP.NET Core server app. So even if an attacker does somehow obtain them, to decrypt them they'd need access to the server, or the encryption key used by ASP.NET Core's Data Protection provider.
There are 2 ways for storing authenticated users details & send the same for each web API call.
Save in Cookie.
Save in Local Storage.
In my case, user details will be used in my Web API & I just need a few(around 4 values) details of user. So for me storing user details in browser is suitable. But, no matter if I am using Local storage or Cookie storage, end user can see userDetails (like UserID, tenantID etc. which are values in my DB). So there is a security issue.
To overcome this security issue, if I will use some angular encoding-decoding algorithm, my application will be slow. Is there any work around?
I am using Web API 2 with Owin. It uses a token based authentication and works pretty well, here is the link for my implementation they follow best practices:
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
You use a bearer auth token that is sent through to client and api to verify the users. You can also have stuff like refresh tokens for additional layers of security using the interceptor services in your angular app. So the benefit of this is, is that you do not need to store your usernames / hashed passwords etc. using local storage or cookies but only the auth token and this is then sent through to the API to verify the current user.