On Tue, Apr 28, 2009 at 12:36 PM, Brian Eaton <bea...@google.com> wrote: > > On Mon, Apr 27, 2009 at 8:25 PM, pkeane <pjke...@gmail.com> wrote: >> I'm happy with OAuth for the typical sorts of social networking, >> photo-sharing, etc. use cases, and I use it for that. But I'd very >> much like to be able recommend it for more highly secure scenarios >> here on campus (I work in higher ed) that might involve confidential >> records. For OAuth to replace or be used in conjunction with the >> cuurent campus SSO and federated systems like Shibboleth, we would >> really need that extra level of verifiable security. > > Hi Peter - > > SSO systems such as SAML/OpenID/others all use the equivalent of a > callback token to bind the session at the identity provider to the > relying party. The fix to the OAuth protocol is to make it look just > like the "campus SSO and federated systems" that you mention above:
Hi Brian- It's true that a "runtime" connection is made in a SSO systems, but as far as I know, it is *always* based on an out-of-band arrangement (such as a public key exchange, or server-provider regstration) or (in the case of Shib) built directly on top of system(s) that have trusted authentication mechanisms in place which are themselves based on out-of-band arrangements. > > OpenID: signature on authentication response. > SAML POST profile: signature on authentication response. > SAML artifact profile: random single-use artifact value. OpenID is simply built on the trust of the identity provider's authentication -- to the extent that is acceptible, the OpenID is acceptable. But that is the equivalent of two-legged OAuth in that it is two "services" that have an agreement. That last link in OAuth (connecting u...@consumer to u...@sp) is NOT based on out-of-band arrangement. It appears to be, but it is not (since the consumer-SP agreement is site-wide *not* user-specific). > > All of those systems pass a value that is unpredictable to the > attacker to a trusted location at the consumer site. None of those > systems force the user to do anything as obnoxious as manually type a > pin at the consumer site. Sure they do. I cannot use my LiveJournal OpenID unless I have gone through the registration process on LiveJournal's site. Once that is completed, I can use that OpenID with services that accept it. Likewise, once a user has gone through the OAuth handshake and gotten the access token for the consumer, the consumer can store it and use it anytime it wishes (for the user -- this assumes that the consumer has a method to authenticate the user to its own satisfaction). > > If you think manually typing a pin increases security, you should > explain the attack you're trying to prevent. Why should OAuth have > such a requirement if SAML and OpenID don't? > I am not trying to thwart a specific attack -- I have no idea how one might exploit the existing hole. I'm simply trying to determine a way to "verify" that u...@consumer IS u...@sp. If that hole is closed, the protocol is as strong as the existing protocols it rests atop of. > So far the only concrete "explanation" I've seen is that ATMs require > PINs, so OAuth should require a PIN. You're confusing two-factor > authentication with federated authentication protocols. I have no stake in a PIN as the solution. My mentioning banks was to try and explain why something as simple as a 4-letter PIN can offer a great deal of security. In fact I don't care at all what the solution is. Any mechanism that verifies u...@consumer == u...@sp is a-ok. Unfortunately, three-legged OAuth is actuallly an authentication/authorization protocol masquerading as an authorization protocol, but it is not actually doing authentication at the consumer which it needs to (authentication meaning proving u...@consumer == u...@sp). I'm not sure this should all boil down to one opinion over another -- I'd prefer that we could agree on what the goal is and if it is being adequately addressed. I think we can all agree (since this is in essence what Eran's blog post suggested) that we need to prove u...@consumer == u...@sp. If everyone agrees the callback_verification is proof enough, I am OK w/ that -- that's a level of certainty that the community as a whole might be able to accept. --peter Two factor > authentication is great, and it's fine for consumers and service > providers to implement that. No change to the OAuth protocol is > necessary to support it. Again, this is exactly analogous to the > situation in OpenID and SAML. It's completely reasonable for a SAML > IdP to implement two-factor authentication for their users, and doing > so doesn't impact the SAML protocol one whit. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
