jogux
Stateful refresh tokens have other practical issues, we've seen several cases in OpenBanking ecosystems where stateful refresh tokens resulted in loss of access for large numbers of users which things went wrong.
The quirks you mention are sorted in the next revision. The cipher requirements come from the IETF TLS BCP [1] (which is clearer in the new version). If you think the IETF TLS WG got it wrong, please do tell them.
As other people said elsewhere, this isn't about completeness - OAuth2.1 is a framework, FAPI is something concrete you can for the large part just follow, and then use the FAPI conformance tests to confirm if you correctly implemented it or not. If you design an authorization code flow flowing all the recommendations in OAuth 2.1, you'll end up implementing FAPI. Most people not in this space implementing OAuth will struggle to know how to avoid the traps once they stop following the recommendations, as "implementing OAuth securely" isn't usually their primary mission.
Sadly the amount of money you need to spend on security & support for such a service does make offering such a service (particularly for free) not viable for smaller entities, there are some big economies of scale to make these things viable that work particularly well if you can also get big companies to pay for commercial offerings.
OpenID Connect does of course remain free view/use, but now people in the above situation have an easier option available to them.
Even some RFCs are basically available as ISO standards and vice versa, e.g. for time/date formats you almost never need to buy ISO8601 and can just read RFC3339 (which is technically a 'profile' of ISO8601).
Was OAuth2 wrong to land exactly where it did on security back in 2012 or before? It seems really hard to say - it clearly didn't have great security, but it was easy to implement and where would we have ended up if it had better security but much poorer adoption?
Does the OAuth working group recognise those failures and has it worked hard to fixed them over the years since? Yes, very much so.
Has OAuth2 being adopted in use cases that do require high levels of security? Yes, absolutely, OpenBanking and OpenHealth ecosystems around the world are built on top of OAuth2. In particular the FAPI profile of OAuth2 that gives a pretty much out-of-the-box recipe for how to easily comply with the OAuth security best current practices document, https://openid.net/specs/fapi-2_0-security-profile.html (Disclaimer: I'm one of the authors of FAPI2, or at least will be when the next revision is published.)
Is it still a struggle to try and get across to people in industries that need higher security (like banking and health) that they need to stop using client secrets, ban bearer access tokens, to mandate PKCE, and so on? Yes. Yes it is. I have stories.
It's technically not compliant, but people definitely do so, and there are definite security advantages to requiring it.
Technically the 'nonce' in OpenID Connect provides the same protections, and hence the OAuth Security BCP says (in a lot more words) that you may omit PKCE when using OIDC. However in practice, based on a period in the trenches that I've mostly repressed now, the way the mechanisms were designed means clients are far more likely to use PKCE correctly than to use nonce correctly.)
For people looking for an easy-to-follow interoperability/security profile for OAuth2 (assuming they're most interested in authorization code flow, though it's not exclusive to that) FAPI2 is a good place to look, the most recent official is here:
https://openid.net/specs/fapi-2_0-security-profile.html
This is a good bit shorter than the 50 or so pages of security BCP :)
FAPI2 should also be moving to 'final' status within the next few months.
(Disclaimer: I'm one of the authors of FAPI2, or will be once the updated version is published.)
https://github.com/openid-certification/oidctest
Apple are absolutely 100% free to run the tool and fix any issues found without any payment to anyone except their own engineer's time.
(There is a fee to pay for the 'OpenID Certified' logo and to be listed as certified, but in my opinion just running the free tool and fixing any interoperability issues is a major benefit by itself.)
The contributor referred to (John Bradley) as saying that OAuth 2.0 implementation mistakes are almost inevitable is one of the authors of the OpenID Connect spec, and if you follow the citation link ( https://mailarchive.ietf.org/arch/msg/oauth/WuT1tmFoxs8S_2v7... ) you'll see him mention that the flaw referred to is fixed in OpenID Connect.
The main requirement therein I would say is that you can't use OpenID to describe an implementation unless it implements the mandatory-to-implement parts of the relevant protocol specification (and all the specifications are 100% free; e.g. https://openid.net/specs/openid-connect-core-1_0.html ). That's more about interoperability than anything else.
Apple are actually following the OpenID standard, that's why the list is differences is concise and to the point. Several of the pieces that are missing/different are items that were added to OpenID to prevent attacks that have been used against pure OAuth 2.
Many of the potential attacks relate to fooling the third party sites as to what happened, so it is difficult/impossible to mitigate them with magic on Apple's side.
(disclaimer: I'd listed as a contributor on above doc. I'm writing here in a purely personal capacity.)
From example, the request object in OpenID Connect (that can prevent authorization request parameters from tampering) is only just now coming out as an RFC https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19