Emelia Smith

@nbulaj yeah, we could ship this and my other changes as a 6.x and just indicate major breaking changes

@gkemmey that looks like overall a good change, but I think we should continue having `force_pkce`, but also introduce `require_pkce_for` and just make the default implementation use the value of...

@gkemmey if you want, open up that branch as a pull request against ThisIsMissEm:fix/allow-force-pkce-for-all-clients and I'll rebase it in, keeping authorship.

what happens if you use `use_refresh_token true`? I don't think this option takes a hash of options? It does take a block, but that needs to return true/false. There isn't...

So this actually works now, and all the tests pass. All we need now is: - tests for the classes in `doorkeeper/oauth/client_authentication/` - any tests we want for the client...

I think I'm now settled on and happy with this code and the test coverage, but let me know if it needs more.

The "correct" place for this would be in doorkeeper-openid_connect, but it doesn't yet support them: https://github.com/doorkeeper-gem/doorkeeper-openid_connect/blob/v1.8.11/app/controllers/doorkeeper/openid_connect/discovery_controller.rb

Oh, actually, that's the client assertions spec, `private_key_jwt` is a token endpoint auth method, which is what I was thinking of, which allows a public client to use client credentials...

We'd need support somewhere for OAuth Assertion Framework [RFC7521](https://datatracker.ietf.org/doc/html/rfc7521) for this to be possible — I don't think this spec is currently implemented in any maintained doorkeeper code or plugins....

This would be enabled by #1772, which allows registering additional client authentication methods.