I'm currently working with ASP.Net Core 2.1.2 and I can't find a solution for my problem.
Currently I'm building a controlpanel together with Angular 5.
The data for a user is stored in a MySQL database.
To have access to the controlpanel you have to login - and the server will load some data. Important is the admin-level (1-?) - some actions are only allowed for admins with atleast a level.
For the authentication I'm using JWTBearer, which gets sent by the client at every HTTP action as header. But in some methods I also want to check the admin-level.
Now where can I store data for the client, like his admin-level?
Is it safe to save it with a Claim? But then wouldn't it be possible for the client to modify it clientside and send a "custom" header?
I also tried to put the data in a dictionary and use the (HttpContext.)User (of type ClaimsPrinciple) as the key, but that won't work because User is always different at every Request.
Is there any safe way to store the data for a User?
You can safely store your admin-level information in a Claim, unless you're worried that someone can read it. It's not possible to modify a Claim in JWT, because its value is signed by key which only you should know and after the modification this token will be invalid. Read this article to get more information about JWT
Related
My application have to fetch data from external services with the usage of manually provided at profile/management by user api key & api secret.
I'd like to prevent a huge amount of retriving those necessary keys queries to database and persist it somewhere else (assuming that those keys won't be updated too frequently).
From my point of view it could be implemented with next options:
Use MemoryCache provider with SlidingExpiration;
Create a custom Claim and append it into existing Identity claims collection;
Please correct me if I'm wrong, but if I've realized it right - claim's information is a part of data, which is used for serialization/deserialization at frontend<->backend interaction (I'm not quite confident about it, but suppose that it's used within cookies & tokens).
Actually these keys are also required for a several background processes (message queue consumers or scheduled jobs for example).
Would you mind letting me know a proper way for persiting such protected and frequently used fields in an optimized way?
Thank you in advance.
When you login using one of SignInManager's sign-in methods, it sets a cookie on the browser with an access token in it. This cookie contains claims data. So in subsequent authorized requests, you can query the User.Claims field to access the required fields without making a trip to your datastore.
Now whether you choose to use claims or not totally depends on how often you need the API Key / Secret. Your claims are part of the access token. If sending the API key / Secret on every request is justified, claims is the ideal choice.
UPDATE:
Rather than decrypting the tokens at the frontend, it's better to send them to the frontend client along with the access token.
Incase you're not aware of IdentityServer4 or OpenIddict do check them out. It's probably got all that you need.
Problem statement:
Hi. I have some secured data which I want to expose through Web API and ASP.NET Identity mechanism. I want to use out of the box classes of ASP.NET Identity. I take a payment manually and change a value in the table. But there are cases where the user will share his username + password with some other guys so that the others can access the same content without paying anything.
Work plan:
So, I have extended the AspNetUsers table with a column named ApplicationToken (varchar). After successful login, I want to generate a token, update the field of the user's row in the table, and add this value as a claim information and send back to the client app. Now, when the user requests for a paid content, my client app will send the token also. So, somewhere in my server side codes, I need to check this ApplicationToken with the Database token value. If both are equal, I allow the request to proceed, otherwise I will send 401 Unauthorized and tell them to login again.
Implementation options:
After studying and searching, I found the below options to implement:
Create Custom Authentication Filter attribute so that I can grab the claims send from the client and do my required validation
Create a base class of the secured API and get the claims there and do my required validation.
Go for different Jwt based implementation where I should have access in both issuing and checking the Json Web Tokens.
If you have any other options, I would be very glad to hear those.
My question is, which approach is better to proceed. I have enough time to implement, so time is not a factor here. Thanks.
Hi I am a newbie to Meteor and I would like to know what is the use of hashedToken generated inside the Meteor.user object.
In Meteor documentation it is explained that the services object,
containing data used by particular login services. For example, its reset field contains tokens used by forgot password links, and its resume field contains tokens used to keep you logged in between sessions.
When I check the localstorage, Meteor.loginToken seems different from the hashedToken.
so my question is,
1.what is the difference between Meteor.loginToken generated in the local storage and hashedToken generated inside the service object?
2.Also why do resume.loginTokens inside service object is an array?
Any help is appreciated...
So a loginToken is a string of characters that can be left on the computer similar to a cookie token. You don't want to leave the actual username and password on a computer so the token is used instead.
The token is then used to authenticate to the server and log-in in place of a username/password.
There are a multiple of them in the array because you can be logged in on many devices at the same time. Each would have their own token.
The reason the tokens are hashed is an extra measure of security on the database. The tokens on the client are sha256 hashed and matched up to the one on the already hashed database ones to try and log in the user automatically.
The reason they are hashed is so no one can use them as loginToken localStorage form to login as a certain user by copying it from the database and pasting it as a localstorage logintoken. Its similar to a plaintext password being able to be used to log in a user.
Here is my problem if i can call it that way.I have implemented authentification with custom memebership provider in asp.net mvc 2.0.Everything works well but i have one problem.When user log in he provides its username and password and i check this through databse in MSSQL then i validate user and pass and use FormsAuthentication to set only UserName as profile information.
But when that user wants to create new item(lets say for sale or something) that belongs only to him and can be listed with other items that user created i can use this username(in FormsAuthentication) check it in database and connect that item to appropriate user with foreign key but that works if username is unique so i need additional informations like ID column from database table "user" to store and use it later so what is the most secure and "best practice" way to store additional information of user and use it later because username as i mentioned must be unique in database and it is not enough information about logged user.
Couldn't you store the User object (or whatever additional info you have) in the Session? or using a cookie at the client side (if you need to persist the login state even after the user closes his browser etc)? Let me know if you need specific examples.
EDIT: After reading your comments, if you are looking for a "secure cookie" solution have a look at this: http://www.codeproject.com/Articles/13665/HttpSecureCookie-A-Way-to-Encrypt-Cookies-with-ASP
I use it to store the user's id (only his id). When I retrieve this cookie I load the user given his id. Some in-memory caching allows me to avoid loading the user on each request.
But just wanted to clarify that the session object seems great for what you are trying to do + you dont have to worry about security (for the average app that is).
I am developing my login for my new homepage.
Now I found out, that I must save something like the userID (or another value that i can recognize my user) in the session variable of the browser.
At the moment I use INT for the userID.
So isn't it unsafe to put the userID in the session?
E.g. when I edit my session variable manual from userID 111 to userID 112, than I am logged in as a complete other user?!
Yes, it is unsafe to rely only on user ID.
You may wish to add a unique authentication token generated and remembered by the server. Also a very simple solution, but it will stop manipulating the user ID since the correct value for authentication token for the other user cannot be guessed.
You also need to submit both user ID and the corresponding authentication token at each request to be jointly validated on the server side, prior to performing the requested operation.
P.S. The above applies if you store this information in cookies which are accessible on the client side and can be manipulated. The viewstate (serialized in pages) can also be manipulated. The session collection is a server-side variable that is not available on the client so it cannot be manipulated. In this later case your user ID should be safe.
I would recommend you to implement the dual system: store the user ID and the token both in cookies and in the session and use the same validation logic (for simplicity). Should cookies be disabled you automatically fallback to using the session without changing your code.
The session variable is not stored in the browser, it is stored on the web server. (Typically anyway.)
A token indicating which session variable to use, is stored in the browser.
So storing the userid in the session variable is fine, as the user has no access to this directly.
If the user were to change the session token, to another one, that would be a problem, but they'd need to know the other token first. (I'm not sure how to do that myself.).
(You can further diminish this by using encryption, or other identifies like IPAddresses etc, it's really a case of how secure do you need your website to be?).
Also, if your site needs the user to log in, it's advisable to use https/SSL.
As Bravax says, the user does not have access to the Session variables (Cookies they do have access to).
If you are worried at all I would use a GUID instead as they are not sequential and nearly impossible to guess.
Also, have you looked at the built in stuff in .Net for authentication? Look at FormsAuthentication.
HTH,
Arry