🇳🇱Netherlands @bojan_dev

Released in 6.0.2

You can take a look at https://www.drupal.org/project/simple_oauth/issues/2946882 📌 Auth revoke on profile update Needs work . There are two solutions available (not merged yet), both of which provide the ability to alter the behavior you are describing.

The matchRequest was breaking test coverage for the client credentials by returning the wrong status code. It seems to be performing some access checks. I reverted to the getUrlIfValidWithoutAccessCheck() approach but added a try-catch block around it. This should resolve the issue. Can someone please verify?

I had to create a custom RestResource plugin to be able to reproduce this.

I’ve made an MR available based on the patch in #6, with a try-catch block to mitigate the issue reported in #11.

The associated test coverage still needs to be updated; once that’s done, we can merge this.

I can't reproduce this. Am I missing something?

• Install simple_oauth:6.0.1, rest, and restui modules.
• Configure a consumer with the client_credentials grant type.
• Configure a REST content resource with format set to json and authentication set to oauth2.
• Send a request via Postman with OAuth2 authentication to /node/<id>?_format=json.
• Receive a 200 response.

This means default scopes will be merged with scopes passed to request in order to get the final request scopes?

I wouldn’t merge it; this way, authorization can be requested with fewer scopes than the default if needed.

Limiting the allowed scopes only makes sense for client credentials. For more information, see: https://www.drupal.org/project/simple_oauth/issues/3495325 🐛 No way to limit allowed scopes for a consumer using client credentialss Active

Client credentials can both limit allowed scopes and provide default scopes. Because of this, we can’t make the existing scope field generic, since a consumer may have multiple grant types enabled with different scope policies. Therefore, we need to introduce a dedicated scopes field on the consumer for the authorization code.

Regarding failing the authorization request when at least one scope is not provided, either by the request or by the default scope set on the consumer, this is a valid approach for the authorize controller.

Did you try clearing the cache? I can’t reproduce this. Also, the tests should fail if this were true, but they are not.

@claudiu.cristea valid point, release 6.0.1 is now available!

@arlanschouwstra That sounds like you are using the client_credentials grant type, which is the expected behavior in simple_oauth:6.0. This allows us to distinguish access tokens issued via the authorization code flow from those issued via the client credentials grant type.

Removing all entities and configs related to simple_oauth and then upgrading could be a potential workaround. I understand it’s not ideal, so if anyone can provide more information about how their existing consumers, scopes, and settings are configured, what errors pop up during the upgrade, and what is shown on the status report page, it would help me reproduce the issue.

It’s indeed a massive change, which is why I need a review from other developers before merging my MR.
So please, review away!

bojan_dev → created an issue.

Oke check, then just replace the assertion to the interface. Can you please provide a MR for this?

TY for the patch.

bojan_dev → made their first commit to this issue’s fork.

Is this a custom decorator? If it's the decorator of the RoleStorage, I would assume that it implements the RoleStorageInterface , it would then suffice todo the assertion base on the interface instead.

@justafish thank you for reporting and the MR.

Alright in that case, if the community can do the heavy lifting, I'm willing to review/merge D11 support for 5.2. Please make a MR available.

Unfortunately it will be more work to maintain two versions with different architectures, also the other maintainers are no longer active. I rather not introduces any new features to 5.2.x or add D11 support, which would mean support will be extended.

Perhaps you can explain your issue with Next.js, maybe I can help.

Thank you @dunjincan for reporting and providing a patch, I have updated the associated unit tests, because there were breaking due to this change.

bojan_dev → made their first commit to this issue’s fork.

Thanks all for the work on this! @bojan_dev Any preference for type of test/where? I believe just test coverage that saving AccountInterface or ConsumerInterface triggers the token deletion right, but the idea that a service can be overridden would not need testing, is that your expectation?

There is a new service introduced TokenExpiryTriggerHandler, all the methods need to have test coverage, checking if they are triggered on specific events and have the right parameters. For example: handleConsumerUpdate() is triggered on consumer update and provides the associated consumer object.

