OAuth for calls with user context

[pulapura]

Hi

We have a service which exposes certain functionality using a REST API. The REST API needs a user context to execute its functions. There would be two ways for the API to get the user context

1. Using a user access token
2. Passing in the user context directly in the request(like userId, no token involved)

Case 1 seems to be relevant when we do 3 legged OAuth where a user access token would be generated.

Case 2 seems to be relevant when we do an internal service to service call, where the user may have been authenticated to the client service using some mechanism other than OAuth, say single signed on using CAS. (So there is no token available for the client service to use when it makes a call)

Given the above two cases, we would need to expose the API in two ways, one that accepts a user context in the request, and one that tries to retrieve the user context based on the access token.

This would however result in any service always having to maintain two ways of accessing the same API. Is there any way around this to avoid having the client from having to implement two mechanisms to access the same API?

Thanks
Sudip.

[Dave Syer]

That's quite an interesting scenario, and one I encounter quite a lot (where some client apps need to act on their own and some on behalf of a user, but access the same resource). To keep the API uniform it needs some way to identify the user (if not authenticate him), so I guess I would design the resources with that in mind, e.g. /users/{userid}/stuff, so that the userid is always available uniformly. If you can't do that I suppose you could use a security filter to setup the security context in a uniform way, so that the userid is always available as a Principal (but that pushes quite a lot of complexity onto the filter, and it isn't really an off the shelf Spring Securty use case).

By the way: using CAS for single sign in no way precludes your client apps from getting a user token (CAS is for authentication and OAuth is not), so if that was your main counter example, you might want to think again. If a user token is always available then it will always be able to encode the userid.

[pulapura]

Thanks Dave.

To keep the API uniform it needs some way to identify the user (if not authenticate him), so I guess I would design the resources with that in mind, e.g. /users/{userid}/stuff, so that the userid is always available uniformly.

I am assuming in the 3 legged OAuth scenario, the userid would not be available to the 3rd party since he would only have the user token available. Am I right in making that assumption? In that case, I am not able to see how this solution would be possible. Do you see the userId somehow being made available to the third party?

If you can't do that I suppose you could use a security filter to setup the security context in a uniform way, so that the userid is always available as a Principal (but that pushes quite a lot of complexity onto the filter, and it isn't really an off the shelf Spring Securty use case).

Can you clarify what the API would look like in that case? Would it just be /users/stuff and then either pass or dont pass the userid in say the body of the request as a parameter depending on whether a token is involved or not. Wouldn't that be counter to REST?

By the way: using CAS for single sign in no way precludes your client apps from getting a user token (CAS is for authentication and OAuth is not), so if that was your main counter example, you might want to think again. If a user token is always available then it will always be able to encode the userid.

I have difficulty in understanding how a single sign on system can work alongside an OAuth system if we consider them to be two separate components. Do they somehow have some service in common? For example, if I have a CAS server, that would be different from my OAuth Authorization Server. In CAS, it would essentially store a cookie in the user's browser. However, at no stage during this interaction has an OAuth token been generated. Now when a client tells me that I have already authenticated my user and hence I should have a token for accessing other APIs, I don't see how that would be possible. Also, once single signed on, I dont have the user credentials to make a call again to get a new token(possibly using the resource owner password credentials). I dont see how a user token will be available in that case. Are you saying somehow during the single sign on authentication I also get an oauth token and encode that in the cookie? If not, as mentioned before, wouldn't we need two APIs(sorry to circle back;-))

Thanks
Sudip.

[Dave Syer]

I am assuming in the 3 legged OAuth scenario, the userid would not be available to the 3rd party since he would only have the user token available. Am I right in making that assumption? In that case, I am not able to see how this solution would be possible. Do you see the userId somehow being made available to the third party?

Most OAuth providers make user details available to client apps (e.g. as a /userinfo endpoint). It's your choice whether to do that or not, but you are right that it is not a bog-standard feature (the OAuth spec does not extend that far, but OpenID Connect does).

Can you clarify what the API would look like in that case? Would it just be /users/stuff and then either pass or dont pass the userid in say the body of the request as a parameter depending on whether a token is involved or not. Wouldn't that be counter to REST?

If it was a GET I suppose you'd have to use request parameters. But yes, that's what I was getting at. It wouldn't be my choice either.

I have difficulty in understanding how a single sign on system can work alongside an OAuth system if we consider them to be two separate components.

Authentication and OAuth tokens are orthogonal concerns. The OAuth spec only says that the Authorization Server must authenticate the user when a token is granted, not how it is to be done. You could use an existing SSO server (like a CAS instance) to authenticate requests to your /authorize endpoint, or anything you wanted really.

[pulapura]

I wish there were specs without open questions, but I guess thats because we intend them to be open to allow for different solutions. I appreciate your responses.

Thanks
Sudip.