9

I have a scenario where a user has logged into to a web application (authenticated with OpenID Connect) and then needs to access data from a separate REST service.

The REST service needs to determine whether or not the user has permission to access the requested data, but if the user does have permission, then it should grant authorization to the web application without requiring the user to interact with the UI.

Essentially, what I need is a two-legged OAuth solution where the client/relying party is fully trusted but the user, who's already been authenticated, is not.

Going in, I assumed that OAuth could accommodate these requirements, but none of the grant types seem to match the requirements:

  • Authorization Code is the opposite of what I need, as the user is pretty much automatically trusted but the client is not, requiring that the user grant access to the client via a web form.
  • Client Credentials trusts the client (which is what I need) but does not give the service an opportunity to determine if the user has permission to the resource (user auth tokens are not passed to the service, making all requests essentially "anonymous").
  • ROPC (Resource Owner Password Credentials) would appear to be the only option, but requires the web application to know and possibly store the users' login credentials (which is untenable).

Is this a gap in OAuth? Or am I misunderstanding these grant types? If OAuth can't support this scenario, is there another widely adopted open standard that I've missed?

Of note: I only own/control the web application, while the customers (all of which are businesses) own/control both the authentication servers and the REST services. Therefore, a shared, non-proprietary standard is necessary so that our customers will know how to configure their services (IBM, Microsoft, whatever) and so that I'll know how to pass along any authentication tokens, etc.

JDB
  • 25,172
  • 5
  • 72
  • 123
  • Could you sketch up the interaction diagrams of the parties involved ?. I *think* i get what you are trying to do but cannot be completely sure. – Yoad Snapir Aug 01 '15 at 18:10
  • > "The REST service needs to determine whether or not the user has permission to access the requested data, but if the user does have permission, then it should grant authorization to the web application without requiring the user to interact with the UI." IF this is the case, then why not always access the API with client credentials? Why do you first want to check if the user has access? – MvdD Aug 02 '15 at 08:52

2 Answers2

0

I think this is possible using normal OAuth2 flows. You have your web application use the code authorization grant to get a token to call the API on behalf of the user.

Your web application makes the call to the API attaching the JWT token in the Authorization header. If the REST service determines the user does not have permission to access the resource, it returns a 401 Unauthorized HTTP response code.

Your web application handles the 401 response by going back to the authorization server and using the client credentials grant to get an access token to call the REST API on behalf of the client itself.

As both grants allow you to get a refresh token, you should be able to switch between access tokens easily.

Community
  • 1
  • 1
MvdD
  • 22,082
  • 8
  • 65
  • 93
  • If I understand correctly, with authorization code, the client doesn't send any kind of client ID/secret to the authorization server. I want to pre-authorize the client, so that the user does not need to explicitly grant permission for the client to access the service on their behalf. Is that possible? (Need to use existing standards - custom extensions to the standard will cause a lot of problems for various reasons.) – JDB Aug 03 '15 at 13:51
  • With authorization code, the client does send its own credentials also. But the token is to call your service on behalf of the user. You can always use the client credentials grant to get a token for the client beforehand. Would that work? – MvdD Aug 03 '15 at 14:26
0

If there is no trust relationship between the web application and the REST service, there's no way around using the Authorization Code grant since the user needs to be involved anyhow to allow the web application to make the call on behalf of the user.

If there is a trust relationship between web application and REST service you should be able to use the regular OpenID Connect flow to get an access token to the web application at login time that can also be used in calls towards the REST service.

You may pass on the user information as part of a JWT (i.e. a structured) access token that is signed by the web application itself or the OP; that would be OAuth 2.0 compliant. See https://www.rfc-editor.org/rfc/rfc6749#section-1.4 and May an OAuth 2.0 access token be a JWT?.

Community
  • 1
  • 1
Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • How does one establish a trust relationship between a web application and a REST service? Is there a standard way to forward a user's authentication tokens to a REST service so that their permission to access the resource can be verified? – JDB Aug 03 '15 at 18:10
  • you may pass on the user information as part of a JWT (i.e. a structured) access token that is signed by the web application itself or the OP; that would be OAuth 2.0 compliant – Hans Z. Aug 03 '15 at 18:14
  • Can you update your post with that recommendation and point to some authoritative references? – JDB Aug 03 '15 at 20:15
  • I don't have enough time to validate the approach you've recommended before the bounty expires, so I'm awarding it based on my perception of the potential of this solution. If it actually works, I'll come back and accept the answer. – JDB Aug 04 '15 at 16:27