Thank you coffeemakr for reporting and and making a fork available. I have compared the logic with dynamic scopes and I can confirm that this is inconsistent behaviour with static scopes. I have updated fork to still leverage the getInstances method, due the fact it has logic when not providing ids. Could you please make a MR available next time, it was not clear for me if there was a fix available.

bojan_dev → made their first commit to this issue’s fork.

I tested how Basic Auth does this, and a non existing URL will get 404 even if the credentials are incorrect, so I think it's a valid point. Please review the MR !185, it does not apply OAuth2 anymore if the URL is not valid.

bojan_dev → made their first commit to this issue’s fork.

Could you please make a MR or patch?

Can someone please review MR !172?

The feature request makes sense, also the MR looks good to me, nice work tstoeckler!

bojan_dev → made their first commit to this issue’s fork.

I agree with coffeemkr, this is the original issue so lets keep it, also the MR in the cloned issue has more phpcs issues.

TY for contributing.

You could use the /oauth/debug endpoint to retrieve the roles from the authenticated user based on the token.

Patch from coffeemakr looks good, the MR has many file changes also the MR description is from a different issue. I think your fork is outdated.

Created issue on solarium repo: https://github.com/solariumphp/solarium/issues/1156

Looks good to me, TY!

Hi Taras,

Nice work! Looks good to me, the tests that fail are indeed unrelated.

Perhaps we should remove the simple_oauth_update_8604, like I said before it's a migration from old scopes (roles) to the new scope entity, which perhaps doesn't cover all different cases. A manual migration/configuration is the safest way to upgrade from 5.2 to 6.0.

Hi Bram,

Thanks for the clear explanation of the feature request.

I agree that this would be a valuable feature for the community, also the suggested opt-out mechanism would not introduce any BC and its implementation is pretty straightforward.

So I would say go for it and I would be happy to review any contribution on this feature.

Oke this is my take on this long discussion:
The goal of this issue is to have the ability to revoke tokens in specific cases. The only 2 options that I see that could potentially land to resolve the issue are MR138 and MR164. Both MR’s are comparable; the only difference is that 164 introduces a config layer which makes it easier for the community to configure the obvious cases mentioned in this issue (without having to write code) and optionally can of course enrich it by themselves. I don’t see the maintenance burden as mentioned, as it’s not a complex implementation.

I'm pretty much up for both MR’s, the only thing that is holding me back to merge MR138: it’s missing test coverage.

I find it not clear how to reproduce your issue, so it's hard for me to figure this one out. The hook_update: simple_oauth_update_8604 tries to migrate existing (old) scope settings from your consumers to the new dynamic scopes, so if this didn't work you could always just manually configure your dynamic scopes and consumers.

The password grant is no longer supported in simple_oauth 6.0, due the following reasons: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#s...

But you could checkout this module: https://www.drupal.org/project/simple_oauth_password_grant →

@yobottehg could you please check if the fix in MR 177 resolves the issue?

I think we should add some extra checks in that hook:

• If role is not NULL.
• If scope already exists.
• If scopes are already referenced on the associated consumer.

This way we can rerun the hook_update.

Could you please check on which line the id() is giving null?

@grasmash did you run drush updb? If the config setting invalidate_tokens is giving NULL back, it probably did not run the simple_oauth_update_10001 hook_update.

We could filter those unchecked values (on submit), to make the array cleaner when retrieving values from the invalidate_tokens.

It appears the following change in thephpleague/oauth2-server is the reason for the BC: https://github.com/thephpleague/oauth2-server/pull/1094.

finalizeScopes is now being called in the RefreshTokenGrant, which does not set the $userIdentifier, this means that no scopes are being returned. This has impact on all grant types that support refresh tokens. Sorry that I missed this, also I have read your comments @m.stenta on 🌱 Move to thephpleague/oauth2-server 9.0 Active , those are valid points I will definitely make a major version release next time.

