I have an ASP MVC 5 app. The app talks to a WCF service. Once the user has passed in their credentials, a connection to WCF is established using those credentials. This is done so that the WCF services restricts their access and only returns useful data to the MVC app.
Authentication is working correctly, and the WCF credentials are stored for the session. However, if I shut down the app, and start it up again, these credentials are lost. So, my question is, what is the best approach to storing the credentials?
If I persist the credentials to file, I probably should encrypt them right? Is there some recommended way of storing passwords so that I can later decrypt them? If so, wouldn't this be very insecure because anyone on the server can grab user's passwords and decrypt them?
Lastly, just to confirm, the cookie on the client side doesn't save and resend the password does it? Just so I understand this correctly, the cookie is just a unique identifier that confirms that the client has previously been talking to the server. Right?
Related
We're in a scenario where a single page application that we develop ourselves (AngularJS front end with https server APIs in the back) opens another
web application developed by a partner of ours in a new browser tab, and where this second web application needs access to a https server API that is also developed by us.
After looking around for possible solutions, we have now created a proof of concept using IdentityServer4, where the second web application is configured as a client with "authorization_code" grant type. When all applications are running on the same domain, the third party application is able to access our https server API without being prompted for user id and password.
The implementation of the second web application in this proof of concept is very much like the solution presented by bayardw for the post
Identity Server 4 Authorization Code Flow example
My question now is:
When - in production - the second web application no longer shares domain with our application and our https server API, will a call from the second web application be prompted for username and password when accessing our http server API?
Seems, you are missing some major things. First of all any API should never ask for username and password. Instead your app(s) should put a token into each request and API should validate that token. Where the user credentials should be asked is when a user accesses your (or 3-rd party) web application. Then Identity Provider creates an Identity token (usually to be persisted in a cookie and used within the app) and access token (to be provided to APIs). Each token is issued for specific Client (app) pre-registered in IdP. Probably when been hosted at the same domain your two apps shared the identity cookie and Client Id what is not correct. In production scenario you have to register the apps separately. All the rest should work fine (if you follow the routine i briefly described at the beginning).
Chosing to post an answer myself from feedback through other channels:
This boils down to the session tracking of the IdP. If cookies are being used to track IdP session, the behavior is impacted by whether a session cookie or a persistent cookie is used.
In general, I have found that Robert Broeckelmann has great articles on medium.com.
I have an MVC application built that uses forms authentication and stores credentials encrypted in AspNetUsers
I also have a web api application that using that same store of users and is secured with oAuth.
The api is tested and works from an javascript app (going to be deployed on smartphones).
Now I also have a need to access the same API from the MVC app. Basically the user is already logged in an authenticated, but as far as I can see, in order to get an access token from the API (calling the api/token endpoint) I need the users password, which is one way encrypted in the DB.
The API and MVC app are deployed as two separate apps.
I guess one way I could do this is to grab the access_token when they first log into the MVC app and store it in the user table.
Is there a another recommended way to handle this in the .NET world?
Thanks
We are creating an Asp.NET MVC-5 application with Identity, and the database is accessed through a WebAPI using OAuth2. When a user logs in with a username and password, the MVC application uses this info to log in to the WebAPI to request the first access_token and refresh_token. These tokens are stored in the MVC application in a dictionary with the user's username as the key. The tokens are not exposed outside of the MVC Application. We then use the user's username to retrieve the tokens from the dictionary each request that the user makes.
We use Identity with Cookie Authentication in the MVC Application. The MVC Application is going to restart every once in a while (every week or so), which means we'll lose the access and refresh tokens stored in memory.
My questions:
We use the UserName provided by User.Identity.Name as the key to retrieve the user's access_token and refresh_token from the dictionary. Is this safe? I assume Identity retrieves this from the cookie. Would it be possible for a user to change the cookie to pretend to be another user, or is Identity's serialization safe enough?
I plan to store the refresh token in the cookie as well, so that when the MVC application has restarted, we can use this token to authenticate the user without forcing the user to log back in. This is basically the same question as 1. Is this safe?
If both are in fact not safe, would it be sufficient to create a small local database where we store this data, and use a GUID in the cookie to retrieve it? We're trying to avoid needing a local database, but if it's necessary then so be it.
Thanks for the help.
It's not secure to store the refresh or access tokens in cookies.
Please refer to Where to store access and refresh tokens on ASP.NET client web app - calling a REST API
You shouldn't be concerned about "losing the access and refresh tokens stored in memory". If it happens, just recreate them.
BTW: Storing any user data at in-memory dictionary is not a good idea. Use ASP Session management. It would be much easier to add any backed to that (in-proc, database, redis).
I'm trying to build the foundation for my iPhone app and server. I have users who will sign up and sign in from the iPhone app. In a normal website login, the http server will provide cookies to allow the user's subsequent requests to remain authenticated. How should I handle this on the iPhone? Should I just send the user/password every single time I have a NSURLConnection GET or POST? That seems excessive. Or do I use the ASIHTTPRequest framework to use cookies. Can anyone point me in the right direction for a proper implementation?
Thanks!
Sending username and password in every request is not great.
You can use anything you want to send cookies. It's just another HTTP header. But that begs the question of what is in the cookie. It depends on what your client/server architecture is. Web apps use session keys because traditionally web clients haven't held any state so the app server had to. Native clients can have all sorts of state and so generally don't need the server to provide that.
But you need authentication. That's what things like OAuth and OAuth 2 are for. They allow you to authenticate once and then use tokens that can be invalidated server-side. Kind of like very long lived sessions without data.
They are a bit complicated but there are open source libraries for both the server and client pieces or you can roll your own. Most of the complication is on getting the original token which you can short-circuit if you own the client and server. OAuth can get pretty complicated because all requests are signed with a secret token. OAuth 2 can be as simple as a shared secret (thus requiring SSL) in a cookie.
I have a Windows Phone application which is reading and writing data from a WCF Data Services service which is hosted in and ASP.NET MVC 3 application.
I can configure both client and server as necessary. I'd like to use OpenID if practical, and once a user is authenticated on the phone they should be able to browse through data which is associated with their OpenID.
How should I configure client and server to make that work?
To use OpenID in your app you should look at using an embedded WebBrowser control which connects to the provider site (or your site which can redirect). When the OpenID provider returns to your site (embedded in the browser control) you'd pass necessary identifiers back to the app.
There's an example of doing this with a twitter app (using OAuth) at http://blog.markarteaga.com/OAuthWithSilverlightForWindowsPhone7.aspx
OpenID is an awkward choice. It sounds like the user already has data associated with their account, which means that the user would have to login to the server at some point in time to set up this data, and then login to the app with the same credentials to access this data. The issue is that of securely verifying that the client app has indeed authenticated the user in question. Assuming that the client app (somehow) has the user's OpenID is not enough because the server can't implicitly trust what the client app tells it.
Off the top of my head, I'd say, what could be done with OpenID is as follows.
First, set up OpenID authentication on the server. Then, when the client app needs to authenticate, it should use the WebBrowser control to point to a server URL that, in turn, lets the user authenticate with their OpenID provider, and points the browser back to the server with the authentication info. At this point, the client app is unaware of the user's authentication status, but the server knows who they are. Now, the server can generate a single-use auth key for the client to use. It can redirect to a special URL with that key in it, at which point the client detects said URL, extracts the key, hides the WebBrowser control, and uses that key to talk to the server. I believe that would be a secure way to do such authentication, but like I said, this is just off the top of my head.