RFC 6749 discusses client impersonation
https://datatracker.ietf.org/doc/html/rfc6749#section-10.2
> The authorization server SHOULD NOT process repeated authorization
> requests automatically (without active resource owner interaction)
> without authenticating the client or relying on other
On Wed, 5 Apr 2023 at 08:00, M Hickford wrote:
>
>
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-08.html#name-countermeasures-2
> says
>
> > To prevent injection of authorization codes into the client, using
code_challenge and code_verifier is REQUIRED for clients,
OAuth defines two client types, confidential and public.
https://datatracker.ietf.org/doc/html/rfc6749#section-2.1
> The client type designation is based on the authorization server's definition
> of secure authentication and its acceptable exposure levels of client
> credentials. The
Has anyone tried scoring how well public OAuth authorization servers
follow tbe best practices described in
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics
?
I scored some software forges including GitHub, GitLab, BitBucket on a
subset of best practices
https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-08.html#name-countermeasures-2
says
> To prevent injection of authorization codes into the client, using
> code_challenge and code_verifier is REQUIRED for clients, and authorization
> servers MUST enforce their use unless both of the
