i have several questions...
Does yahoo and microsoft api support
oAuth 2.0?
If yes then what are the main
security measures those should be
taken care of while shifting from
oAuth 1.0 to oAuth 2.0.
Google API supports oAuth 2.0. But
they have still marked it as an
experimental. Is it good to start
shifting even though it is
experimental?
I see while registering an
application on google (for oAuth
2.0), they ask for callback url. If a single application uses a
condition dependent callback url
such as -
if($myVar == NULL) $callbackUrl = 'http://www.mydomain.com/test.php?m=f¶ms=null'
else $callbackUrl = 'http://www.mydomain.com/test.php?m=x¶ms=1'
How can i implement above when the callback url is already specified? The above conditional mainly handles fallback model of an application or if browser supports java then java based model of an application. Kindly suggest
May i know how many of email
providing websites and social
networks supports oAuth 2.0?
Yahoo does not support OAuth2 yet, only Oauth 1.
Microsoft does support OAuth2. http://msdn.microsoft.com/en-us/library/hh243647.aspx
Oauth 2 is simpler since it uses SSL (HTTPS) to provide transport security, so the signatures and token-secrets are not needed. When you switch you will need to re-implement your OAuth flow. I can't think of any specific security measures specifically applicable to upgrading from OAuth1 to OAuth2, but the spec details some security considerations in section 10 (The parts applicable to clients are 10.3, 10.4, 10.5, 10.6, 10.8 and 10.9).
The OAuth2 specification is still not finalized, and may change. You could begin to implement your OAuth2 flow with Google, but bear in mind that it is possible that names or requirements of parameters, endpoints etc. could change and your application will break / you will need to make changes in future. [Experimental Features] could change (or even be removed) at any time. It is probably a bad idea to use experimental (or beta) software in a critical production environment.
Also, not all Google services support OAuth2 at the moment. eg. If you want to use OAuth for IMAP access to Gmail you will have to use OAuth1 for now.
In the API Console, you can specify multiple callback URLs for your OAuth2 application, one per line. An alternative would be to store your 'm' and 'params' parameters in a browser session / cookie and do the redirect to the correct page once authorization is complete.
Support (some revision of) OAuth2: Facebook, Microsoft/Live, Google (with exceptions described above), Foursquare, GitHub, Gowalla, GeoLoqi, Salesforce.
Support OAuth1 Only: Yahoo, Flickr, Twitter.
Source.
Related
I'm writing a VBA client which needs to post to GitHub. I'd prefer to use Oauth2 for authentication to keep it in line with implementations in other languages.
When specifying the redirect_uri some oauth2 providers allow you to specify an out of band uri .. specifically
urn:ietf:wg:oauth:2.0:oob
Since the VBA app is not web based, I can't specify a real redirect_uri. Does anyone know whether the GitHub API can support some form of out of band OAUTH2 authentication like this, and if so, how to specify it in the GitHub Application console.
Our existing customer base is in peoplesoft and we are developing lot of mobile applications. Hence, we would like to use oauth 2.0 for authentication and authorization, but i cannot find any way to integrate the two.
Does PS implement OAuth? If they don't then you'll be out of luck. A quick search indicates they support SAML for SSO (on their web sites). You will probably have to describe a little bit more what you are doing, and why you think OAuth is the way to go.
Note that being mobile doesn't necessarily mean you have to implement OAuth.
This is a very late answer, but as of PeopleTools 8.58, PeopleSoft applications support OAuth2 for REST services. The caveat is that only Oracle IDCS is able to be used as an authorization server. There may be a plan in the future to support other authorization servers.
Cf. https://blogs.oracle.com/peopletools/what-peoplesoft-is-doing-with-oauth2-in-858 and https://support.oracle.com/knowledge/PeopleSoft%20Enterprise/2621182_1.html for more information.
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.
I need to develop an API to be the core of a web APP.
My initial idea was making a REST API that would treat all the request and then create some clients for web, mobile and desktop.
My question is, How should I manage the authentication for this situation?
I thought about using a token that would be passed with all requests to the REST API.
Im my case, I would not like to have something like OAuth because the ecosystem will not have multiple apps like Facebook/Twitter does.
NOTE: I must have the API separated from the client for web.
In more details, I would request POST /users/auth passing their password and username, and receive an auth token.
Is it a good approach or there is something better?
Agree that Devise is great for the auth in the application. For the API level, 3scale could help a lot (http://www.3scale.net) - it takes care of rate limits, keys, oauth secret distribution, analytics, developer portal and other stuff. There's a ruby plugin to get started here: https://github.com/3scale/3scale_ws_api_for_ruby.
Devise is a fantastic gem that handles authentication in rails apps. It also provides token based authentication. You can find many resources on the web (for example here) explainig how to use it. No doubt it will fit for your situation.
We are building a REST API using ASP.NET MVC. This API is similar in principle and usage to the Factual v3 API. They use 2-legged Oauth 1 for their API. Our design is very similar in that applications, primarily mobile will use our API behind the scenes to provide a service. The end user of the application will not know about our API, and will therefore not have any credentials. So redirecting the user via a browser window to an auth form (like facebook) does not make any sense. My questions are..
Why OAuth2 flow is the best to use in this scenario?
Should we even use Oauth2 or just stick with 2-legged OAuth 1?
For reference we are using C#/.NET, ASP.NET MVC 3 and plan on using DotNetOpenAuth v4.
http://developer.factual.com/display/docs/Factual+Developer+APIs+Version+3
Why OAuth2 flow is the best to use in this scenario?
It isn't, necessarily. OAuth 2 is an unfinalized spec. If you need maximum interoperability, OAuth 1.0 is the better choice (for now). OAuth 2 is simpler for the client, at the expense of significantly added complexity on the server.
Should we even use OAuth2 or just stick with 2-legged OAuth 1?
Use the pros and cons listed above to choose. And also that if you're using DotNetOpenAuth, OAuth 1.0 support has been around for years whereas OAuth 2.0 support isn't fully baked yet so you'd probably hit some road bumps.
Try this:
http://community.codesmithtools.com/CodeSmith_Community/b/tdupont/archive/2011/03/18/oauth-2-0-for-mvc-two-legged-implementation.aspx