So I'm creating an iOS framework that will be a static library that developers will add to their project, when they create an account on our site I'd like to give them a unique token that they put in their app to use my static library.
For iOS dev's, think TestFlight, you sign up, get an App ID and then run [TestFlight takeOff:<#some-key#>];
I'd like to authenticate the requests that the framework makes to my REST webservice (using https).
Is there anything I can do to prevent people from "breaking into the app code" and stealing the developers api token and using it to make requests? My api endpoints will not be public information, at least for now. and I can't authenticate the user because it's a framework and that would be an awful UX.
The question is, is there anything I can do to prevent this sort of behavior? Should I even care? I will charge the developer per X requests eventually so I was hoping to authenticate this so we don't have spammers racking up a bill for the developer.
How do other iOS frameworks handle this?
Any design ideas and criticism welcome.
I'm not sure what you're trying to do is ever possible. If the text is in the client code, it can be pulled out. SSL-pinning won't really help you here either because the cert is in the client binary as well.
One way you might be able to get close is to use the developer's authentication system. Say a user logs in into the developer's auth system, then server side you generate a short-lived key for that user. Then the client code can be passed (over SSL-pinning) that short-lived key and use that to make your API calls. However, this requires the developer to actually have a secure auth system, and without SSL-pinning, they're vulnerable to a simple man-in-the-middle attack which will reveal the short-lived key.
You can try to minimize the damage by throttling API calls on your end, or trying using per-app heuristics to approximate what normal API usage would look like. Anything out of the norm will get flagged as potentially hacker based. That might be enough to flush out most of the wanna-be-hackers. The true hackers will learn of the throttling and be clever about circumventing it...
Your safest bet is to make it a server-side library instead of a client-side library. However, that's certainly not a super-sexy solution either. Not all apps have a server side component... and even if they do, once the developer's server is compromised (ie. gets spammed or hacked, etc) it's game over once again. But, in the end, the nice thing about a server-side solution is that you're at least less vulnerable to an attack and you put the responsibility of securing the system on the developer.
What's really lacking here is some form of Apple-based verification for network calls originating from Apple devices.... but that probably won't ever happen. :)
Related
With OAuth 2.0 PKCE Flow for Installed App (e.g. a desktop app/cli/client library), it seems that nothing is preventing an attacker to:
obtain client_id by using the original app (client_id is public and can be easily copied from browser bar/source code)
make a fake app to mimic original app
use the fake app to seduce the user to grant access and thus obtain a refresh token which essentially means full access within requested scopes
Without PKCE, it's hard to fake an app and obtain a refresh token because that would require an attacker to obtain client_secret. It seems to me that, although PKCE offers security improvements over implicit flow, it makes it so much easier to masquerade authentic apps that use OAuth 2.0?
I'm using googlecloudsdk (gcloud), it seems that it has client_id (and even many client_id/client_secret pairs) hard coded into the source code, which is distributed to the client. I doubt there's anything to stop attackers to fake gcloud and thus gain access to user's GCP environment (for proof, run gcloud auth login and it will show you the url in the console that an attacker needs.) Could anyone clarify/help me to understand what's going on?
Private URI schemes are probably the best you can do on desktop but are not perfect as you say. It is what I use for my Desktop Code Sample, but ideally I'd also like to resolve the above concern.
For mobile you can use Claimed HTTPS Schemes to solve the problem - see the answer I added to the post sllopis sent.
I would be aware of Updated OAuth 2.1 Guidance for Native Apps - see section 10 - but I don't think you can fully solve this problem.
It is expected that end users are careful about desktop apps they install, to reduce risks for this scenario. Hopefully operating system support will enable better cryptographic options in future.
Just wanted to follow up on this because I had the same question myself, but also answered it myself and I wanted to add something that wasn't said here:
When you set up the application on the oauth2 server, you have to set up a number of redirect_uris, allowed places to return to after authorization is complete. This means that someone who creates a phishing attack like the one you described cannot return to their own app after login, and will never receive the code.
There is a separate attack where you try and return to a legitimate app from an illegitimate app, however this is solved by the inclusion of the state variable.
I have been using Cookies for authentication and session control in my web apps, and am content with its functionalities.
I was introduced by an iOS app developer that the new hot thing is JWT (JSON Web Token). He told me that JWT is the way of doing authentication and sessions for native mobile apps, and without giving specific examples, he suggested that both iOS and Android apps have various problems with Cookies.
So I looked up JWT, e.g. http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/ and https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/, and I failed to see why it is significant better (or even that different) than Cookies, and more specifically, why it does better in native mobile apps. It seems that, at least iOS, handles Cookies just fine (Persisting Cookies In An iOS Application?).
So my question is, for a native mobile app that interacts with a server-side API, what are the specific advantages and associated use cases for using JWT over Cookies for authentication and sessions? Please highlight the ones that Cookies simply cannot do or does it much worse.
We software developers (sometimes) have the tendency to apply the new hot thing everywhere we look; it's possibly a variation of the saying if all we have is an hammer, everything looks like a nail where in this case we just feel a desperate urge to use this new thing we learned about.
One interesting point about this comparison is that neither JWT or Cookies are in fact authentication mechanisms on their own; the first just defines a token format and the second is an HTTP state management mechanism. Only this is sufficient to give us an indication that advocating that one is better than the other is wrong.
It's true however that both are vastly used in authentication systems.
Traditional server-side web application have used cookies to keep track of an authenticated user so that they were not forced to provide their credentials at every request. Normally, the content of the cookie would be an (hopefully) random generated unique identifier that the server would use to find session data stored on the server.
However, for a new type of web application - the API - it's more much more common to accept a token (in JWT format most of the times) as a way for the server to decide if it should grant access to who's making the request. The reason for this is possibly because while a traditional web application had one major type of client, the web browser, which has full support for cookies, the API's are generally used by much simpler HTTP clients that don't natively support cookies.
I think this is also why we could possibly argue that token based authentication makes more sense for native mobile applications. These applications generally depend on a server-side Web API and we've seen that if the API supports tokens it will increase the range of clients that can use it, so it's just the most practical thing to do.
In conclusion and to try to answer your concrete question, I would say JWT's do have an advantage over cookies on native mobile applications just because of the fact they are currently in very common use, this means more learning resources, SDK's, known pitfalls (mostly because someone else already did it and failed), etc.
Nonetheless, only use them if they give you the security assurances you need and end up simplifying your scenario. If you haven't gone through it already, I think you'll also appreciate Cookies vs Tokens: The Definitive Guide.
I cannot speak for Android but on iOS cookies work with URLSession as good as headers. Once you can utilize the (standard) API right (e.g. dedicated, properly configured session with cookie storage per web app...), iOS should be a rather negligible factor to this decision.
UPDATE: I failed to mention earlier that we want solution that will be flexible with authenticating users from within our databases or by asking other servers to tell us if the user is authenticated. It is also worth mentioning that these other servers are not under our control so we can't enforce a specific user model.
I had a long and hard read on OAuth and OpenID but they are both not a suitable solution for our situation and will make the process harder to the user. This is something that has been solved a thousand times, yet I cannot find the solution.
What we are looking for is a framework that can be used in a REST services server to authenticate users (no third-party clients involved) with their username and password.
The solution must not pass the username and password except the first time on login and use tokens for further authentication. Even though OAuth does use tokens, it is designed to allow third-party clients access to the service-providers resources. That is not the case here, the services are for our own application only, the only thing needed is user authentication.
What do you guys think is the most appropriate solution?
Configuration:
-Spring server that provides RESTful services with our thinking going towards using Spring Security with some user management and token management framework.
-iOS Device that will be making HTTPS calls to the server.
What we ultimately want is to have the device send a login request and receive a token if the login was successful, later on make requests using that token. Just like Facebook, excluding third-party involvement.
Is there something that is ready to be configured in our server? Or should we consider building our own token management, comparison and generation software?
Is using Spring-Security with an iOS application without involving storing cookies or redirecting to pages possible?
OpenStack offers as part of it's many projects related to open source cloud... the project Keystone. Which does this pretty much exactly what you want.
You might want to check it out here:
http://docs.openstack.org/developer/keystone/
I'm currently building a mobile application (iOS at first), which needs a backend web service to communicate with.
Since this service will be exposing data that I only want to be accessed by my mobile clients, I would like to restrict the access to the service.
However I'm in a bit of a doubt as to how this should be implemented. Since my app doesn't require authentication, I can't just authenticate against the service with these credentials. Somehow I need to be able to identify if the request is coming from a trusted client (i.e. my app), and this of course leads to the thought that one could just use certificates. But couldn't this certificate just be extracted from the app and hence misused?
Currently my app is based on iOS, but later on android and WP will come as well.
The web service I'm expecting to develop in nodejs, though this is not a final decision - it will however be a RESTful service.
Any advice on best practice is appreciated!
Simple answer: You cannot prevent just anybody from acecssing your web site from a non-mobile client. You can, however, make it harder.
Easy:
Send a nonstandard HTTP header
Set some unique query parameter
Send an interesting (or subtly non-interesting) User Agent string
(you can probably think of a few more)
Difficult:
Implement a challenge/response protocol to identify your client
(Ab)use HTTP as a transport for your own encrypted content
(you can probably think of a few more)
Of course anybody could extract the data, decompile your code, replay your HTTP requests, and whatnot. But at some point, being able to access a free Web application wouldn't be worth the effort that'd be required to reverse-engineer your app.
There's a more basic question here, however. What would be the harm of accessing your site with some other client? You haven't said; and without that information it's basically impossible to recommend an appropriate solution.
I'm starting a new system creating using .NET MVC - which is a relatively large scale business management platform. There's some indication that we'll open the platform to public once it is released and pass the market test.
We will be using ExtJs for the front-end which leads us to implement most data mining work return in JSON format - this makes me think whether I should learn the OAuth right now and try to embed the OAuth concept right from the beginning?
Basically the platform we want to create will initially fully implemented internally with a widget system; our boss is thinking to learn from Twitter to build just a core database and spread out all different features into other modules that can be integrated into the platform. To secure that in the beginning I proposed intranet implementation which is safer without much authentication required; however they think it will be once-for-all efforts if we can get a good implementation like OAuth into the platform as we start? (We are team of 6 and none of us know much about OAuth in fact!)
I don't know much about OAuth, so if it's worth to implement at the beginning of our system, I'll have to take a look and have my vote next week for OAuth in our meeting. This may effect how we gonna implement the whole web service thing, so may I ask anyone who's done large-scale web service /application before give some thoughts and advice for me?
Thanks.
OAuth 1 is nice if you want to use HTTP connections. If you can simply enforce HTTPS connections for all users, you might want to use OAuth 2, which is hardly more than a shared token between the client and server that's sent for each single request, plus a pre-defined way to get permission from the user via a web interface.
If you have to accept plain HTTP as well, OAuth 1 is really nice. It protects against replay attacks, packet injection or modification, uses a shared secret instead of shared token, etc. It is, however, a bit harder to implement than OAuth 2.
OAuth 2 is mostly about how to exchange username/password combinations for an access token, while OAuth 1 is mostly about how make semi-secure requests to a server over an unencrypted connection. If you don't need any of that, don't use OAuth. In many cases, Basic HTTP Authentication via HTTPS will do just fine.
OAuth is a standard for authentication and authorization. You can read about it in many places and learn; Generally the standard lets a client register in the authentication server, and then whenever this client attempts to access a protected resource, he is directed to the auth-server to get a token (first he gets a code, then he exchanges it with a token). But this is only generally, there are tons of details and options here...
Basically, one needs a good reason to use oAuth. If a simpler authentication mechanism is good for you - go for it.