I have successfully login to Web Api and I have received "accessToken".
Now I need to use that accessToken numerous times to call that public WebApi.
Where is the best place to store that accessToken in ASP.NET MVC4 application ?
What if I store accessToken to session?
What if I store accessToken to userData in FormsAuthenticationTicket?
APS.NET Session is stored on the server so this is best in terms of security. The user data portion of the forms authentication ticket is also a good place. Forms authentication automatically encrypts the ticket so you should be fine as well. The advantage of the forms authentication cookie is that you don't need to worry about distributed environments. For example if you run in a web farm you will have to use an out-of-proc session state whereas the cookie is on the client. It's really up to you. Both solutions are good enough.
Related
I have a C# MVC 5 website that will be called from a legacy 3.5 asp.net application that has performed all the pre-authentication of users. The idea is that the legacy app will generate a "token" (guid) with a matching database entry containing all relevant user information. The token will be passed to the MVC site via the url.
The MVC application needs to authenticate the user via the token received in the querystring and validate via the same database entry (the token will only remain valid for a very short period - say 60 seconds) with that expiry being stipulated and controlled at the database. Once the user is authenticated the user access should be maintained for a given time. I am open to using readonly session state and having access for life of the session or alternatively open to suggestions for handling expiry some other way.
I'm not particularly well versed in aspects of security for .NET having only really used "standard" forms authentication in .NET ASP and even less familiar with MVC.
The closest thing I've found to this concept is the below thread however there is simply not enough detail in the solution for someone with my lack of knowledge / experience to implement, also it's fairly old so may be outdated?
Authenticating users with auth token in query string with ASP.NET MVC
I am working on an intranet application where we have multiple MVC web applications authenticating against azure ad using OpenId. All works well with the first MVC application which redirects to azure login page and get the claims back. I want this information to be passed to the downstream MVC applications without the user logging again. I am not sure how to implement it in the best way. I cannot find the information here as well. It will be great help if someone shares can it be done.
Since you're using OpenID, why not just pass the access_token and id_token downstream. Those are all you need, and in fact, you do not need the id_token unless you want additional user-profile data. You can store the tokens in the browser or where ever else is convenient, and then including them in each request for a secure resource.
My team currently uses WebForms for projects, but I'm trying to convince everyone to switch to MVC. One of the problems that I'm running into is with authentication. I can't figure how to to implement our login process to work with MVC.
Our authentication is done via mostly a web service (we pass username & password and are told if it is valid or not), but occasionally we use ActiveDirectory for logins.
Right now we are using sessionstate to store information about the logged in person. How would I translate this to ASP.NET MVC? I've read a lot about various things -- Claims, Roles, MembershipProvider, IProvider, ASP.NET Identity, OWIN, but ASP.NET has been evolving so rapidly that I'm afraid that I'm reading old information on StackOverflow.
Right now we are using sessionstate to store information about the logged in person.
Don't do this. Ever. Not in WebForms, or MVC. It's highly insecure and easily spoofed. Session should never be used for anything to do with Authentication or Authorization. Plus, Sessionstate is volatile, and IIS can dump your session at any time, losing synchronization with your authentication.
The solution to your problem is very simple. You already have the authentication in your web service (though I question whether this would be secure either, given your Sessionstate authentication methods, but that's a different argument). All you need is the Authentication portion, which is easily provided by FormsAuthentication to set the cookie to allow logins.
You Validate against your service, if you succeed, you call FormsAuthentication.SetCookie(), and then you add [Authorize] to all the MVC action methods you want to protect. It's really that simple.
If you need to have information available about the user, then you would create a custom IIdentity and/or IPrincipal implementation that provides that information, making it secure (secured by encrypted cookie) and easy to access.
I'm using ASP MVC application + WCF service with custom session behavior implementation. Clients receive, store and use (for authorization) session tokens. Now I'm searching for most secured way to store session token at client side in ASP MVC.
I see few ways:
Hidden field. Drawback: user can open page source code and get token.
Route value. Drawback: token is actually open. User can get it from address bar.
Session. I've read a lot articles with one conclusion: using Session in MVC application is a bad practice. But Session have a lot advantages as well: can be widely
configured, can store token at server side, etc.
I'm sure there are some best practices for solving my problem. Any help will be appreciated.
Require HTTPS connections, encrypt secure data, place in cookie.
You could also pass the token around your site, encrypted of course via a hidden field or something but your scenario is actually what cookies are made to do.
My bank sets a cookie, they should be good enough for what you are doing.
I have reviewed some of the similar questions on this site but could not find one with an answer appropriate for my situation.
I am using asp.net mvc, and it is communicating securely with stateless wcf services. for each service call, i need to pass in the username and a few other ints for identification purposes. - not password, the services are not authenticating.
I am using forms auth to authenticate the users. I am just not sure where, after the user logs in, I should store their username and other account details used for the scope of the user's time logged into the site. suggestions for webforms apps include in "Session". Is there an equivilent alternative in MVC? is storing the info in the forms auth cookie the best solution? it seems like it would be slow to have that info in a cookie as opposed to somewhere else in memory..
thanks
If you need access to a select few bits of information about the current user over and over again, you could combine FormsAuthentication with a custom principal implementation.
The Forms authentication mechanism will write a cookie to your client's disk, and will recreate the custom principal based on that cookie for each call. You could e.g. store something like a user "level", a user "profile" or other small chunks of information, which would then be accessible through the HttpContext.Current.User at any time during the lifetime of your request.
Check out these resources on the topic:
MSDN docs on How to Create a Custom Principal Identity
Using Custom Principal with Forms Authentication in ASP.NET
and I'm sure googling or binging for "ASP.NET custom principal" will render quite a few more hits for you!
yes, unless it's a lot of information, the preferred location is to store it in the cookie. Aside from that, session is the next best place.