Hot answers tagged

53

This isn't a vulnerability of/in OAuth 2.0 at all. The issue has been wildly overblown and misstated by CNET and the original finder. Here it is in a nutshell: If your web site (example.com) implements an open redirect endpoint - that is, implements a URL that will redirect the browser to any URL given in the URL parameters - AND your redirect copies URL ...


51

OpenID is a protocol for authentication while OAuth is for authorization. Authentication is about making sure that the guy you are talking to is indeed who he claims to be. Authorization is about deciding what that guy should be allowed to do. In OpenID, authentication is delegated: server A wants to authenticate user U, but U's credentials (e.g. U's name ...


29

I like the idea, but I too have many questions left open. Please do not see this as any form of bashing, because I wrote it trying to apply my authentication experience to this new scheme. I am concerned about (in no particular order) : Unauthorized use of the private key Rich client support (Outlook, Notes, etc.) Using from multiple computers Private ...


22

I guess there is no really good solution for everday websites (e. g. not high profile sites such as banks for which users accept and economic allows a two factor authentication). One can only pick a solution which as little negative impact as possible. Unfortunately people are not good at remembering a huge number of passwords. This results in either them ...


22

OpenID connect will give you an access token plus an id token. The id token is a JWT and contains information about the authenticated user. It is signed by the identity provider and can be read and verified without accessing the identity provider. In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice. for instance ...


17

Many people still visit this so here's a very simple diagram to explain it Courtesy Wikipedia


17

In my understanding, "less secure apps" refers to applications that send your credentials directly to Gmail. Lots of things can go wrong when you give your credentials to third party to give to the authentication authority: the third party might keep the credentials in storage without telling you, they might use your credentials for purposes outside the ...


16

From a security perspective, having a tried and tested mechanism is almost always better than rolling your own. Implementation errors are one of the most common ways a good security concept gets broken. From a usability perspective I slightly prefer oauth, it is just easy to use, so for your end users that is a huge benefit. An average non-technical user is ...


16

You are correct. App secret should be secret and should not be easily obtained by reverse engineering your client code. Facebook uses OAuth so everything I say here also applies to all the applications that use OAuth to authorize and authenticate. The app secret authenticates your client to facebook. Just like a username/password authenticates a user to a ...


13

Without a specific scenario and threat model in mind it is hard to answer your question. But one clear win is the classic OAuth use case. It turns out users are amazingly willing to give one web site their password for another web site, e.g. their Google password to a social networking site like Shelfari. And as Kalsey notes, they were sometimes horribly ...


13

State Parameter The scope parameter is not used to secure the authentication request against CSRF attacks (see below). But there is another parameter called "state", which matches your description. [Asking the user] This step cannot be skipped. I am afraid, this assumption is not correct. It is very common, that the user is only asked for permission, ...


13

Technically you can store the access token in your database, and use it for API calls until it expires. It might be more trouble than its worth, though. For one thing, as Jonathan notes in his comment above, now you have to worry about securing your database and the data in it - these tokens give access to some fairly privileged information about your ...


12

Stack exchange also has a detailed comparison of BrowserId and WebID. As argued there BrowserId is very close to WebID (a W3C Incubator Group at the W3C). Here are some points that need to be made in defence of both protocols usually as they are very different from how public key cryptography is usually done. Unauthorized script use of key. Agree that ...


12

There are two ways you can save authentication information in the browser: Cookies HTML5 Web Storage In each case, you have to trust that browsers are implemented correctly, and that Website A can't somehow access the authentication information for Website B. In that sense, both storage mechanisms are equally secure. Problems can arise in terms of how ...


11

As others have stated, this is not a new idea. Eran Hammer (one of the creators of the Oauth 1.0 spec, who resigned from the Oauth 2.0 committe) wrote a good synopsis of the vulnerability, almost 3 years ago. His description didn't get a fancy logo or any sensational media coverage. http://hueniverse.com/2011/06/21/oauth-2-0-redirection-uri-validation/


