I have been coding against a Delphi EXE (win32 desktop app) to access twitter and do certain functions. It used to use Basic authentication with the api limitation. I know I have to convert this to OAuth. I have been reading over the documentation trying to determine the best approach. I understand the best method is the Web browser with a call back url. I also know that Twitter includes a Pin Based (oob) authentication method. I figured this was the route to go with this application, but I want to make sure since that is not seamless. It requires the user to go external to the application and get a pin number. It also is not as secure since the access token returned never expires.
I am using Indy v10 components to do the GET/POST operations, so I am wondering if there is a way to do this using them and being able to do a callback and not use the Pin authentication method.
Can anyone help me?
Also I've been trying to get Chuck Beasley's Twitter Class working in Delphi 7 with Indy v10 and I've been having trouble. IdObjs and Idsys don't exist anymore. Has anyone got this class to work with my scenario?
Thanks,
David
OAuth is a standard used for Web applications, its text is liberally littered with the word 'agent', meaning a browser. The best solution IMHO is, if possible, to actually have a callback URL, meaning you have your own site which provides the service to back your application functionality. There are services that make this possible for third parties already, like JanRain. If these options are not feasible (meaning you cannot provide a true WWW site for the callback URL) not feasible, then your only option is indeed the out-of-band authentication, oob. Don't even think about having the OAuth authentication call back the app listening on some port, that is completely unreliable for 1) the vast majority of apps will sit behind some sort of NAT device (router, outbound proxy) which makes them unreachable from the OAuth prvider and 2) the OS firewall will block your incoming calls.
In the mean time, Beasly's Twitter class has been expanded/updated; see the latest incarnation
I've started a library that uses Synapse to access twitter. It can use OOB/PIN authentication and predefined oauth token/secret. It can be extended to use browser based auth. Currently written using FPC but should be adaptable to Delphi quite easily. FPCTwit code
You may wanna try my take on twitter, supports unicode as well unlike the other delphi implementations:
http://eden.fm/2011/02/27/twitter-library-for-delphi/
I don't use Indy though, but ICS
Related
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.
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.
I'm mildly familiar with DotNetOpenAuth and OAuth in general, but in terms of Web API development, what is the best way to lock down a web service in terms of the following criteria:
Ease of implementation
Interoperability/compatibility with end-user facing platforms (iOS, Android, Win Phone, Flex...)
Whether or not it is clearly standards-based (like OAuth for example)
Thanks!
please take a look here: OAuth 2.0 in Web API
Inside the WebApiContrib project there are also Basic Authentication samples which is straight forward but it should not be used without SSL.
The DotNetOpenAuth .zip download includes a sample WCF service that is protected by OAuth.
There are a couple of wcf web api implementation to handle authentication on internet. I have done one as well # http://misaxionsoftware.wordpress.com/2011/07/29/secure-restful-web-service-by-wcf-web-api-no-https-seriously/
Note: code is based on Preview 3, some class name has changed in Preview 5.
The idea of implementation is ensure secured communication without SSL.
It's easy to construct. The function is transparent to your service because all the work is done in message handler. You don't bother to call the authenticate function in your service method.
Compatible with end-point where RSA encryption is supported.
Standards-based, hmm... Standards varies from case to case...
I'm a bit confused about all this OAuth bruhaha in the sense that all the examples I can find are for web applications and none of them for desktop applications.
I understand the Web application work flow, but that includes some redirections between the web app and twitter.
How does one do this in an desktop application?
How does the redirects work?
Should I have to include a Web Browser object?
Is there a way to go around this?
Could anyone point me to resources instead of a full blown solution please?
Thanks
Not sure which language you're using, but the .NET library for Twitter called Tweetsharp has a post on using Tweetsharp from a desktop app and authenticating via OAuth. See http://tweetsharp.com/?p=68. If you're not using .NET then perhaps it will inspire something you can do?
Basically, what tweetsharp does is launch the browser to the authentication URL and then waits for the user to return. I don't know of any way to do this other than something like that (Or include a WebBrowser control of some kind to launch the authentication URL in your own window).
Here's a straightforward solution, implemented as a set of PHP scripts for running from the command line. Well documented and explained, with a helpful 'verbose' option for debugging.
http://nullinfo.wordpress.com/oauth-twitter/
After some poking around and asking some questions about this subject to some other programmers, it looks like it's still an ongoing discussion, with no visible light at the end of the tunnel.
But for people interested on the ongoing discussion, here's the best link to have:
OAuth Desktop Discussion
I've seen a few desktop apps get around this by effectively embedding a browser into their program, so they can just open the in-app browser window to let you do the login and authorisation. This strikes me as a bit of a cheat or defeat of purpose because you still end up typing your ID and password inside the application anyway.
One possibility I was thinking of was, your desktop application could embed a mini HTTP server inside it. So then it launches the default browser to perform the authorisation, with a callback URL something like http://127.0.0.1:8765/oauthorized and then just listen for it.
Would that work?
Not sure what you would do for console applications... spawn a copy of lynx?
Include a WebBrowser control in your app. Put it in a panel or a separate form that you'll Form.ShowDialog().
Create a callback for the browser's successful posting of OAuth and one for a rejection. Don't forget to check for a FailWhale.
In the callback, you close the panel or form and store the token.
Here's a nice overview with sample code and everything: http://tweetsharp.com/2009/04/how-to-authenticate-a-desktop-application-with-oauth/