I found this interesting because, in this case, Twitter isn't using OAuth only 
for content authorization (the original intent of OAuth), but instead for 
single sign-on authentication.  OAuth was not designed for SSO, but it can be 
used as an SSO protocol.  You can think of the OAuth tokens (Request Token + 
verification code) is analogous to the CAS service ticket, and the protected 
resource is analogous to the CAS validation response.  Certainly, OAuth 
includes a bunch of extra steps compared to the CAS protocol, but the end 
result is interestingly similar.

Instead of creating a new protocol for authentication, Twitter decided to 
leverage an existing authorization protocol and re-use it for authentication.  
I found that interesting.

-Nathan

From: Scott Battaglia [mailto:[email protected]]
Sent: Monday, May 24, 2010 11:20 PM
To: [email protected]
Subject: Re: [cas-dev] Twitter using OAuth for authentication

Nathan,

We're actively looking at additional protocols to support (we had pretty much 
the same epiphany you did ;-)).  When we looked at OAuth, there didn't seem to 
be much we needed to do (or anything we could do).  If you've got some 
additional insight, I'd love to hear it.

Cheers,
Scott

p.s. I'm recovering from not reading email for 8 days.  Apologies for any wave 
of emails.


On Fri, May 14, 2010 at 11:53 AM, Nathan Kopp 
<[email protected]<mailto:[email protected]>> wrote:
I just read an article about how Twitter is making use of the OAuth protocol to 
support CAS-style delegated authentication.
Here is the article:
http://hueniverse.com/2009/04/introducing-sign-in-with-twitter-oauth-style-connect/

Here are details from Twitter's website:
http://apiwiki.twitter.com/Sign-in-with-Twitter

So now we can add OAuth to SAML and OpenID as a delegated authentication method 
that can work similarly to CAS.

As demonstrated with SAML, CAS could be extended to support these protocols 
natively as an identity provider (IdP).

On the flip side, I am considering creating authentication providers to allow 
CAS to act as a consumer for at least some of these protocols.  This would 
allow our users to access some of our CAS-protected sites using, for example, 
their Yahoo account (via OpenID).  (We also plan to support facebook connect as 
an identity consumer, though it probably wouldn't make sense to support that 
protocol as an identity provider.)

If multiple authentication mechanisms and IdP protocols are used in combination 
with "level-of-authentication" (LOA) concepts, CAS becomes a federation hub.  I 
could imagine a user accessing a SAML-enabled application and signing in with 
their Twitter account.  Interesting.

-Nathan


--

You are currently subscribed to 
[email protected]<mailto:[email protected]> as: 
[email protected]<mailto:[email protected]>







To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-dev


--

You are currently subscribed to 
[email protected]<mailto:[email protected]> as: [email protected]

To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-dev

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-dev

Reply via email to