I'm trying to create a web application that uses a Web API to perform database operations. I've created a project at work that uses Windows Authentication on the API Level. Since this is an intranet web application I don't need to implement a login mechanism on the web application. However, this project I'm working on can be private or public web application and I would like to implement a login mechanism but I would like to be able to specify what type of security to use i.e. LDAP, generic username/password, Google, Facebook, etc.
The question is, what is the best strategy to implement security on both Web Application and Web Api. For Web Api, I could probably implement some soft of token mechanism like other Apis. But not sure if there are other ways.
Is Sign-in option like Google, Facebook, etc done on the Front-end side? or can I Implement it on the WebApi side?
The best practice on this case,
Web Application: client certificate authentication or username/password
Web API: JWT
or if the target company uses G suits with the company domain, Google will be okay.
You can set a filter using domain name of the email address.
Related
We are in the process of developing a mobile (native) app, and are looking at how we should do user authentication. Most of the information I have found have been about web apps and / or third-party apps accessing public APIs. OAuth 2 is therefore recommended to be used most of the time.
Since we develop the app and our API isn't public, it seems like the Resource Owner Password Credentials OAuth 2 flow could be an option, but according to oauth.net that is not recommended any more.
We are using Google App Engine (with Node.js) and Cloud Endpoints (Not sure if end-points would be needed since it's a private API, but that is another question) as the back-end, and both Firebase Auth and Auth0 has built in support in Endpoints. However, we have some special requirements that doesn't make those services suitable (Swedish BankID for example).
What other options are there when authenticating users? Could we write an app in App Engine to check the users credentials against our database, and then send back a JWT (Cloud Endpoints supports custom authentication methods as long as they use JWT)? Would it be safe to do this ourselves? I have found some Node.js libraries for authentication, but most seem to be aimed at web apps. Are there any that are suited for a native app front end?
For authentication, yes, you can perform the check yourselves, in your database and deliver or not a JWT according with the authentication result.
However, and it's obvious, this authentication service must be public (because it's for authenticated unauthenticated users!). And thus, you can be expose to attacks on this service. And because it's the authentication service, if the service goes down, no one can no longer sign in, or worse, if you have a security breach, your user database can be stolen.
That's why, to use existing services, with all the protections, all the resources (people, monitoring, automatic response, high availability,...) deployed to managed a large number of threats. Firebase auth, Auth0, Okta (...) are suitable providers but I don't know your Swedish requirement and you might not avoid specific developments
At the moment we are building a web shop as a SPA application. All the SKU information is provided by a Web Api 2 service.
Of course the web shop is publicly available to every visitor, and currently there is only one user who can log in to manage the web shop: the administrator.
For the administrator we built in the basic authentication with the bearer token, as a lot of samples on the internet shows us, but now we need every user to log in before they can see any product. Not really what we have in mind for a web shop ;-)
What we would like to implement is that our Web Api is not available to the world but only for our SPA application. Every blog post or tutorial on authorization seems to assume that there is always a user that needs to log in, in our case there is only one user: the administrator.
The AllowAnonymous attribute makes specific API calls available to the world again, so that's also a dead end.
Basically it comes down to preventing any other apps (web or mobile) to fetch the data from our Web Api.
What would be the best and most secure approach to secure our Web Api without having the anonymous visitors of our web shop to log in?
Solution for now: Altough I'm not 100% happy with this solution, it will work for now. We implemented the OAuth Implicit flow with CORS enabled for specific domain.
You should take a look at the OAuth 2.0 client credentials flow. The client in OAuth speak is the application and not the user using the application. This way you can make sure only your SPA app can access the backend API.
The parts that only should allow access to the administrator, you can decorate with the [Authorize(roles = administrator)] attribute, which prevents any other roles from having access.
I think Json Web Token could help you with this. This article has more information about using Json Web Token for granular authorization of your web api.
OAuth 2.0 is inherently insecure, and solely relies upon SSL. It has no encryption, and most of the latest web api gurus are suggesting that it's dead. This again is relative to what you need the security for. If it's for a social SPA where the data isn't financial or medical, for example, and good enough SSL security is ok, then perhaps OpenID or OAuth2 is suitable.
A much better solution is to implement Identity 2.0 for the Web API authentication flow, and then utilize something like Hawk Protocol for HTTP MAC implementation. Check this out : https://github.com/webapibook/hawknet for an example.
For OAuth2 framework and a extensible solution, check out Thinktecture.IdentityServer3 on GitHub
For a lightweight .net 4.5 Web API Tokenization solution, check out Thinktecture.IdentityServer2 on GitHub.
Hope it helps.
We are building an application with following attributes:
Consists of a web app, a web API, and mobile apps in future
The web app will contain HTML pages (multiple features that behave
like single pages applications)
The web app will talk to the web API (communicates in JSON, using
JQuery AJAX Calls)
The web app + web API do not follow the standard MVC architecture
Need to support SSO (will be using client Identity Provider) and
forms authentication
mobile will be consuming the same web API
My question is around what approach we should follow for securing the application. Two of the approaches that we are contemplating on are:
Securing the web API only: the web app is purely HTML and all the
data (that needs security) will come from the web API
For this, we thought of using OAuth for securing the web API
Both, the web app and the mobile app will first perform
authentication, generate an access token (follow the OAuth flow)
Securing the web app using forms authentication/SSO, and using HMAC
authentication for authenticating the API consumer (web/mobile app)
This delegates the user authentication to the consumers (web and
mobile app)
The API consumers will use HMAC for authenticating themselves
How can we pass the authenticated user details to the web API? Don’t
want to pass it as a parameter in API calls
Or is there any other approach that is better than the ones we evaluated above? Has anyone handled a similar situation where an HTML web app uses a Web API, and authentication happens using SSO + Forms/custom authentication?
If you have any comments agreeing/disagreeing the two approaches, that would be welcome as well.
We understand that the web app cannot be purely HTML, and some of the SSO authentication part will have to be handled on the server side and that is ok. But the core application will be HTML + Web API.
Here is some additional information related to this:
- Using ASP.Net with Framework 4.0 (with VS2010 IDE)
- Using Web API 1, but open to switch to Web API 2
You may benefit from building an external authentication/authorization identity management component in your architecture. Your current use cases can probably be covered by the tools that come with ASP.NET, but the architecture will be hard to extend as you start adding different types of clients and SSO scenarios. Look at this and this articles for a more detailed explanation.
Azure ID and Access management offering can be a good option. If you don't want to use the cloud, there are some third party and open source identity servers available.
Here is a good free book to help you understand federated identity concepts in the context of Microsoft technologies.
What is the simplest security that could be applied in ASP.NET Web API in MVC 4 to prevent external users from accessing the Web service , is there anything simple enough like authorization of some token which could be maintained for each instance?
It depends, a Http Web API is stateless by nature. If you are invoking the Web API from a web browser using Ajax, you might rely on cookies for maintaining the user identity in the session. Otherwise, other traditional HTTP authentication mechanisms like basic authentication requires the user credentials in every call. You might want to take at the Thinktecture.IdentityModel library, which provides a lot of extensibility points for authentication.
http://leastprivilege.com/2012/10/23/mixing-mvc-forms-authentication-and-web-api-basic-authentication/
Regarding authorization. The framework already ships with a few attributes like AllowAnonymousAttribute or AuthorizeAttribute that you can use to decorate the Web Api methods.
Better you could have search about Authorization in MVC. Yes it does support it. Please check the below links which could be helpful.
Secure MVC 4
Redirect unauthorized Users
Custom Authorize
I am busy doing some research into using REST services with mobile applications and would appreciate some insight. The scenario is as follows.
Consider a web application that provides a service to users. The web application will also be the main interaction point for the users. This will be done in Grails, and secured with Spring Security.
Now, we want to provide a REST service so that users can use the service via mobile applications. Since Grails has such nice support for making the existing web application RESTful, we will use the built-in Grails support for that.
My question now is, what would be the "best" way to secure the REST service interface so that it can be use from mobile applications (native- iOS, Andriod, WM7, BB).
The information exchanged are highly sensitive, so the more secure, the better.
Thanks
We decided to split our grails project in three...
model-domain-project (This is the "admin" section with all the views/controller scaffolded, and all the services, domain)
web-app (this is the main application, controllers, views)
api-rest-app (this is the rest controllers)
The model-domain-project is a plugin that it's plugged in the web-app and the api-app, contains the domain model, services, and all the database security, transactions, etc.
The web-app is all the html templates, views and controllers, here we are using the attributes of Spring Security
The api-rest-app we are using grails-filters and we are using Basic-Authorization via https with a token with an expiration date...
if the expiration date of the token is reached you will have to ask for another token with a "request-token" we sent you with the first token... (it's more or less like oauth2)
To get the two first tokens, you will have to confirm the device via a login with user/phone/password then you receive a key via sms that you will have to enter in the app
Do not know if this the best way, but it's the way we do it...
Sometimes we are using the web-app as client and call the api-rest-app...