There are to things that I want to understand
Does Microsoft OWIN Security oAuth is completely built in on the oAuth 2.0 RFC.
I need a complete sample code that have client to Single Sing on ADFS using OWIN oAuth. What will the architecture for this Single Sing on
Many Thanks
IK
1) OWIN is based on RFCs 6749 and 6750 (oAuth 2.0 and Bearer Tokens), and whilst I can't say for certain that it's 100% compliant in every respect, that does certainly appear to be the goal, there's an interesting discussion on similar matters on the Katana forum here.
2) Have a look at this, it's the Azure AD Git sample for WSFederation, recently mentioned in Vittorio Bertocci's Cloud Identity blog here.
Related
Disclaimer - I am an extreme n00b when it comes to SAML, ACS and OAuth .. and just auth in general. I'm used to Windows Auth and at a push ADFS. I'm afraid you might need to give me the slow "one word a page" version here
As you are I'm sure aware Google has now deprecated the use of the OpenId 2.0 API for authentication (as of May 19th 2014). This has of course completely broken the "Google" Identity Provider (IP) in Azure Access Control Services (ACS). I basically need to add Google Support back in for a new project and understand it might be a bit more complicated than "click a few buttons".
I have seen a few blogs mention that I might need to "create an STS for the Google Auth, which I then add to ACS as the IP" but they didn't go into any more detail and I honestly don't have any idea how to do this or what it involves. I am happy to write code (I've been writing C# for almost 10 years) but have never done anything like this before.
Can anyone point me at samples / tutorials that will hopefully not go completely over my head?
The latest samples for Google+ are the ones on the Google+ Github page. Check out the .NET sample, this shows the code flows for OAuth 2.0 using Google's client libraries. There's a blog post on the key OAuth 2.0 flows in .NET as well.
If you are using MVC, there is a blog post on integrating OAuth 2.0 with Microsoft's MVC framework.
Although the samples are not targeted to Azure, I have deployed them to Azure instances without issue. If getting integrated into Azure is shown to be problematic and you think it would be worth it for Google to provide support, please request a feature in the issue tracker.
If you create a plugin, extension, etc that would be useful to other developers, please share with the Google+ developer community.
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 building a web app which will have an api and an authorization service using DotNetOpenAuth. I found this example on how you can authorize using a service provider that already exists but I would like an example on how to implement a service provider that can create tokens, persist them and do evaluation. Is there any great articles or sample providers that I can download?
Update
DotNetOpenAuth has moved on since this was initially posted. I strongly suggest you follow Ashish's advise and take a look at the samples. It contains code to write Authorization Servers, Resource Servers and Clients for all the major flows.
If you wanted a pre built solution, with opensource code
Thinktecture Identity Server is an Open Source .NET security token service. It supports a number of endpoints for authentication including OAuth 2.0 Bearer tokens.
Update this Thinktecture Identity Server is now on version 2 and supports these OAuth 2.0 flows
Resource Owner Password Credential Flow
Implict Flow & JavaScript
Authorization Code Flow
again take a look at the code to see how it was all done and there are samples here to show how to plumb it in.
I hope this helps - these library's and examples have hugely helped us over the past few months.
Update
There is also another example warning, it looks dated of a simple OAuth provider for MVC here Sample code here
There are complete working example for DotNetOpenAuth can be found here - https://github.com/DotNetOpenAuth/DotNetOpenAuth/tree/master/samples
I tried a number of times with DNOA....had to give up, but documented my findings (used Thinktecture in the end)...http://tb-it.blogspot.co.nz/2015/06/oauth-20-frameworks-and-platforms.html
I've seen this Two legged OAuth using DotNetOpenAuth but it doesn't provide any details on how to remove one of the legs.
I am finding the code quite hard get my head around (using DotNetOpenAuth 4.0). Can anyone give me any pointers on how to modify the samples to do a two-legged auth?
From the service provider, it is a simple matter of authorizing the request token immediately before before returning what normally is an unauthorized request token. Since the service provider already has to provide code to generate and store request tokens, this should be straightforward.
From the consumer, it's simply that you skip the redirect step. There's a sample of this in the OAuthConsumer samples' GoogleApps2Legged.aspx code-behind.
Take a look at this post, it explains how to implement a 2 Legged OAuth using DotNetOpenAuth 4 with a Google Apps consumer key + secret.
Google Calendar V3 2 Legged authentication fails
Hope it will helps you :)