OAuth2 Alternatives to Bearer token over SSL? Signed tokens?

[smitty22s]

Hi all,

In OAuth2 it seems that bearer tokens distributed over SSL are the standard. In my understanding, the server generates the bearer token for a client, persists it, and then sends it to the client over SSL. Then clients attach the token to a request and the server validates that the specified token is authorized for the requested resource, but there is no validation that the request is coming from the client that originally requested (and "owns") the token, is that right?

Does anyone know of any existing projects (sample or real) that utilize some form of signature verification mechanism with OAuth2? The idea would be that the server can verify the authenticity of the token without having to persist/remember the token after generation. Perhaps something using SAML 2.0?

In my project, we are being asked to create a token that is not persisted yet can be validated in the future by the server. Is this a valid use case for OAuth2?

Any insight you can provide is appreciated. Thanks!

[krishy]

Does anyone know of any existing projects (sample or real) that utilize some form of signature verification mechanism with OAuth2? The idea would be that the server can verify the authenticity of the token without having to persist/remember the token after generation. Perhaps something using SAML 2.0?

In my project, we are being asked to create a token that is not persisted yet can be validated in the future by the server. Is this a valid use case for OAuth2?

I *think* this is alluded to by the OAuth2 specification in the sections on extensions and access token types, though I am not familiar with any projects that actually provide support for this.

[Dave Syer]

@krishy: correct, I think. The extension specs are less mature than the main one, and even that isn't final yet, so it would be surprising to see a lot of activity in implementing them. There are JIRA tickets open against Spring Security OAuth for SAML grants and MAC tokens, which I think would meet the needs of the original poster. Contributions gratefully accepted.

@smitty22s: You are also correct about the majority of OAuth2 use cases and implementations. But bearer tokens don't absolutely require persistence, and it's not the case that there can be absolutely no verification of the client. Tokens can carry their own state - the spec doesn't say what the content of a token is. And it's not part of the spec, but you could enforce client authentication with every request, for instance. HTTPS would still be needed, but it would stay fairly lightweight.

[smitty22s]

@krishy, thanks for the links to the relevant paragraphs in the spec.

@Dave Syer, thanks for the info. Can you provide more detail about what a bearer token might look like that wouldn't need to be persisted? Perhaps if the token included the user ID and access role that it's valid for, and was signed by the server?

If we "forced the client to authenticate with every request", do you mean include user ID and pw in every request? It seems if we did that we'd be negating the benefits of using OAuth.

[Dave Syer]

Perhaps if the token included the user ID and access role that it's valid for, and was signed by the server?

Yes, for instance.

If we "forced the client to authenticate with every request", do you mean include user ID and pw in every request? It seems if we did that we'd be negating the benefits of using OAuth.

Not really. the benefit of OAuth is in delegating the role of the User not the Client. The Client only has one secret, but it might have many Users that each have their own token.

[smitty22s]

The Client only has one secret, but it might have many Users that each have their own token.

Ah, I was confusing the client with the user.