I have an angular2 app that authenticates through OAuth2 with password grant type. I store the session token on sessionStorage, and I need to store another data more secure, like user current roles.
I know that I can store more information in sessionStorage or localStorage, but this is easy modified by user. Although really, if the user modifies the sessionStorage, my backend is secured because check the token against user roles.
What happens is that if the user modifies his role he could see some hidden options, and i dont want this.
I think of two solutions, and i want listen some tips.
Save the role in sessionStorage encrypted, suggestion about this? what encryptation i should use?
Having a global service like is explained on angular docs, which is used by my navbar-component and load data on ngOnInit (because routes).
Any suggestion? Thanks.
We have in our dashboard the same case of yours.
Approaching the second option its a bit messy because you need to think what happen if the user reloads the page.
The service when you are reloading the page will loose the data and you will not know what where the roles for the user.
You can fix this issue by running http in the app component when init.
For the case of encrypting read this:
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
For now we use the approach of a Global Service. (Service are Singelton)
Related
I am using my building journey to learn web development. I'm using nodejs, reactjs, mongodb, axios and expressjs.
Currently, I'm storing basic user details such username, id, role,email in the local storage. I could store other things as I continue.
However, along the line, I felt that storing something like role in the localstorage could be problematic since anyone can edit their localstorage. This means, user can easily edit their local storage and change their role to admin to have access to what admin has access to.
I decided to visit some known websites like Upwork, etc, I checked my localstorage and I noticed that they didn't store information such as username, email, role, etc.
As someone new in this field, where do you think is best to store information such as the above I mentioned, especially data that can grant access and change access privileges of any user? I don't think localstorage is best for this at all.
Also, while inspecting the browser developer tool, I noticed that whatever one passed from the response from backend is also seen under the response section in the web developer tool.
Is that response section accessible by Javascript? Or it is already encrypted by expressjs?
There are two concepts here which are important to understand: Authentication and Authorization.
Authentication is the process by which the server will validate that the user says who they say they are. The most common example of authentication is username and password.
Authorization is the process by which the server will validate the user can perform the action they want to perform. Once the user is authenticated, they will usually look up the user in a database and see if the user as the rights to do this (in your example, once such right could be admin).
For your example application, you could probably do something simple like store the username, a hash of the password and the user role in a table in your database. That would probably be good enough for your learning. When a user is trying to access something, look up the role in the table and if they don't have permissions to, return a 403 Forbidden
But you are just scratching the surface of the topic. For example, you said that applications do not store roles on the client side, but interestingly if you're using something like Json Web Tokens, this information will be on the client-side. In this flow, you authenticate to your service, you get a token that contains your role (admin in your example) and a signature. The signature is used to validate that the token was emitted by the service, meaning that the role it contains can be relied on. So when your application makes a request to your service, your service will only need to validate the signature.
I was once in your shoes, trying to figure out what to use when, when working with the same tech stack as yours. Let me tell you now what I use-
Decide what do I want(if it is a small application that needs to be built rapidly with all functionality I use sessions ( nodejs provides an excellent library known as express-sessions ), if I want a detailed fast app, I use JWT.
When you want to store things user settings of volume, light-mode dark mode, you can use simple local data storage.
If you are receiving data on the frontend side and want to use it there, you can use state-management frameworks like zustand, redux, or any others.
Further detail on the question -> you can modify what you store in the session like username, email-id, and all that, and as more data is needed you can request from the database once the user is verified.
If you have more specific questions to ask, feel free to fire on me, I will try my best.
Upvote if it gave you some insight on topic.
Never store important information on localstorage. Your intuition of it can be changed or it can be accessed by someone else is correct. And even if you store some data (such as jwt tokens) never trust your front end and validate it with the backend server for data retrieval.
In your case you can use session storage or cache storage depending on how to store the data that you need
I'm working on a react app where the pages can be used both by authenticated and anonymous users. The pages show more features for the authenticated users.
If a user previously has signed in and revists the website, I want the user to be automatically authenticated, and am struggling to achieve this.
I'm using redirect methods because I don't believe popup is working well on phones (is that assumption correct?).
I have tried storing the homeAccountId in local storage and use that to get the account used and then calling login in the msal instance. I also set up a addEventCallback and listen for EventType.LOGIN_SUCCESS which I use to set some internal state about the logged in user.
I have tried using MsalAuthenticationTemplate but strangely this doesn't invoke a login. I have also tried to detect if this is a "first run" and then invoking the login, but that doesn't work all the time. Sometime I get a SSO error indicating I should provide a login_hint or sid which is not possible because I use B2C.
If I don't do anything the user can click the login button and if the user has a valid cookie with B2C the user is logged in without providing credentials which is a strange behavior for the user because my website indicate the user is not authenticated (and show no logout button).
So I can't really get this to work and are wondering if somebody has a concept for achieving this?
Please checkout the msal-react samples which all demonstrate the behavior you're looking for. The MsalAuthenticationTemplate would be the recommended way to do this and if you're still having issues getting this to work after reviewing the samples I would recommend opening an issue on our repo with code snippets so we can take a closer look at what's going on.
Also using localStorage, if you're not already, would help to maintain application state between browser sessions. sessionStorage is the default.
As for B2C not asking for credentials; server state is separate from client state. You can be signed in on the server without the application knowing about it. Until your application makes a request to the B2C server your application will show that a user is not signed in. If a session already exists on the server when you make a login request, the server may redirect you back to your application without asking for credentials again.
So I have got all my auth working in my MVC web site but I want to ask: What is the recommended way to pass the access token around in my application?
So, I click login, a dialog pops up and I log in. My parent window receives the access token and I get some playlists. But what if I go to another page, which would be a completely new request? Do I pass it around on the query string, or in session, or maybe a cookie? I have searched the API documentation for this, but cant find anything about it.
I would say you should store it in the side from which you are making the requests. If the requests are done client-side, then keep the access token client-side. You can persist it using localStorage, as done in the web api player example. That way you can read from localStorage when you need to make a request and use it until it expires.
Then, if you have used the authorization code flow you will want to refresh it, so the user doesn't need to log in every 60 minutes. For this, you will need to make a request from your server, since the refresh process involves sending a secret that you don't want to make available in the browser. You can store the refresh token in the server (e.g. in a database table storing user <-> refresh token) or in the browser's localStorage too, sending it to the server when you want to refresh it.
You could also store it as a cookie, but if the server doesn't need to know about it, localStorage is better.
I think the Identity will be holding all the details about the logged in User. If anything we want extra , we can extend it.
Below link may help :
http://www.codeproject.com/Tips/574576/How-to-implement-a-custom-IPrincipal-in-ASP-NET-MV
I use a pyramid and i need logout all users from my site. Currently i cant find any place where are sessions wrote. There is nothing written in pyramid documentations about this situation so is any way to do that?
This depends on the authentication backend you're using. If the backend stores the session somewhere, you can just clear that somewhere.
If you're using a backend that stores the session in a cookie, like AuthTktAuthenticationPolicy, then the cookie is signed with a secret that present in your configuration. Changing this secret would invalidate all cookies, effectively logging out all users.
Change your session factory settings, such that request object return the session after calling its session.clear method.
I have been through much of the documentation and examples provided, but Im looking for some inputs for my setup from other users.
I have a some clients (website, iOs/Android apps). These only serves as a shelves and its content will be requested through servicestack, which makes servicestack a central point of my setup.
The client will login through servicestack and get a sessionid.
My question here is, how should i setup servicestack to make sure that the user is validated on each request?
I was thinking after login, i save the user in the cache and make sure this expires after some time (unless persisted). Then on each request based on the session id, i check the cache to see if the user exists. If the user exists, the request i authenticated, and if not the user have to login again.
Am i on the right track here, or is there an easier way in servicestack, to support this?
I was thinking after login, i save the user in the cache and make sure this expires after some time (unless persisted).
It sounds like you can just use the Authentication/Authorization plugin. Once a user is authenticated (using any of the 'Providers') the user's session is stored in the cache using the key 'urn:iauthsession:[sessionId]' and contains a bool property isAuthenticated. For any Service the requires Authentication you can use the Authenticate attribute.