10

PCI DSS v2, Requirement 7: "Implement Strong Access Control Measures" is the pertinent section. This section details access control primarily for non-consumers that will be accessing cardholder data for business purposes, though there are a couple requirements that seem applicable to consumers as well as non-consumers: 8.1 Assign all users a unique ID ...


10

OAuth and OpenID don't send your password to the sites you use OAuth/OpenID providers to login with, so no. Not unless the attack is performed on the OAuth/OpenID provider and provider's servers are vulnerable to CVE-2014-0160 (The Heartbleed Bug). It is however possible, of course provided that sites you're logging into using OAuth/OpenID providers are ...


10

Here is a Youtube video the original finder put together leading you through the vulnerability: https://www.youtube.com/watch?v=HUE8VbbwUms. OpenId and OAuth both provide a field that allows a third-party site to specify a redirect when authentication has completed and is successful. For instance, you go to Good Reads, they want you to login with your ...


9

Well the first consideration is that SSL/TLS is absolutely necessary to implement correctly. One must also consider 2-legged or 3-legged authn mechanisms. While most are going to recommend the more complex (and safe) 3-legged approach, it is possible that 2-legged would have advantages when done right for certain apps. There have been some timing attack ...


9

I use Google for my OpenID account. Almost all websites that do not use OpenID let me reset the password via email, so if someone got the password to my gmail account, I would be screwed anyway.


9

Wrote this about federated ID. Basically you are talking about the centralized risk problem or keys to the kingdom. This also applies to password managers, but securing a small number of identity and authentication systems is a lot easier and more effective than having hundreds of weak passwords (or the same weak password a hundred times). Open-ID providers ...


9

I haven't found a way to comment on the accepted answer, so I'm submitting a response to those six points as a new answer. Sorry. 1. Unauthorized use of the private key In the case of the Javascript BrowserID implementation, the private key is stored in local storage under the login.persona.org domain. So a rogue script would have to be hosted on that ...


9

The OAuth RFC states: OAuth uses tokens to represent the authorization granted to the client by the resource owner. Typically, token credentials are issued by the server at the resource owner's request, after authenticating the resource owner's identity (usually using a username and password). There are many ways in which a ...


9

OAuth provides only and should only provides authorization using an access token. OpenID connect is built on OAuth 2 in order to provide user authentication information. However, it will not provide you a more robust implementation than OAuth (since it uses OAuth and add some extra interactions with a OpenID provider). OpenID Connect 1.0 is a simple ...


9

To answer your questions: 1) How do you handle a situation with a compromised token secret which is shared between a client and the server? Add an expiry date to your token. Make sure the token cannot be used after the expiry time. But this doesn't prevent unauthorized access within the token's expiry period. So, to overcome this problem you can embed ...


8

Well, it depends... OAuth is a protocol for creating a session. OAuth bearer tokens are transmitted by the client using the Authentication: Bearer HTTP header. This is just a cryptographic nonce that is transmitted via an http header element, which in effect is (almost) identical to the cookie http header element. How does it differ? Well, the ...


8

These are really two questions. How can I guarantee that requests from sources claiming to be this client application can be trusted? You can't. The specification says: The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client [...] The resource owner (aka. user) ...


7

Rather than logging in to accounts they control, I expect voter fraud would be done by clickjacking or CSRF, harnessing the social viral power of Facebook to attract unwitting accomplices. With the prevalence lately of images on Facebook that claim that you can obtain a PS4 simply by "liking" and "sharing" an image and the sheer numbers of people who do so, ...


7

From having conducted many an IT audit over the last ten years or so, I would say my biggest worry would be gaining assurance that this third party authentication mechanism works as it should. An auditor who puts their neck on the line and green-lights this is in a very sticky position if something happens at the facebook/twitter end of things (they are ...



Only top voted, non community-wiki answers of a minimum length are eligible