I have 2 projects an mvc5 & webapi. I am wanting to call the api from a pure clientside manor even though im using mvc (I am slowing trying to migrate old code into a spa like application still being able to maintain the current codebase).
The url of the api sits under the main domain e.g. subdomain.mydomain.com/api so I dont have to worry about jsonp or crossdomain stuff.
How do I secure the api. Am I right in thinking when a user logs into the mvc5 application there is there some kind of key or token I can access. I store it somewhere on the site and add it in the request header?
If I follow this approach how do I validate the token at the api end. An actionfilter that reads the header? or is there a cleaner method.
The only information I can really find on using the api is to use basic auth which is something I dont really want to have to do.
I think a nice simple(ish) way to do it is to use a token based method. So the client authenticates once, you give them a token, then subsequent requests pass the token and the server checks it.
It does require some custom code, but I have seen a few good examples. Here is one that I loosely followed:
http://www.codeproject.com/Articles/630986/Cross-Platform-Authentication-With-ASP-NET-Web-API
It enforces HTTPS, then does the token generating and validation after that.
Related
I have a ASP.NET Core 6 web app. I'm using Identity for an authentication. It is in its simplest form - users need to put credentials in the login page to access parts of aplication.
Now I need to expose one endpoint. It should be accessible by application from a different server. Therefore a solution with redirection to a login page and storing credential in caches doesn't make sense (keep in mind I want to keep it, just add some filtering on a particular api).
Instead I would prefer to allow hitting this enpoint with some kind of token. Another solution that comes to my mind is to whitelist the server of the application not to require authorization.
I don't know which of these are possible or recommended. Will gladly hear your advices.
I am developing an ASP.NET MVC web application. The application is consuming a REST API, but authentication for REST-full application is quite unclear for me.
As REST is stateless, do I have to implement two different Authentications with two different databases, one for client, and one for the REST service?
Or, do I have to send the login/password each time, to authenticate on the server?
Please give me some advice or tutorial on this.
You can authenticate a Web API using individual user accounts that are stored in a database.
In this case client should obtain access token first. And then include it to each request, that requires authorization, header:
Authorization: Bearer boQtj0SCGz2GFGz[...]
Good tutorial can be found HERE
Also authentication methods could be extended in Startup.Auth.cs with Cookies or some external authentication methods (Google, Facebook etc)
The stateless isn't a main problem in your situation, problem is that browser can only send GET or POST request in tradition way in tag form, so to send PUT or DELETE request you should use Ajax, the easiest way is to use JQuery library and config it to send user credentials in http header(between requests it can be store in cookies) in every request and use basic-authentication if you plan use own auth logic. I recommned you to look some SPA frameworks like angularjs
or emberjs
or backbonejs
to simplify your life from hardcode JavaScript . Also in future you can easy extend your auth by OAUTH 2.0.
I have been implementing a skeleton Claims Based architecture for our services and websites. I'm using WIF, .NET 4.5, MVC / Web Api.
I have the STS (WS-Federation / WS-Trust) and several Relying Parties implemented, and all is working fine.
Now, I want to be able to authenticate in one Relying Party and use that same token (the bootstrap token, I assume) to make Ajax calls to another Relying Party. I can get the Bootstrap Token down in the HTML (is this even a good idea?), and add it to the Ajax call headers as some form of Authentication (Basic, etc).
What I don't know is how to intercept the request in the final Relying party, and "tell" WIF to use that bootstrap token and do it's magic with it (Load, Validate, Authenticate, Authorize, Create Principal, Create Session Token, Write it down in a cooke).
I guess I could do all this by hand using the available classes, but there must be a point where I can just hook up for this. Probably around the SAM / FAM modules, but I can't understand exactly how.
Any ideas?
Thanks
SAML is not a good fit for being consumed in html. The format is complex and relies too much on WS-Security for cryptography. I see more adoption these days of OAuth2 (It was OAuth-Wrap in the past), although is complex as well. If you want to explore that path, I recommend the ThinkTecture Identity Server as a quick solution.
http://weblogs.thinktecture.com/cweyer/2012/11/oauth2-in-thinktecture-identityserver-v2-implicit-grant-flow-with-javascript.html
Thanks
Pablo.
I am working on an asp.net mvc-4 web application and I have started implementing some web services which provides statistical information about my site. But to make sure that only authorized and authenticated consumers can call and consume the web services I am thinking of defining a master login username and password for each consumer, and when a consumer sends a web service request he should include these master login username and password (stored as a hash value ) in the web service calls.
For example the web service link to call specific web service from my web site will look as follow:-
/web/json/statistic/getsummaryinfo/areacode?j_username=masterusername&hash=D012B772672A55A0B561EAA53CA7734E
So my question is whether the approach I am following will provide a secure solution to my web services and to the consumers? OR my approach have security holes I am unaware of ?
:::EDITED::
I am using the WebAPI controllers to implement the web services inside my asp.net mvc-4.**
Best Regards
There are a few ways to make sure things are secure.
http://techcrunch.com/2012/11/08/soa-softwares-api-management-platform-and-how-it-compares-to-its-sexy-counterparts/ This article just came out today highlighting some API tools. I'm not sure how big you are or are planning to be, but if you're looking for scale, these tools seem to be pretty popular (note: I haven't had a large scale API project myself, so I haven't used these).
You can use something like ServiceStack to build your API layer. It has authorization and authentication built in with a boatload of authentication providers. It scales well and, after a call to authenticate, is session-based so you don't have to authenticate each call.
You can use "signed" requests. Signed requests often look something like: "take all the parameters for the request as a querystring, append a 'secret consumer key' to the end of the request', and then sign the request by appending the md5 hash of the results (without the secret key!!) to the request." This is a safe way of doing things because even if the request is made client-side (AJAX) it is generated server-side using a secret key. So you can ensure that things weren't tampered with.
You can go the oauth/token route (which often still uses method #3 above).
You can go with a simple API key that can be revoked (again, fotne used with method #3). bit.ly uses this method I think.
Option #2 is my favorite. I like ServiceStack. But to be honest the learning curve for your first project can be a little steep.
A master username and hashed password feels weak to me, so I'd strongly consider at least looking around at how others are doing it.
HTH
I do not consider your way to be safe. If I could listen on the wire and cache the request I will have the login an the password to the service. There even does not matter if the password is hashed or not. I like the point 3. in Eli Gassert's answer. It sounds very useful and light weight and you are not exposing the password because it is hashed "somewhere" in the request.
I am building a RESTFul API and wondering what's the best way to do auth? Users will need to authenticate. I know of three ways:
1.) Pass API key in every RESTFul requests:
http://api.mydomain.com/api-key-here/get-users
This is nice because developers can immediately start using the API by simply copying URL string into the browser. Are there any potential security risks though?
2.) Every request passes the API key in the header of the request.
This seems to be more secure, but developers can't make requests via their browser. CURL is required.
3.) oAuth
I must admit I don't know much about it, but seems very popular. My concern is that its a barrier for developers to start using the API. They first must be familiar with oAuth, and have it setup.
Thoughts? Thanks greatly.
If your concern is burdening developers with a high cost to entry, I suggest basic auth, but running your API over https.
I do this with Diligent Street and it works really well. I use an API Key and couple it with a Secret as the username/password combination for basic auth.
I have employed the technique found here: Build a RESTful API. This solution uses an MD5 hash of your API ID, API secret and the UNIX Time stamp and passed in the HTTP header. This authentication method is the same used by Mashery’s Authentication.
This link references and contains a full blown starter kit for creating an API that has Auth, Membership and*API Usage Metering* along with a supporting EF database.
As for testing the service you can use RESTClient to execute HTTP calls with custom headers instead of using Curl.