Merging MR !176 and will roll out a new stable release.

I was assuming you were only using the grant types that are provided by simple_oauth, based on that assumption that would mean that only the Authorization code grant type supports refresh tokens. But I see you are using the Password grant, which is not supported by simple_oauth: 6.0 due to the following reason: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#s...

You could take a look in 5.2 which still supports the password grant.

@skyejohnson no, the community can review it as well, so if you have the time please take a look.

@drunken monkey thank you for you input and you have some valid points, I could just create a custom plugin extend the "search_api_solr_suggester" and make those adjustment like you said. But trimming by default spaces in the "search_api_solr_suggester" plugin feels to me like the query is specific for some Solr lookup implementations, vs just allowing spaces and having the query to the Solr suggester raw as possible.

If you still find this an edge case, we can close both issue's and I will do a project specific implementation for it.

bojan_dev → created an issue.

bojan_dev → created an issue.

Do you mean it's missing from /oauth/userinfo route/endpoint?
Did you try to update to beta10?

Take a look on the following KernelTest, which illustrates how to retrieve user info from a token: https://git.drupalcode.org/project/simple_oauth/-/blob/6.0.0-beta10/test...

Closing issue because simple_oauth 8.x-4.x is EOL.

I can't reproduce this, it's not possible to refresh the token for any grant type, it is only applicable for the "Authorization Code".
Can you please provide more info about the configured consumer, scope and authorize request?

By the way: please don't set the issue status to reviewed, a peer review should not be done on your own work.

I agree with e0ipso this hook_alter comes from anonymous_login and makes no sense for people that don't use the anonymous_login module. That hook should be documented in the anonymous_login, for people that use both simple_oauth + anonymous_login modules.

Issue is outdated, if error is still occurring feel free to reopen.

Logging has been improved in: 📌 Reduce logging severity/don't log expired tokens/401s Needs review

In 6.0 we migrate some tests to Kernel tests, but some are still needed in browser, e.g: when dealing with Authorization Code Grant there is a case where a grant form is presented in the authorization flow.

No activity for a long period, closing issue for now.

Logging has been improved in: 📌 Reduce logging severity/don't log expired tokens/401s Needs review

Closing issue due the fact 8.x-4.x is EOL.

Fixed in #3230707: 5.x broken on php 8 due to incompatibility with lcobucci/jwt v4 via league/oauth2-server ^8.2 → .

No activity for a long period on this issue, closing it for now.

Fixed in #2974963: Link refresh tokens to the user they will identidy for query filtering → .

There is for a long period no activity on this feature request, closing it for now.

Closing issue: task is pretty old and no patch was provided.

Closing issue due the fact that D7 is EOL.

@skyejohnson I made a new release for this composer fix 6.0.0-beta10, so you should be able to do a regular update (without patching), "drupal/simple_oauth": "^6.0" should be set as requirement in your project composer.json.

Please review: MR !175.

I wonder if we really need that dependency specified, because it's already a dependency in: steverhoades/oauth2-openid-connect-server, see: https://github.com/steverhoades/oauth2-openid-connect-server/blob/v3.0.1....

composer update drupal/simple_oauth -W should do the trick or am I missing something?

You need to update simple_oauth with dependencies, thephpleague/oauth2-server needs to be 9.2, for more info see: 🌱 Move to thephpleague/oauth2-server 9.0 Active and https://git.drupalcode.org/project/simple_oauth/-/jobs/4456948.

How did you verify that the tokens are invalided for those specific entity updates?

In hook simple_oauth_entity_update the tokens get deleted if the consumer or user entity get's updated. In 📌 Auth revoke on profile update Needs work we are trying to improve this logic with configurations.

Thanks for reviewing/testing @tstoeckler!

bojan_dev → created an issue.

bojan_dev → created an issue. See original summary → .

Looks good, merged!

TY, merged!

Nice work!