webhamster

German implementer here. We have to use some kind of attestation mechanism per the eIDAS implementing acts. That doesn't work without operating system support.

The initial limitation to Google/Android is not great, we know that, and we have support for other OSs on our list (like, e.g., GrapheneOS). It is simply a matter of where we focus our energy at the moment, not that we don't see the issues.

For starters, without restrictions on the redirect URI, I (as the attacker) can just redirect a user to the authorization endpoint with a client ID of a trustworthy client, a redirect URI pointing to my server, and a PKCE challenge that I selected so that I know the PKCE verifier. The auth code will end up at my server and I can redeem it, giving me (instead of the trustworthy client) access to the user's resources. If the client is a confidential client, I can use a authorization code injection attack to redeem the code and work with the user's resource.

That's not correct. There are a number of attacks that can be mitigated by both, but PKCE serves as a very effective defense in case an authorization code leaks to an attacker. Such a leak can be caused by a malicious script on the redirect URI, referer headers, system or firewall logs, mix-up attacks and other problems even when the redirect URIs are restricted.

There is a good reason why we mandate both redirect URI allowlisting AND PKCE in the OAuth Security BCP RFC draft. One learning from our discovery of mix-up attacks with "code injection" was that client authentication is not sufficient to prevent the misuse of authorization codes.

Can we finally stop conflating an encoding/signature/encryption method with a transport/storage mechanism?!

Quote:

   The resource owner password credentials grant MUST NOT be used.  This
   grant type insecurely exposes the credentials of the resource owner
   to the client.  Even if the client is benign, this results in an
   increased attack surface (credentials can leak in more places than
   just the AS) and users are trained to enter their credentials in
   places other than the AS.

   Furthermore, adapting the resource owner password credentials grant
   to two-factor authentication, authentication with cryptographic
   credentials, and authentication processes that require multiple steps
   can be hard or impossible (WebCrypto, WebAuthn).

FYI, the IETF plans to deprecate the Resource Owner Password Credentials Grant you are talking about [1].

[1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics

There is no issuer in OAuth. Therefore, the distinct-redirect-URI solution is the most universal.

Also, we now have formal proofs for the security of the OAuth and OIDC protocols.

Does Hydra follow the OAuth Security BCP (https://tools.ietf.org/html/draft-ietf-oauth-security-topics...)? I do not see PKCE or mix-up mitigation mentioned, for example.