I am new to mobile web programming - having spent a lot of time designing back end Windows services and some IOS native programming recently.
We are in the process of designing a new app for usage by our end clients. We need it to be light weight, responsive and also work on all mobile devices - IOS, Android and Win 8. After much research we have narrowed down to using HTML 5 based JS framework - namely either Chocolate Chip UI or Phone JS. Server side code is PHP.
I have a question about the best practices for authentication when it comes to mobile Web applications and sites
We could present the login form with user details and post to server/authenticate and write to an authentication cookie and then redirect to an HTML 5 page from which point on all data GET and POST is using REST Calls.
Or not post to server but authenticate using a service and store an authenticated token or cookie and check when requesting/posting data.
But are the above methods still relevant - since i have never had to deal with UI authentication before - what are the best methodologies when designing mobile web apps specially with regards to authentication?
Im my JAVA EE projects, I'm using a JDBC Realm for storing users, passwords and roles and JAVA EE build-in Container Managed Security for securing my webpages bases on the roles. If a user is not authenticated a Form will be shown where he or she has to enter the security information. The web pages get data access by services with CRUD functionality.
For Android, Java FX, WPF and so on I'm using a Restful Interface wrapping the Java specific service to support different programming languages combined with OAuth2 (http://oauth.net/2/). A few benefits of OAuth2 are that no user name and password must be stored on the client side, the obtained token can be refreshed and you could seperate parts of your services by using scopes (read-only, full, only calender access,...) befined by yourself. The tokens must be stored in a database and mapped to the user principal it belongs to if a REST service will be accessed. Your users can be also allowed to register own third-party applications using specific scopes of the REST interface.
Herr is an example implementation: https://github.com/OpenConextApps/apis/blob/master/README.md and here some information about JAVA EE security: http://docs.oracle.com/javaee/7/tutorial/doc/security-webtier.htm#BNCAS
Related
I'm looking for a way to design
Mobile APP <--> Server API which:
authorize user and app for work with server using OAuth2.0
validate on server, that it's legitimate application
Problem I face now: Application in Oauth2.0 terminology is a public clients:
there is no way to secure any static information in application bundle - any one can extract such info and reuse it in fake application.
And if I add some additional method for register new instance of application on Server - there is nothing stop fake application from doing the same thing.
Is there ANY way to exchange data between Application and Server without involving REST API, or get verified information aboute calling application.
I know that answer is platform specific - I'm interesting in information on any platform as I can search analog for others.
For mobile apps use Authorization Code Flow (PKCE) which generates a runtime secret, so that there's no need for a fixed one to be deployed with the app.
A rogue app can potentially use the Client Id and Redirect URI of your app, but one way to deal with that is to use Claimed HTTPS Scheme Based Redirects, as recommended in Financial Grade APIs / Native Apps.
If interested in this approach, my blog has a couple of detailed examples:
Android AppAuth Claimed HTTPS Scheme Code Sample
iOS AppAuth Claimed HTTPS Scheme Code Sample
The Difference Between WHO and WHAT is Accessing the API Server
I'm looking for a way to design
Mobile APP <--> Server API which:
authorize user and app for work with server using OAuth2.0 <--- WHO
validate on server, that it's legitimate application <--- WHAT
Before I dive into your questions I would like to first clear a misconception that I usually find among developers of any seniority, that is about the difference between who and what is accessing an API server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
Think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
So, you need to bear in mind that the guarantee that you know who is in the request cannot guarantee you that the request comes indeed from what your API server expects, a genuine and unmodified version of your mobile app.
Possible Solution
And if I add some additional method for register new instance of application on Server - there is nothing stop fake application from doing the same thing.
Is there ANY way to exchange data between Application and Server without involving REST API, or get verified information aboute calling application.
If your API server can have a high degree of confidence that the request are indeed from what it expects, a genuine and unmodified version of you mobile app then registering a new instance of the application and exchanging data with the API server can be done with the confidence that a bad actor is not involved.
You can resort to UBA and RASP solutions to help you with knowing what is making the API requests:
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
RASP:
Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.
RASP technology is said to improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering.
UBA is based on negative identification models that do their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives. The UBA solution is based on analyzing each API request and they don't have client side realtime intelligence gathering from whats going on the mobile app and its device.
RASP solutions are client side, and the API server has no visibility for what they are detecting and blocking. Once they are client side they can be bypassed without the API server know it happened, therefore it will accept the API requests from this bypass.
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
So, the possible better solution section in the linked answer mentions the use of a Mobile App Attestation solution that will combine realtime background communication between a cloud service and the mobile app to attest the mobile app is genuine and unmodified, and that is running in a trusted device. The API server will then be able to know with a very high degree of confidence that what is making the request is indeed a genuine and unmodified version of the mobile app running in a trusted device.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
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.
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...
I have a basic ASP.NET MVC 3 site using Forms authentication, which will be internet-facing.
I also want to implement a Windows application, purely for intranet usage, which will allow users to maintain various aspects of the ASP.NET user database (it has additional tables and fields beyond the stock schema).
My initial thoughts are that I could do this by having various actions in my controller classes, into which I could pass a dedicated username/password and then within each action method validate those credentials using Membership.ValidateUser() .
I realise I could use mixed-mode authentication with Windows authentication for the intranet part but this seems to me like a lot of unnecessary faffing since the intranet users won't be using a browser to do this.
The Windows application will running on the corporate intranet and will be accessing those MVC 3 actions on the website via internal HTTP requests using this dedicated username/password in the query string.
Question: Is this safe enough?
Hi we have a similar situation, we chose to build the management interface into the web application and using ASP_NET Roles to give access to it.
Otherwise (not sure how it works) but in the properties of a Windows Forms project you have the option of using forms authentication, this could possibly be a better solution.