Client credentials middleware should allow any sort of valid/existing client

[JuanDMeGon]

• Passport Version: 8.0.1
• Laravel Version: 6.5.2
• PHP Version: 7.3.11
• Database Driver & Version: Any driver and version

Description:

Currently, it is not possible to get access to any action protected by the ClientCredentials middleware (CheckClientCredentials) if using a password or a personal client. BUT it should be possible, as those clients still being valid clients.

Now, even when it was discussed and seems to be a lot of confusion about this. The only job for the CheckClientCredentials middleware is to validate if the client is a valid client; does not matter the type of client it is.

Based on the theory and official standards of OAuth2: "The Client Credentials grant is used when applications request an access token to access their own resources, not on behalf of a user." (REF1, REF2). So, basically you use the CheckClientCredentials to protect the route and validate if the request comes from a valid client (independently of the type of client). In fact, a token obtained using the client credentials grant does not have a user associated with it, so any user-related action is going to fail.

It was introduced in #1040 with the call to $token->client->firstParty() (source).

In conclusion: If ANY client obtains an access token using the client credentials grant it SHOULD be authorized when making a request to an endpoint protected with the CheckClientCredentials middleware and currently it is not working that way.

Steps To Reproduce:

• Create a route protected with the CheckClientCredentials middleware
• Obtain a valid access token with a password or personal client (any of those) & using the grant_type: client_credentials
• Send a request using that access token to the route created at the first step and it will fail with "unauthorized" response. BUT, again, it should be allowed as it is a valid client AND successfully obtained an access token.

Thanks in advance. I hope it helps to resolve the current issues with this.

[alvirbismonte]

Just to add up to this issue, it should be either a Personal Access Client or Password Grant Client to replicate the Unauthorized response and not simply a Client Credentials Grant.

[JuanDMeGon]

Just to add up to this issue, it should be either a Personal Access Client or Password Grant Client to replicate the Unauthorized response and not simply a Client Credentials Grant.

Thanks. I fixed that now to get it more clear.

[driesvints]

I'll need @Sephster & @alshf89 to both weigh in here. Even @matt-allan if you're willing to.

We need to get a consensus about this once and for all so that we don't go back and forth changing things all the time.

[driesvints]

@billriess @soundsgoodsofar would be cool if you both could also give your insights here given your involvement on the original issue here: #691

[billriess]

In our apis we use both password and client_credentials grants using the same oauth client. We require the consumer apps to use client credentials for non-user apis like pulling app configuration or registering new users then password grants for authenticating. All of our apps are first party though so we can trust this use case.

While I agree that the middleware should work for all grant types, this would be an unexpected flow for our use case. If this is changed it would likely need a major version bump to prevent breaking existing use cases.

[T0miii]

Has some one got a workaround going for this, while it will or not will be changed?

[driesvints]

@T0miii don't upgrade to 8.0 for now

[JuanDMeGon]

In our apis we use both password and client_credentials grants using the same oauth client. We require the consumer apps to use client credentials for non-user apis like pulling app configuration or registering new users then password grants for authenticating. All of our apps are first party though so we can trust this use case.

While I agree that the middleware should work for all grant types, this would be an unexpected flow for our use case. If this is changed it would likely need a major version bump to prevent breaking existing use cases.

I am not so sure to understand your issue here. If a token is obtained using the client credentials grant, it will be allowed to pass ONLY through the routes protected by the CheckClientCredentials middleware. A token issued using client credentials grant does not pass through a route protected by auth:api. Only the tokens that have a user associated with it can pass the auth:api middleware (those are the ones using password, or authorization code, or even personal, grants).

Now, finally, I think this is not a matter of a consensus but more of following the OAuth2 directives. Here is the official RFC for the client credentials grant in the OAuth2 specification: 4.4. Client Credentials Grant.

As in the previous RFC there is no distinction of the "client type" at all, it only matters if the credentials are correct or not to get an access token. Once again, as the standard says, this grant is intended to provide access to ANY route which is not related to any user recourse (which is the current way to work of Laravel Passport).

It seems like we are accommodating Passport to the use cases of some, instead of stick to the specification itself.

[billriess]

