Kong: [request] OAuth 2.0 Set Scopes per Consumer

[matthewgo]

Defining the scopes allowed per consumer will allow more access control in the API side.

I can have my self-developed app and assign it the following scopes: read, write, update, delete.
On the other hand, I would be creating a website where third-party apps can register to view user information, thus my system assigning them a scope of 'read' only.

This can help limiting the access such that Kong can reject an authorization request made by a third-party client for an access token with a scope of 'write'.

Based on my understanding, the current setup of Kong's OAuth basically allows all apps to request for a token with any scope as long as that scope is defined in the value.scopes field of the API's OAuth 2 config.

[ammmze]

+1

I am attempting to use a spring boot application with spring security oauth2 as the authorization server and replacing the default client details service and token services objects with ones that call the kong api's for getting client details, creating tokens, etc. But right now I am unable to build up the proper ClientDetails object because the scope and grant type come from the api.

For reference, here is the BaseClientDetails class. This not only allows setting scopes per client/consumer, but also the grant types. Ideally these would come back with the GET http://kong:8001/oauth2?client_id=some-client-id.

[DonMartin76]

I was just looking for how to do this with Kong, assuming it was already possible. In my eyes this has different aspects depending on which OAuth2 flow you are using:

• Client Credentials Flow: This is where it would be most useful out of the box. A consuming application should be assigned "allowed scopes" or be regarded as "trusted" (can get access tokens for any scope; this would be the default state and like it's done today)
• Authorization Code/Implicit Grant: Actually, it's equally useful here, but you'd have to take care it's used correctly from within your Authorization Server: The allowed scopes of a consumer would limit the scopes the application (consumer) could ask from the end user. Kong wouldn't allow getting more scopes than the ones assigned to the consumer.
• Resource Owner Password Grant: Same as Authorization Code/Implicit Grant, albeit a little less complicated.

Oh, this would be awesome to have.

[DonMartin76]

@thibaultcha Would a PR be welcome which would implement such a behavior? Given that it's possible to make it completely backwards compatible? This I really need for some of our use cases here.

[Tieske]

I think it would be a nice addition. But... the Oauth2 plugin is not my area of expertise, so maybe better to ping @thefosk on this.

[DonMartin76]

I have started implementing this, I now just have to make the unit tests work the way I want... I chose to implement it the following way and would be happy for some comments by @thefosk or whoever maintains the OAuth2 Plugin:

• The oauth2_credentials gets an additional field (space separated) allowed_scopes which contains the scopes which are allowed for the specific client/consumer; if it is empty, it is assumed to be a "trusted" client which can get whichever scopes it requests (which is the default behaviour right now)
• If a client's allowed_scopes is specified, the retrieve_scopes (now also gets the client as a parameter) function will additionally filter the scopes by the allowed_scopes of the client
• If filtering took place, the retrieve_scopes also returns true for a new return variable scope_required_in_response, as this requires the scope to be returned in the token response as by the OAuth2.0 spec, section 3.3
• With the Authorization Code grant, this can't be done immediately, but must be stored temporarily with the authorization code, so the oauth2_authorization_codes also gets a new field, scope_required_in_response, which is used when generating the token response
• This is taken into account in the generate_token method, which also gets an additional parameter scope_required_in_response.

tl;dr: My addition will behave as before if you do not specify the allowed_scopes on a consumer OAuth2 credential (corresponds to a "trusted" client which can have any scopes). If you specify allowed_scopes, Kong will filter the scopes and possibly also return the altered scope with the access and refresh token response.

Makes sense?

[subnetmarco]

@DonMartin76 makes sense - the only problem would be that it's then manually required to maintain the scopes mapping when you change them. ie: later on you rename the email scope to email_address, then you have to iterate over each application to also rename the scope in the allowed_scopes property (if it exists).

Could you submit a PR?

[DonMartin76]

@thefosk Still fighting with getting the unit tests to work. I won't be able to work on this for a couple of days, will get back to you.

You're right on the scope updates. That's also one of the reasons I currently don't validate the allowed_scopes (in the sense of checking whether they actually exist as scopes on the API); the consumer oauth2 record isn't tied to an API, so this is really difficult to do without writing lots of extra code around.

[DonMartin76]

@thefosk There you go, a pull request for this thing. Thanks go to @Tieske and @thibaultcha for giving me hints on how da fuq to set up the development environment. If this is okay with you, I'd also tweak the oauth2 plugin documentation if/after we agree on where this can land.

[namco1992]

Hi, just checking any update for this issue? The PR has been there for a really long time :)