Tag Archives: authorization

Is OAuth Stateless? Can it work for REST?

I spent a good chunk of the last year putting together a couple of different implementations of OAuth for internal use by our web services, and for some admin UI interfaces. The architecture guys were trying to push other development teams besides ours in that direction, too, so that we could have our services inter-operate, with a single security model.

Because I work in a large, multi-national corporation, nothing is that easy. There was lots of push back, and lots of opinions about how we should provide authorization around our web services and pages.

Or… lots of monkeys getting passionate about how to peel their bananas.

But one complaint that was kind of annoying was a standard rallying cry of the detractors that OAuth is not stateless. Ergo, it violates the principles of REST, and, ergo, is not consistent with the overall architectural direction.

So here is my take on that. I’m interested in what others think.

First, if the architecture team says, use REST, and then later they say use OAuth, it’s kind of silly to say the one rule disqualifies the other. Every technical choice is a series of considerations, and, one way or another, at the end of the day authorization and security concerns are going to trump just about anything else.

Second, how can you complain about OAuth’s state-ish-ness, and then turn around and put SSL in front of a REST service? I mean, come on.

However, ultimately, I’d like to come up with a better answer than “stop whining”, so I’ve been noodling on it some. Here’s what I think.

While the OAuth protocol is not stateless, because it requires the user to pass credenitals one time, and then maintain state of the user’s authorization on the server side, these are not considerations of the underlying HTTP protocol. It’s a higher-level concern. It’s the same as passing a “login” cookie or some other session token so the server can keep track of the user. Which is something we do all the time.

The point of statelessness is to make the servers on the REST side anonymous — so you can bring them up or tear them down at will, and leave the health of your service intact. If I have information held for clients on a particular box, and it goes down, then I have a problem, because all the client interacting with that box have lost their state.

But the kind of state that OAuth maintains is above the level of the HTTP protocol, and represents a generalization of an application concern. So really it’s not the individual *server* that cares about your OAuth token, it’s the *application* that cares.

Which means you can push your OAuth token into a distributed cache like memcached, and your individual servers are safe. OAuth, while it requires a sort of “session” state, doesn’t affect the state of any particular server, and doesn’t force you to provide server affinity.

In other words, yes, OAuth is stateful, but not the way you’re worried about. It doesn’t require the RESTful servers to be stateful.

In our implementation, we really quickly gave up on providing OAuth as a solution inside the application code itself, and almost all of our REST services externalize OAuth. For incoming traffic we use a reverse proxy in front of the service, and on the way out we use a regular proxy going to remote services. The “in” guy provides validation and bounces any unauthorized requests before they get to the REST server. The “out” guy adds the necessary headers to any outgoing request to satisfy OAuth.

That’s even nicer than terminating SSL in our load balancers, and I don’t hear anyone complaining about that.

I suppose I’ll have to continue scowling at the smug faces of developers who are convinced they’ve defeated OAuth with logic, but really I don’t see a problem with OAuth in a stateless server world.

Probably there’s a more concise way to put it, though, and I’d love to hear that.

So, to be clear, OAuth works well with REST, and doesn’t compromise any REST-ful-ness requirements for a server.

There are two ways to look at it:

+ authorization is part of the application concern, and part of a resource definition. Remember that the definition of Resource is arbitrarily large. So, “A list of ___ as allowed in this authorization scope.”


+ as a transparent concern provided by middleware, exactly as SSL (or even TCP) is. SSL doesn’t compromise the statelessness/REST-ful-ness of a service, despite it’s stateful protocol. One of the fundamental ideas of REST is to line up services in a way that allows dropping middleware in the flow to take care of concerns like routing, load balancing, encryption, authentication and authorization, without compromising the reliability of scalability of a resource server.

So OAuth, or really any token-passing authorization scheme, doesn’t compromise the validity of a REST service that it protects. You aren’t required to use Basic Auth, or proscribe SSL, everywhere to defend the REST-ful-ness of your service.

(However, statelessness is a good idea in itself … but the bigger issue for REST is that very few teams are implementing hypermedia in their service, so hardly anyone is implementing REST anyway.)



Filed under OAuth, REST

OAuth 1 vs. OAuth 2?

So the world was shocked recently when the new OAuth draft spec came out, and it was completely different from OAuth 1. It’s a much better spec overall, but still there’s a lot of work that has gone into the 1.0 implementations.

