I have an HTTPS WebService that need to be accessed from a Mobile (iPhone) application. both are developed by our-side.
We need to secure the Mobile access to this Service. So we used a username/password credentials.
We are aware of OAuth, but we need a more simple authentication scheme.
What We think of is the following:
The Mobile App shows a Login-form to the User/Resource Owner.
The Resource Owner enter The login credentials on behave of the Mobile App.
The Mobile app connect to the Server at special WS Method (e.g. "ValidateLogin") that takes username/password -probably hashed- as input and returns the HTTP Session Id.
The Mobile app persists this HTTP Session Id -which is a unique key from server side, and may be secure?- to communicate with the Server for subsequent requests (Invoking business methods).
If the Client doesn't communicate with the Server for say 30 Min, the Server will send 403/Session_time_out (The Mobile may remove the persisted HTTP Session Id to indicate to himself that he no longer has access to the Server resources - and It may opt to do so in case if it needs to end the communication with the Server)
In this case, the Mobile will need to use the Resource Owner again to obtain a new session id from the Server and gain access to the Server resources.
The Questions are:
Does the above steps are good enough to depend on?
What do you think from security perspective?
Do you have any other thoughts/opinions?
EDIT: It is a HTTPS WebService
The question is very open in nature, and I believe that it is difficult to answer those general questions with your specific needs in mind.
To answer some concrete questions:
How to secure your app against unauthorized clients?
Look at SSL and Client side certificates.
How to manage user credentials securely?
Look at using the Keychain API in iOS.
Related
I have a relatively successful app in the app store that allows people to view metrics on their iDevice using a JSON file hosted on the their server. The app has a simple settings screen in which you simply type the URL of your JSON file and the app takes care of visualising the data in the file. I use AFNetworking for this.
For example the URL might be: http://www.mylargecompany.com/factorykpi.json
Customers are now coming back to me and asking for the ability to connect to their servers more securely. Problem is there is a myriad of ways you can secure your server.
I need some advice. What kind of standard security features would I need to build into my app. I am confused by OAuth, HTTPS, etc.
I believe OAuth would mean the customers server would have to use it? Can you make a generic OAuth login screen in an app or do you need to know which web server you are connecting to authenticate.
Any advice on even the most basic of security measure would be very welcome!
Regards,
MonkeyBusiness
Security is really a very broad topic. There is no short answer. In any case, both web service and client app need to implement security mechanisms. I would recommend, you provide both the web service and client app.
You likely need some user login with a password, "server verifies user identity" and "client verifies server identity" using certificates. Then you utilize HTTPS which ensures to transport confident data in a secure way. The web service should be implemented with one of the well known web application frameworks since security is a scary business, and tricky. Implementing everything yourself, might end in a suboptimal insecure application.
You should now read more about the complex topic and come back when you have specific questions.
... most basic would be to use https, which would secure the transaction, but anybody accessing the same link would be able to access the same data. Thus you will need some kind of authentication, starting with a simple secret key passed as POST request, username and password and/or via certificates.
I am creating a solution that will contains a website and mobile apps. I will use Zend-Framework 2 for the website.
So, to make it good, I am wondering if it would be a good idea to build :
A REST web service (using zf2)
Another website that will call the REST ws (using zf2)
The mobile apps that will call the REST ws
I will use OAuth for the autentication and security.
My question is, if my website gets the data by calling the REST ws, it will have to make a database request at each call to check the token whereas if I do a "normal" website, my app will be able to use session to store the information of the connected user.
Because, for what I have read, there is no such thing as session with OAuth/REST so for each call, I have one more sql request to check the token validity.
Is it still a good idea to make a full REST service, even for the website or to have a "normal" website and also a REST service API just for the mobile apps ?
Thanks
Oauth is a server to server authentication framework. Like it is between mobile app and your API server , website vs your API server etc. You can adopt an approach where , you generate only one access token for your website client instead of multiple access token for each user from the website. This access token is stored in your webserver vs user cookie in website.Ultimately the aim is to identify all the clients of your REST WS and your website is one of its client and a very trusted one.
This way you can cache the access token to avoid db calls (typically cache time can be equal to or less than token expiry time). Do explore the multiple grant types specified in the oauth spec for this
Regarding maintaining session for user in your website, it is not dependent on whether the back end is a REST WS or not, it can be handled in your website
When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application.
So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,...
This is not managed by OAuth2 ? Or I missed something ?
For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key.
There's no good answer. Native app callbacks typically happen via custom registered URI schemes (e.g.: callback redirection URI is something like: myapp://oauth?code=xyz123). Unfortunately, any app can claim ownership of a given protocol scheme and receive the callback.
This problem is very synonymous with trying to lock down any protocol with "trusted clients". Think of the IM networks battle to lock out 3rd party clients (in early 2000's). Eventually they gave up - since whatever client & protocol endpoints are deployed could be reverse engineered by 3rd party developers.
Note: There is also some active discussion on this topic on the OAuth WG mailing list: http://www.ietf.org/mail-archive/web/oauth/current/msg08177.html
Normally client_id is associated with site's URL - OAuth responses/redirects will be sent only to the registrated Url. So attacker will not be able to receive results of the request on own site (unless somehow your and attacker pages are on the same domain).
I'm building and iPhone App that will make requests to an application of mine running on a server. I'm using REST to build the server's application API. What is the best way for securing the requests from the iPhone to the server and viceversa. Is OAuth a good option? What would you recommend?
Thanks!
If it's a server you control, use a SSL/TLS connection for all communications between the phone and your server. Make sure that the phone app code checks the server's certificate (e.g., to check that it is a cert for your domain name, where your domain name is hardcoded into the source code). This will protect against eavesdropping, man-in-the-middle attacks, message forgery, and other attacks on the data while it is in transit.
There is not really any way to answer the question "what's best" without a lot more information on the security needs of your app.
In general, you should consider authentication, authorization, and transport.
Authentication could be as simple as username/password login. This could be simple authentication, OAuth, kerberos, etc. It is meant to identify the user. Authorization deals with which services are allowed to be accessed by which groups or individuals. You'd need a way to grant and maintain privileges. Finally, securing the transport typically means using encrypted services, such as HTTPS over SSL. This prevent data from being intercepted or altered during transport.
There are many other considerations to think about including how your protecting personally-identifiable information, encryption, etc., but again, there is no one-size-fits-all solution that could be recommended.
We would like to achieve following very general, day to day scenario in any web app. We would like to secure a call from non-windows client (i.e. non .NET client) to WCF web service. Client is mobile device (iPhone, Android or Blackberry, but should work on all of them) and also assume native app will be a banking (finance) domain app . So security cannot be compromised.
User will be provided a screen to enter username and password.
WCF Service call will authenticate the user credentials ( we would want to know how to secure this WCF service call)
After successful authentication, all the subsequent call does not have to pass username and password.
Each service call should be able validate the credentials or check whether it is a already authenticated user and if it is then load user roles from some store to authorize the call.
As you can understand we are looking for secure session from a now windows client to WCF Services. Looking forward for a solution ( avoiding ASP.NET sessions) to secure every service call and to authorize call.
Please reply back with code, configuration
Thanks and regards,
Milind
That is perhaps day to day scenario in web app but not in the service. Day to day scenario with a service is authentication in each call and avoiding any session as much as possible.
The answer to your security requirement is HTTPS. That will ensure that the communication will not be compromised. The answer to your authentication requirement is Basic authentication (and perhaps custom HTTP module for handling authentication if you host the service in IIS) or UserName token profile for passing credentials in message body (only SOAP services).
User will be able to provide his credentials in your mobile application but your mobile application should use these credentials for every call to the service (in .NET world these credentials are set only once for communication proxy but that is just implementation - they are still send within each call).
WCF supports security session implemented on top of WS-SecureConversation but neither of mobile platform supports it and it is pretty tough specification so you will no try to implement it yourselves (if you do, you can sell it as separate project). Moreover with very poor SOAP support on iPhone you will most probably use REST service where nothing like secure conversation or even session exists.
If you want any session you will have to use ASP.NET Session (= AspNetCompatibility) or you will have to implement your own session management and pass session token in cookie (= generally same mechanism as ASP.NET session) or in message body (= generally what WS-SecureConversation does but it handles all security stuff around this).