In our apis we use both password and client_credentials grants using the same oauth client. We require the consumer apps to use client credentials for non-user apis like pulling app configuration or registering new users then password grants for authenticating. All of our apps are first party though so we can trust this use case.
While I agree that the middleware should work for all grant types, this would be an unexpected flow for our use case. If this is changed it would likely need a major version bump to prevent breaking existing use cases.

I am not so sure to understand your issue here. If a token is obtained using the client credentials grant, it will be allowed to pass ONLY through the routes protected by the CheckClientCredentials middleware. A token issued using client credentials grant does not pass through a route protected by auth:api. Only the tokens that have a user associated with it can pass the auth:api middleware (those are the ones using password, or authorization code, or even personal, grants).

Now, finally, I think this is not a matter of a consensus but more of following the OAuth2 directives. Here is the official RFC for the client credentials grant in the OAuth2 specification: 4.4. Client Credentials Grant.

As in the previous RFC there is no distinction of the "client type" at all, it only matters if the credentials are correct or not to get an access token. Once again, as the standard says, this grant is intended to provide access to ANY route which is not related to any user recourse (which is the current way to work of Laravel Passport).

It seems like we are accommodating Passport to the use cases of some, instead of stick to the specification itself.

I agree that the middleware should only care about authenticating the client, for any grant type. The issue for our implementation is the opposite of what you described. In our case, we don't want the password grant to access non-user specific APIs which this change would allow. So we're leveraging the fact that it does not work as it should according to the specification. We would just need to update the way we're handling that flow on our backend but changing this without a major version change could be a breaking change for people currently using it as is. That was my only concern.

Again, just to be clear, I agree with your original post. The middleware should only care about validating the client, not the grant type.

[JuanDMeGon]

I agree that the middleware should only care about authenticating the client, for any grant type. The issue for our implementation is the opposite of what you described. In our case, we don't want the password grant to access non-user specific APIs which this change would allow. So we're leveraging the fact that it does not work as it should according to the specification. We would just need to update the way we're handling that flow on our backend but changing this without a major version change could be a breaking change for people currently using it as is. That was my only concern.

Again, just to be clear, I agree with your original post. The middleware should only care about validating the client, not the grant type.

OK, I think I understand now. So, I think this should be resolved, of course, at app level and not in the package as currently seems to be.

Just to provide a possible solution to your case, you can add one middleware or condition checking the client type and blocking access the case it is not the client type you want (basically the same segment is currently causing the issues here).

I think we agree on the issue about the current way it is working, so if @driesvints is OK with it, I would send a PR to remove the current behavior. Additionally, I would like to know if it will require a major release again or just a fix on the current one?

[alshf89]

as long as I remember, I faced with this issue when I had some API routes that didn't belong to User scope API but CheckClientCredentials middleware didn't care about it... so when someone issued an access token via Password Credential they could access these Client Credential API Routes as well.

[JuanDMeGon]

as long as I remember, I faced with this issue when I had some API routes that didn't belong to User scope API but CheckClientCredentials middleware didn't care about it... so when someone issued an access token via Password Credential they could access these Client Credential API Routes as well.

OK, I get your point, but the implementation is not correct, so. As it is restricting the client and not the token itself.

ANY client can issue a token using client_credentials grant type, so you should not restrict based on the client type but in the grant used to obtain that specific token (following your idea).

Now, in the RFC, there is not any detail about this, so even when your point is valid (about restricting this only to access tokens obtained using the client_credentials grant) there is not a specification that says if any other access token still valid or not.

From the logic, even when a client used the password grant to obtain an access token, its credentials still being valid, so that client (using that token) can definitively pass through the client.credentials middleware as well.

The main purpose of the client.credentials middleware is to validate the credentials of the clients, which, by definition, are correct if the access token is valid.

Finally, I am not basing this in my thinking of how should it work, it is based on the current implementations and RFCs. Even when the client_credentials grant is suitable to issue tokens for machine-to-machine communication is not the only case of use. Those access tokens are valid for any case where "the client making the requests don’t require a user’s permission" (REF1, REF2).

I hope it helps to resolve the current issue.

Again, if @driesvints or anyone behind this is OK I would make a PR to remove that small segment in the condition verifying the client type, which is completely wrong (even for the use case mentioned by @alshf89).

Please let me know, I would like to resolve this as soon as possible as it is probably affecting a lot of projects.