But then it occurred to me that since 1.0 and 2.0 have almost no overlap, there’s no reason why one has to obscure the other. So right now, I’m treating OAuth as an extention to 1.0 that adds a Bearer Token protocol to the original spec. We can support that.

Right now, internally, we’re only using 2-legged OAuth anyway. And the work I need to do on the Bearer Token scheme will, ironically, add the pieces that I’m missing for a complete 1.0 3-legged implementation.

So once I started thinking of it that way, it reduced the angst over spec drift greatly.

Currently my biggest grief comes from how much detection I want to do, because I could certainly walk through the protocols and, for example, upgrade from an Oauth 2 Bearer Token to an OAuth 1 3-legged request.

Now my grief is coming from the architecture guys — someone has decided that he wants an implementation that’s “more lightweight” than what I developed (even though I told them for months what I was going to do, did it, scored a couple of HUGE wins with it, etc.). So right now my plan is to open-source the core classes of my implementation, then just wait for someone to show up and cut my throat. But, hey, that’s life in the big city.

Leave a comment

Filed under OAuth

Getting started on OAuth 2.0

Sure, the OAuth 2 spec is still a draft, but so is the project we’re working on. I expect that by the time anyone is ready to talk to us, 2 will be solid enough and have enough adoption that we’ll have lots of partners to play with.

So far the questions we’re addressing are pretty basic.

  • Can we use OAuth 2 to protect web pages?

This was sort of out of the question in 1.0, but the Web Server flow is most of the way there to providing a bearer token scheme for protecting some of the admin tools we’re standing up.

  • Can we pass an access token in a cookie instead of an Authorization header?

I mean, why not? The reason cookies were invented was exactly this: to pass “magic cookies” that would let you get past the authorization troll.

  • Can we attach application-specific name value pairs to an access token?

Right now it looks like we can pass keywords in the “scope” value of a request. While that’s just a space-delimited list of keywords, nothing in the OAuth 2 spec says they can’t be name value pairs. As long as there’s no spaces in them.

In the end, we’ll probably fall this way:

Protect web pages? Yes.

Use cookies? Yes, in addition to the Authorization header and query string parameter.

Use name value pairs in “scope”? No, keywords should be enough for us.

On the last point, we may implement a second call to the Authorization Server to get more information tied to the access token than we got up front. Ya, that’s an extra hop, but right now we’re working with low-volume admin apps, so that should be OK.

Oh, and the other fun part is that we’re building an OAuth reverse proxy that sits in front of the webapp and takes care of the authorization — kind of like terminating SSL at the load balancer.

So far, pretty fun stuff.

Leave a comment

Filed under OAuth

Blowing up OAuth

We’re getting more and more into OAuth here. We’ve found that once you get over the hurdle of the weird terminology, it makes a lot of sense. Several people have commented, it’s just simplified Kerebos for the Web.

I know nothing about Kerebos, so I’ll take their word for it.

But the OAuth spec provides for a couple of things. The first part of it is a spec for bouncing back and forth between a couple of servers to authenticate a user and exhange a set of tokens and token secrets.

Then you get to the good part, which is branding an HTTP request with a signature hash. It rolls up all the good parts of the HTTP request, and is a nice hashing and validation scheme. Everyone in the room could come up with their own hashing scheme, but as you refined it, it would end up being pretty much what OAuth has.

That’s where the fun comes in. Because OAuth provides for two tokens in the hash — an access token and a consumer token — but doesn’t provide any definition around what those really are or what they look like, suddenly everyone puts on their “thinking outside the box hat”.

There are lots of good ideas of how to turn the OAuth spec on it’s side this way: set up a token cache, and just jam all kinds of existing identifiers in there to use as the access token. Or use an existing identifier as a kind of long-lived access token. Or use short-lived consumer keys. Or don’t pass an access token at all.

Lots of these are actually good ideas, but fortunately we kind of forced ourselves to not be creative,  and read the spec narrowly.

The major way we’re being creative is we are using the “2-legged” variant where the access token is empty. Also, we’re defining our consumer keys to be very, very broad entitlement grants, and perform an additional entitlement check on the request URI *after* OAuth validation has succeeded.

Also, we’re moving toward the “nAuth” spec that Twitter (I think) is moving toward, where the first N jumps in the spec are covered with a single login/access token request.

I guess I don’t have a point here. It’s just been interesting to see all the different variations and the creative spins people are putting on tokens and keys. I’ve been putting off looking at the 2.0 spec, but I’ve heard that spec addresses some of those scenarios.

Leave a comment

Filed under open standards