This may have a simple solution that I'm just not seeing, but Android apps can be decompiled, so people can extract your OAuth key and secret from your code. What is the best way to prevent this?
All depends on your architecture. May be the best solution is not to place secret data in apps but better in service/server application. All what can be decompiled will be decompiled. You may only gain time for exctracting data from apps by means of encryption.
Related
I am creating a new React SPA. Users of a legacy app need be able to use the new app without re-authenticating. So I need to support SSO.
It's important to note that it is also required that users of other (currently unspecified) apps should also be able to use the new app without re-authenticating, so whatever approach I take needs to be sufficiently decoupled to potentially allow this.
The legacy app supports authentication via Shibboleth, the new app currently has no authentication method, but uses JWT for authorisation.
I'm wondering if anyone has any experience of such a scenario? It seems to me that I probably need to be create an OAuth2 authorisation server for the new app to talk to and I need to somehow bring Shibboleth into the mix for the authentication, maybe with the authorisation service acting as a Shibboleth Service Provider. Googling around hasn't revealed much useful info.
Is what I've described along the right lines? I know it's very high level and woolly, but I'm really not sure of the approach to take. Any advice, information or experience in this area would be gratefully received!
GOALS
It's a little bit of a subjective question, but the main goals are usually as follows:
Focus on building your UI and API security in a future facing manner
Also provide good Login Usability
Also deliver on non functional requirements such as availability / reliability
AUTHORIZATION SERVER
On the first point, the modern option is to integrate UIs and APIs with an Authorization Server - perhaps as in My Tutorial. Your architecture is then good, but the migration is not trivial.
FEDERATING TO SHIBBOLETH
The Authorization Server can then redirect to Shibboleth and talk SAML2.0 to achieve Single Sign On, as you suggest. It is a complex solution though, and may be a backwards step in some ways.
AVAILABILITY
This is usually a big concern, and most companies use a cloud provider such as Azure / AWS due to its high availability / low maintenance / low cost. Would this be a better option for you?
I'm trying to develop an open source solution which will be deployed on Raspberry Pi's or similar SBCs. The RPi part is only relevant insofar as it means all the code and app resources need to be publicly available.
The solution needs to read Twitter statuses, as close to real time as possible, and with as little interference from third parties as possible. I found Twitter's Streaming API, which is blazingly fast, and would be perfect for my application – except it requires OAuth. And as far as I can tell, the OAuth mechanism isn't well suited for deployment on users' machines, since it relies on a secret key which belongs to the application owner (the consumer secret).
I couldn't find any easy way around this – the only solutions I could think of are either handling request signing on a central server, or asking each user to create their own Twitter app account. And I find both solutions terribly distasteful.
Do you see any elegant way out?
It turns out this is indeed not currently feasible cleanly with any of Twitter's public APIs; not now, and not in the foreseeable future. Refreshingly, for once we do have proof for a negative: I also asked this on Twitter's own forum, and I was lucky enough to have my question kindly answered by Andy Piper, Global Lead Developer Advocate at Twitter. There you go.
Your app can open a web browser with Twitter's application authentication webpage loaded. When the user enters their credentials Twitter will return a code which they can copy/paste into your app. It's not particularly elegant. Here is a Python example of the workflow: https://github.com/geduldig/TwitterAPI/blob/master/examples/oauth_test.py
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.
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. :)
Greetings!
Say I have fleet of mobile devices that are the consumers in a three-legged OAuth. The user authorizes each device, but then hands them over to other people. I would like to have these people then need an additional password to interact with the mobile device's protected resources.
Is there a standard, best practices way to do this? Could I use another, layered 2-legged OAuth, or should I do something else?
--Edit--
P.S. Since I posted this I discovered Twitter's "4-legged OAuth" for things like TwitPic, using a "delegator" this is a step towards answering my question, as it appears that OAuth can, in principle, be n-legged.
Are there other 4-legged and/or n-legged OAuth implementations floating around I can read over?
Thanks again,