Some More Thoughts On OAuth 2 Sample

Recently, Pedro Félix sent me some questions on an internal mailing list regarding the recent sample I pushed out for integrating OAuth 2 into Web API (if you haven’t checked out Pedro’s blog, you should go and do that).  I thought they were really good questions/comments, so I wanted to share them here, along with my responses, and invite you into the conversation.  Some of the “Qs” are comments, but in the name of keeping the format simple, I’ve just broadly adopted the Q/A format.

Q

Regarding the “A Brief Disclaimer” section, OAuth’s primary goal is delegated *authorization* on resource access. IMHO, your scenario fits well into this goal. The key observation is that the *resource* under access control is the *user’s identity*. Instead of the user *pushing* its identity to the service (e.g. Basic authentication or a federation protocol such as SAML), the service *pulls* this identity (just a resource from the OAuth view point) from a trusted-third party (Facebook).

A

I agree that it fits – However, I don’t yet believe that treating an OAuth resource server role as an identity provider “fits well” for 2 main reasons:

  • It seems wasteful to establish an OAuth session (using “session” since an access token as valid – and as such must be stored on the authZ or resource server) so that it can be used just long enough to get a piece of identity information.  For that scenario, the push model of federated identity tokens seems like a better fit.
  • Because OAuth is really an authorization protocol, and because the major players like Facebook act as both the authZ server and the resource server role, every application that wants to have Facebook authenticate its users (each “relying party”) needs to register a pho Facebook application with its own app key and secret – or use a broker like ACS that does this for you and sends you an identity token.  Again, doable, but feels to me like a misuse of OAuth.

Q

I’m unable to fit this scenario into any of the typical OAuth use cases/profiles. Typically, the OAuth client

  1. is a webapp interacting with the user via a browser
  2. is an active client running on the user’s machine

In this scenario, the OAuth client is a web service, being accessed by a service client on the user’s machine:

A

The scenario is a modification of a standard OAuth server flow.  Web API is the OAuth client, Facebook is the AuthZ and resource server.  Web API fits into the definition of a confidential client here and as such, I’m using an auth code grant type.  Where this breaks off from the more typical OAuth flow (which would generally be a Web application) is in the fact that the UX is a single page, AJAX-driven app, so there’s an additional protocol (term used loosely) happening between the jQuery code and the Web API.

Q

IMHO, it would be better to start with simpler scenarios

  1. web api as a resource server, using an external authz server (e.g. AppFabric’s ACS)
  2. web api as an authz server, using various grant_type (password, client_credentials, saml,…)

A

I called those out at the bottom of the post and these are the scenarios that I’m working through now – For people unfamiliar with the world of federated identity, though, I would argue that they are not inherently simpler scenarios.

Q

On OAuthFacebookOpHandler, I don’t think that attaching the principal to the current thread is a good idea on this brave new world of asynchrony – the underlying thread may change several times. A better solution would

  1. Attach the principal to the current request message (the threads may change on a request, but the request message doesn’t)
  2. Return the principal as an http parameter, so that it can be used as an input parameter on downstream handlers and on operations

A

both good ideas – will update

About Howard Dierking

I like technology...a lot...
This entry was posted in OAuth, Web API. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Buster

    Hi Howard,

    Do you have any plans to update your SecureServices demo to work with the new ASP.NET web api at all?  I’m having difficulty migrating it myself and would love some pointers now that the HttpOperationHandler is no longer available!

  • Anonymous

    Hi Travis – I kept wondering why your name sounded familiar and I just realized that it was because your OAuth on mobile apps post was open in my browser (just read it – really cool idea, btw – I’ve been in some very similar conversations recently with sibling teams).

    On using OAuth for authentication – I don’t think it’s unreasonable, I just think it’s a stretch.  I’m more excited about OpenID Connect, as it seems to better use the right tool for the right job.  Wrt the AS/IdP relationship, I realize that they don’t have to be related – but until recently, I hadn’t really seen many practical examples of them separated.  I’ve found a few resources more recently demonstrating this (for example, there’s some stuff written about exchanging a SAML token for an AT), but I would certainly appreciate any other resources you could point me to.

    On the workflow, that’s a cool idea to use the client credentials grant type with one AT to get another AT – I’m sure this would scale better as well – will add this into my sample.

    On Q3, the Q/A on RS vs. AS was more related to whether we could provide support for hosting an AS that could manage scopes/permissions for a known RS (Web API) – not so much whether the service itself was an AS.

    Thanks for commenting!  To be continued, I hope…

  • email@travisspencer.com

    Q1. Using OAuth for authentication is a reasonable thing to do, even more so in the future when OpenID Connect, which is an authentication protocol built atop OAuth 2, becomes commonplace. In this scenario, the user will be redirected from the RP to the Authorization Server (AS) component of the OpenID Provider (OP). The Access Token (AT) issued to the RP (an OAuth client) will call a user info endpoint on the OP to pull down user attributes. The model of OpenID 1 and 2 is a push model though and user attributes are sent on the front channel using extensions to the protocol. Also, there is nothing in OAuth that says that the AS must be the IdP. It could federate back to an IdP using SAML, for example.

    Q2. Sounds like this post: http://stackoverflow.com/questions/7813135/any-references-regarding-an-oauth-2-0-scenario-where-the-client-is-a-web-servi/7895185#7895185. See my reply there.

    Q3. Services are usually OAuth Resource Servers (RSs). Like with other protocols, a service can also double as a client (think of WS-Trust). I can’t imagine any scenarios where a service would be an AS.

    Thanks for opening up the conversation. Just my $0.02 :-)