Should scopes be client not user-centric?

[livingos]

I have a couple of projects running with the previous oAuth package lucadegasperi/oauth2-server-laravel. So have been looking at moving to Laravel 5.3 and passport to clean up dependencies. But at the moment there are things that the older package would do (or allowed) that Passport does not.

I am using the client_credentials grant type, which I know has now been added to Passport through additional middelware.

But scopes do not work with the client-credential grant type. Scopes seem to be entirely user-centric in Passport. In the older package scopes can be or are entirely client-centric.

[livingos]

I have submitted PR with an updated CheckClientCredentials middleware that now includes a scopes check.

Though I think this does mean that there might be some inconsistency in the way Passport handles scopes. As explained above, passport has assumed scopes to be user-centric and not client-centric.

So when passport uses the TokenGuard to authenticate it actually ignores scopes until you also use the additional and separate scopes middleware. But really, the scopes belong to the token/client. The underlying resource server actually returns the scopes that a token can claim when validateAuthenticatedRequest is called. But these are ignored by TokenGuard to integrate with Laravel's Auth.

But to my mind if a token was generated for a specific scope, then it should only be valid in those scopes. This should be independent of the Grant Type being used.

It is possible that to be consistent TokenGuard should also take into account scopes rather than rely on presence of other middleware.

[themsaid]

Scopes are now supported.