access token theft threat countermeasure

i have been looking at the threat model put forth in this document:

http://tools.ietf.org/html/draft-iet...threatmodel-02

one identified threat is the theft of an access token from a client (the transport layer has not been compromised), and one associated countermeasure is having the resource servers add an extra check validating ownership of the token to the caller.

one way to accomplish that would be to pass client-id/client-secret along with each request.

does anyone know if there are any existing hooks to help accomplish this countermeasure at the s2-oauth client and/or provider?

thanks,
tony.

If the client has a secret s2-oauth will require it to authenticate every request (you might be able to switch this off, but it's on by default). The main problem with this threat is implicit grant tokens since the client is by definition untrusted, but that's outside the scope of the threat model. The best defense against that is to limit what an untrusted client can do by assigning it a weak authority and restricting the scopes it can use in the token.

excuse my ignorance, but can you briefly elaborate on how this per-request authentication is being carried out?

obviously client-id/client-secret aren't in the headers for each request...

Actually, I was talking nonsense, sorry (confused after a long day). The client requests to a resource server are authenticated by the OAuth2 token. The Bearer token type does *not* provide the Resource Server a way to verify the identity of the client (that's the meaning of "bearer token"). Other token types can (and probably will) provide client authentication (e.g. through encoding and/or signing), but we haven't implemented any of those yet in s2-oauth, and their specs are lagging a little behind the core.

ok, so i'm not crazy (at least not certifiable on that point ;).

let me rephrase then, if i was so inclined to implement a stop-gap in that regard where id+secret were added to the headers of each request and used at the provider for that redundant authentication, are there any existing suitable hooks that you can think of that might be leveraged to that end?

If you are using s2-oauth for the client (or Spring RestTemplate in general) you can probably work out how to add headers. Whether or not you are using RestTemplate for the client the header would have to be a custom "X-*" header because the Authorization header is taken by the token itself. Then on the Resource Server you would have to grab the header in an auth filter (perhaps extending the existing OAuth2AuthenticationProcessingFilter or perhaps adding an additional http-basic filter to the chain, like with the token endpoint in the Authorization Server). Not actually all that complicated.