Subject: [OAUTH-WG] SSO scenario

From: Justin Karneges <[email-masked]>
Date: Fri, 26 Aug 2011 16:04:57 -0700

Hi folks,

I currently use a proprietary token approach to provide authentication to a 
browser widget, and I wonder if OAuth could be used to replace it.

Here's how the system currently works:
  - website supports authenticated users (happens via username/password form)
  - website and widget provider have a shared secret
  - the website serves a page to the browser, containing an embed of a remote 
widget as well as a token that asserts the currently logged in user.  the 
widget takes this token and performs an ajax call to the widget provider 
server.  behold, the user is now logged in to the widget.

In trying to organize this into OAuth terms and roles, here is what I come up 
with:
  - resource owner: the user
  - resource server: widget provider (where the resource is generically "the 
ability to utilize the widget")
  - client: the webpage running in the browser
  - authorization server: the website

The website essentially serves up the client application and token in one 
shot, so the client never has to explicitly ask for a token.  However, the 
client would then take that token and use it to access a service.  The website 
and widget provider would share key material such that token validation is 
possible, but it's important to note that the two services are not owned and 
operated by the same people.

Does this seem right?  Normally when I think of OAuth, I think of a user 
giving a third-party service access to his personal stuff, but in the above flow 
I'm proposing that OAuth be used so that the user gains access to his own 
stuff.  In fact, there would be no way to access his stuff other than this 
approach, so it's not just about optional third-party access.  It's the direct 
and only access.

Would love confirmation that OAuth is appropriate for my needs, and if I have 
the roles right in that case.

Thanks,
Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Aug 2011 13:14:39 -0600

I tried to help Justin off-list, but it would be nice to have a FAQ
somewhere that shows developers how to translate from OAuth 1.1 to OAuth
2.0, even just conceptually (as in, "they got rid of the legs, how do I
do two-legged auth in OAuth 2.0?!?").

On 8/26/11 5:04 PM, Justin Karneges wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Wed, 31 Aug 2011 15:42:05 -0400

This description actually sounds a lot like the user-agent flow (aka,
"implicit authorization grant") in OAuth2 more than it does a true
two-legged system. The user is still there, and there's still a client
and protected resource, it's just that they're fairly tightly tied.

When using the implicit flow, one of the things you rely on for
verification of the client is the callback url. In this case, it can be
completely pre-registered back to something that the AS/PR has direct
control over.

If you wanted to do a more traditional two-legged approach, you can use
the client-credentials flow between the two servers and have the user's
identity just be asserted as part of an explicit API call. But since you
have a user in the loop, you might as well use them and do a real
three-legged kind of thing.

Additionally, the "user is logged in" bits could be handled by using
OpenID Connect if he wants to go in that direction. At a very high
level, the user ID basically becomes an OAuth2 protected resource, thus
allowing you to log in from any where you can get an access token.
(Connect folks, please feel free to chime in and tell Justin how wrong I
am.)

 -- Justin

---

From: Justin Karneges <[email-masked]>
Date: Wed, 31 Aug 2011 13:58:07 -0700

Thanks Justin.  I tend to agree that this is probably not a 2-legged issue, 
and that there is likely a better fitting arrangement in the OAuth 2.0 system.

I've thought about this some more, and, especially given that the website and 
widget provider are separately-owned entities, maybe the roles ought to be:

 - resource owner: the website (not the user)
 - resource server: widget provider (where the resource is generically "the 
ability to utilize the widget")
 - client: the webpage running in the browser
 - authorization server: widget provider (not the website)

This way, we are sharing an auth grant between two separately-owned entities 
rather than an access token.  As I understand it, an access token is really 
meant for exchange between two tightly related entities since as far as I can 
tell access token formats are proprietary.  Auth grants, on the other hand, 
are being standardized (SAML?), and so they seem more appropriate for exchange 
between organizations.

So, by the fact that the website trusts the client (the user has signed into 
the website using a traditional web form, and the client possesses a cookie), 
the website gives an authorization grant to the client in order to access 
widget services.  The grant would indicate rights scoped appropriately based 
on the particular user.

How's that? :)

On Wednesday, August 31, 2011 12:42:05 PM Justin Richer wrote:
> > > I currently use a proprietary token approach to provide authentication
> > > to a browser widget, and I wonder if OAuth could be used to replace
> > > it.
> > > 
> > >   - website supports authenticated users (happens via username/password
> > >   form) - website and widget provider have a shared secret
> > > widget as well as a token that asserts the currently logged in user. 
> > > the widget takes this token and performs an ajax call to the widget
> > > provider server.  behold, the user is now logged in to the widget.
> > > 
> > > The website essentially serves up the client application and token in
> > > one shot, so the client never has to explicitly ask for a token. 
> > > However, the client would then take that token and use it to access a
> > > service.  The website and widget provider would share key material
> > > such that token validation is possible, but it's important to note
> > > that the two services are not owned and operated by the same people.
> > > 
> > > Does this seem right?  Normally when I think of OAuth, I think of a
> > > user giving a third-party service access to his personal stuff, but in
> > > the above flow I'm proposing that OAuth be used so that the user gains
> > > access to his own stuff.  In fact, there would be no way to access his
> > > stuff other than this approach, so it's not just about optional
> > > third-party access.  It's the direct and only access.
> > > 
> > > Would love confirmation that OAuth is appropriate for my needs, and if
> > > I have the roles right in that case.
> > > 
> > > Thanks,
> > > Justin

---

From: George Fletcher <[email-masked]>
Date: Wed, 31 Aug 2011 17:05:58 -0400

You could also use a signed JWT returned by the resource owner (web 
site) to be presented to the resource server (widget provider) that the 
resource server can validate (e.g. verify the signature). The JWT can 
contain scopes, expiry time, etc as needed. If the widget provider needs 
to access services at the resource owner, the JWT can contain an 
appropriate access_token for the user.

Thanks,
George

---

From: Justin Karneges <[email-masked]>
Date: Wed, 31 Aug 2011 14:15:01 -0700

> appropriate access_token for the user.

Interesting, I was not aware of JSON Web Tokens until now.  Is there a 
relationship to OAuth?  Are they at odds or serve different purposes?

Justin

---

From: Brian Campbell <[email-masked]>
Date: Wed, 31 Aug 2011 16:48:20 -0600

JWT is definitely not at odds with OAuth.  I guess you could say JWT
is potentially complementary in a number of ways (they can be used
together but don't need to be).  Though I'm not aware
of any spec work around it, I suspect many will chose to use JWT as a
bearer access token format.  JWTs can also be used as an OAuth grant
type [1] which is based on similar functionality for SAML tokens [2].

[1] http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer
[2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer

---

From: John Bradley <[email-masked]>
Date: Wed, 31 Aug 2011 21:36:30 -0300

JWT is designed to be used with OAuth and openID Connect.

There is a IETF WG being created to standardize the signing and encryption for JWT and other JSON tokens.

John B.

> A new IETF working group has been proposed in the Security Area.  The 
> IESG has not made any determination as yet. The following draft charter 
> was submitted, and is provided for informational purposes only. Please 
> send your comments to the IESG mailing list ([email-masked]) by Tuesday, 
> September 6, 2011                            
> 
> Javascript Object Signing and Encryption (jose)
> =================================================
> Status: Proposed Working Group
> Last updated: 2011-08-18
> 
> Chairs
>   TBD
> 
> Security Area Directors:
>   Stephen Farrell <[email-masked]>
>   Sean Turner <[email-masked]>
> 
> Security Area Advisor:
>   Sean Turner <[email-masked]>
> 
> Mailing Lists:
>  General Discussion: [email-masked]
>  To Subscribe: <https://www.ietf.org/mailman/listinfo/jose>
>  Archive: <http://www.ietf.org/mail-archive/web/jose/>