This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How is oauth 2 different from oauth 1
I know these 2 are not backward-compatible. But, having implemented OAuth 1.0 already, is it easy to switch to OAuth 2.0? Thanks
OAuth 1.0 and 2.0 are two completely different protocols. However, they are designed to solve pretty much the same basic set of use cases and most of the people developing the new version have working 1.0 implementations. So they all made sure it would be trivial to upgrade.
With 2.0 you get more choices when it comes to how you want to issue and authentication access tokens. The providers with early 2.0 support use Bearer tokens which are send over HTTPS and don't include any cryptography on their own. Another (much better) option is to use MAC tokens which are similar in design to OAuth 1.0 HMAC-SHA1 but are simpler to use (no crazy parameters normalization).
The main difference and where the transition can be more complex is when dealing with large scale. 2.0 handles scale significantly better than 1.0 (which actually sucks at it). So if you have needs for scale, 2.0 would make your life much easier, but to take advantage of it, you'll need to do some work.
OAuth 2 relies on https for security, you don't have to "sign" requests anymore, just send your API key and tokens as querystring parameters.
It's really easy to implement, you don't need libraries or anything like that.
Check facebook's graph api to start playing with OAuth2!
OAuth 2.0 is not finalized yet, and is quite different from 1.0. So 1.0 experience is not that much help for 2.0, though it is some help.
As already pointed out, the major difference is that it relies on HTTPS for security so you no longer need to sign requests. This would be good if not for XSS attacks and Firesheep!
Related
I was looking for some information on the Internet about that and ended up on the RFC for The Oauth 1.0 Protocol: https://www.rfc-editor.org/rfc/rfc5849
You can read "Obsoleted by: 6749" at the top of it and if you follow that link, you end up on the The OAuth 2.0 Authorization Framework RFC.
Based on that, can I safely infer that OAuth 1.0 has been deprecated in favour of OAuth 2.0?
Thanks.
Yes and No.
IETF has published a new version of OAuth 2 obsoleting OAuth 1.x and it strongly recommends the new Auth providers switch to OAuth2.
There is a revision to OAuth 1.0a which fixes many of the security flaws found in 1.0 and is widely considered to be the most secure OAuth version yet.
OAuth2 is a completely new protocol and is not backwards compatible with OAuth 1.x. The major differences with respect to OAuth 1 are listed in this thread.
However, not everyone is as happy with the new standard. Eran Hammer-Lahav, the lead author and editor of OAuth specifications, resigned from the committee citing reasons in this blog post.
Homakov, who rose to fame with his exploit on Github, has not so nice things to say about OAuth 2.
So yes, OAuth 2 has officially replaced OAuth 1.x, but there are conflicting opinions on the net on whether one should use OAuth2 or stick with OAuth 1.0a.
Yes )
The most of companies use 2.0 - for example google:
Important: OAuth 1.0 has been officially deprecated as of April 20,
2012. It will continue to work as per our deprecation policy, but we encourage you to migrate to OAuth 2.0 as soon as possible.
but there are some using 1.0 or 1.0a as you can see wiki: OAuth in the chapter List of OAuth service providers
There is also an official information that 1.0 is deprecated RFC 6749: The OAuth 2.0 Authorization Framework
.. This specification replaces and obsoletes the OAuth 1.0
protocol described in RFC 5849.
And RFC 5849 is The OAuth 1.0 Protocol
The direct answer to your question is yes. From the OAuth 2.0 spec:
it is the intention of this specification that new implementations support OAuth 2.0 as specified in this document and that OAuth 1.0 is used only to support existing deployments.
Although I prefer OAuth 2.0, and have implemented a 2.0 authorization server and contributed to the spec, I'm not able to say that one is better than the other. I do believe that 2.0 is easier to work with.
As a useful protocol, OAuth 1.0 is not obsolete or irrelevant. As of version 1.0a (RFC 5849 is 1.0a), I know of no vulnerabilities that make it less secure than 2.0, and in fact it is arguably more secure by default. 1.0 is just as capable of handling most use cases.
OAuth 2.0 is incompatible with OAuth 1.0; it is a completely new protocol. The design decisions that drove development of 2.0 were not rooted in flaws of 1.0, per se, but rather 2.0 was borne out of a desire to make OAuth simpler to implement, and more elegant for use cases that were hard for 1.0 (such as native apps).
Some differences which may be worth noting:
2.0 relies on the security provided by TLS encrypted connections. 1.0 does not require TLS, and as a result the protocol is more complicated because it has to include its own defenses against man-in-the-middle attacks. For example, 1.0 relies on signed requests to access protected resources, whereas 2.0 offers a much simpler Bearer access token type.
2.0 splits the OAuth server into two conceptual roles: (1) authorization server and (2) resource server. This separation of concerns fits naturally with enterprises where authorization concerns are spread across many servers responsible for different types of resources.
2.0 distinguishes between confidential and public clients. Public clients are those that run on user devices, and therefore they cannot reliably keep secrets (hard-coded, embedded credentials). Distinguishing between confidential and public clients makes it easier to make secure implementation decisions that suit the needs of client application developers.
2.0 introduces multiple authorization grant types. Each grant type has its own protocol flow, and these protocol flows make OAuth 2.0 adaptable for multiple use cases and client types.
2.0 makes a great effort to be extensible. Section 8 of the spec makes provisions for defining new access token types, grant types, and protocol parameters. For example, in addition to bearer tokens, work is going into MAC tokens and JWT bearer tokens.
This is subjective, but one might say that OAuth 2.0 tries to be flexible for many use cases, where OAuth 1.0 required developers to fit their use cases into a more rigid framework.
I don't really think that you can say that OAuth 1.0 has been deprecated in favour of OAuth 2.0. You can still work with the 1.0 if it suits on your demands.
The 2.0 is better for large scale like Twitter did the deprecation and changed it's API from 1 to 1.1, so to make use of the new OAuth, but that has to do with twitter.
In another case maybe 1.0. is still working perfect, so no need to upgrade.
OAuth 2.0. has to do more like with public encryption, public key. And not private, not great news as that method is known years now.
So that's way there are still be different opinions about if is good or bad.
Here Oauth2.0 and the road to hell, and here OAuth 2.0'bad' i think you can find more interesting and detailed information of what you want.
Lately I have been reading lots regarding the OAuth (Open Authorization) protocol. I have come to understand following points:
OAuth 1.0A :
It uses digital Signature (mitigates the phising) and recommends the use of TLS/SSL (mitigates the man-in-middle-attack) and practically all those Service Providers using OAuth 1.0A are using TLS/SSL. Due to implementation of digital signature and TLS/SSL, OAuth 1.0A is more secure, forgiving the hard times of getting digital signature correct. Yet many had implemented OAuth 1.0A -the paradox.
OAuth 2.0:
This is relatively new, but entirely non-compatible with the earlier one (i.e OAuth 1.0 (A) ), does not use digital signature due to the hard times faced in getting it correct 100% instead it uses SSL/TLS and bearers token (i.e the holder of the token can do anything). Best thing about OAuth 2.0 is that it has differentiated the different grant flows which in OAuth 1.0 is all merged together. And non-interoperability is yet another issue with the OAuth 2.0 (i guess it will lead to more division..just my guess).
In many ways I find OAuth 1.0A is better than OAuth 2.0, from what I have learnt so far. Now can anyone shed some light on this, why OAuth 2.0 is encouraged when OAuth 1.0A is better (better in the sense that it is more secure).
Thanks.
There's a funny thing about your last statement. "Better in the sense that it is more secure"
That was exactly the OAuth problem. They made it so complex and secure that many people/apps cant just use it. OAuth 2.0 is not as secure but it was made to be easily handled.
I'm trying to secure my MVC4 Web Api. Actually, I just really need an identity provider with some light security. My service is similar to twitter, from a security standpoint, there's not a lot of private data, but the service does need to know the userid for the caller.
It's also important to know that the web service will only be consumed by mobile devices right now, although a website may accompany it at some future point.
S.O. and the internet have led me to Thinktecture.IdentityModel, but man it seems complex and I can find exactly zero documentation or samples. I also haven't yet had a pleasant experience with claims-based authentication. I don't have a claims server, token provider, or anything like that, and it seems like you would need that to use this method. This all seems far to heavy for my situation.
I've also read about people implementing their own HMAC solution (https://github.com/cuongle/WebAPI.Hmac) or using OAuth (https://github.com/maksymilian-majer/DevDefined.OAuth) but these also seem a bit complex (I've read that OAuth without the helper class is enough to make the best developers cry, and I'm not the best). Janrain looks like it might work, but it looks like you have to pay for more than 2,500 authenticated users per year ...
What is the best way to implement a simple identity provider and security for Web Api?
Thanks!
I have attempted to answer a similar question to this before Create an OAuth 2.0 service provider using DotNetOpenAuth where I highlighted the Thinkecture Identity Server. The Setup instructions not too difficult (IMHO) The installation video is here and should help a lot.
I have updated my older answer with this too but there is also a fairly lightweight O-Auth 2.0 implementation example here Sample code here http://code.google.com/p/codesmith/downloads/detail?name=OAuth2.zip&can=2&q=#makechanges
Have you also read this well articulated question here Authenticating requests from mobile (iPhone) app to ASP.Net Web API (Feedback requested on my design)
Well, security is hard :)
As for Thinktecture.IdentityModel -- this is a token processing library (among other things) that you'd use in your WebAPI application. You'd use this so you don't need to do the logic to accept tokens (basic auth, SAML, SWT, JWT). Claims are just a side-effect.
If you're looking for an identity provider, then the sister open source project Thinktecture.IdentityServer is in beta for version 2. It's an identity provider that supports a custom database and issues tokens. The project URL is:
http://thinktecture.github.com/Thinktecture.IdentityServer.v2/
In response to the problem of finding example code as documentation, consider the samples folder in the Thinktecture github repo: https://github.com/thinktecture/Thinktecture.IdentityModel.45/tree/master/Samples
(Why do you need more reputation to comment on SO than to answer?)
I've been trying to find a good solution for authenticating a user with OAuth 2.0 using the ASI HTTP library. I'm coming up a bit short. Does anyone know of a library that adds this to ASI HTTP? I found one that only works with OAuth 1.0, and another that adds methods to the request for OAuth, but none that handle logging in etc.
Thanks so much for any insight.
I see a few implementations floating around. The question has also been asked here. This set of classes seems to add support.
I actually recommend switching over to something like AFNetworking since ASIHTTPRequest is no longer updated/supported. If you do that, there is an official extension to do what you're asking here.
I am going to start writing an API for my open source project.
Should I go with OAuth 2 for authentication or OAuth 1?
My main concern with OAuth 1 is than I don't want to invest time in writing API based on it if OAuth 1 going to be outdated soon.
My question is - will OAuth 1 become outdated soon? Also, I think from the point of end-user of the API, OAuth 2 seems to be easier to implement.
Should I just write OAuth2 API and forget about OAuth 1 or are there good reasons to use OAuth 1 for now?
Use OAuth 2.0. It is stable and ready for implementation. There is no reason anyone should be deploying OAuth 1.0 at this point. 2.0 is simpler, more secure, and more robust.
As for 1.0, the protocol is published and anyone can use it as long as they want. It is an information RFC and will remain that way. However, once 2.0 is published, 1.0 will be marked as obsolete. None of this IETF bureaucracy should make any difference to you.
OAuth 2 is in draft stage (current writing, draft 16), but OAuth 1 has already is already in RFC (RFC 5849).
OAuth 2 authorization flow is easier than OAuth 1 but what you might encounter is that you have to choose a draft you want to implement and stick with it. When an RFC for OAuth 2 will be released, you will have to conform to it.
Addon: If OAuth 1 will be obsolete, the RFC will be obsoleted. The IETF will put the RFC into Status "historic". Chances are, they might make OAuth 2 an RFC and historicalize OAuth 1 RFC. Until that happens, OAuth 1 is valid to this day.
I hope this little info can help you.
You should think about your users (developers) and choose an appropriate API based on that. Are they likely to have experience or a preference? If not I'd tend to go for OAuth2. You might also want to make the decision based on the type of organization you are dealing with. I've dealt with people who have a preference for older protocols because they feel they are more mature and secure. This is not always rational but sometimes it is worth considering.
There is some information on design decisions (why a new version?) driving Oauth2 available.
I am worried about the future of OAuth, seriously. Since Eran Hammer, one of the founder of the OAuth left the group and later David Recordon followed him.
They are concerned about the security and vulnerability of OAuth 2.0. This is how Hammer described OAuth2.0
more complex, less interoperable, less useful, more incomplete, and
most importantly, less secure.
May be its time to look at SAML for the OAuth users.