Comment by jcmfernandes
8 months ago
Since OIDC is a layer on top of OAuth 2, it inherits its complexity. OAuth 2.1 (currently draft) will help bring some sanity. GNAP - https://oauth.net/gnap/ - will, one day, tie everything.
8 months ago
Since OIDC is a layer on top of OAuth 2, it inherits its complexity. OAuth 2.1 (currently draft) will help bring some sanity. GNAP - https://oauth.net/gnap/ - will, one day, tie everything.
GNAP was just codified to be an RFC: https://www.rfc-editor.org/rfc/rfc9635.html
When I looked at it a few years ago[0] it seemed like a modernization of OAuth (which still uses form posts(?!?)). But I'm worried about uptake, myself. Haven't had a single client request it or bring it up.
0: https://fusionauth.io/blog/gnap-next-gen-oauth
I see that the GNAP WG has been closed [0]. I don't know how this works with IETF, but is anyone caring for the spec and its adoption atm?
[0] https://mailarchive.ietf.org/arch/msg/txauth/uEXUsdk43TbPlls...
The working group was closed because the core specification is published as a finished RFC:
https://www.rfc-editor.org/rfc/rfc9635.html
The group's other major work, the GNAP RS specification, has passed IESG final review and is in the queue with the RFC editor. This means that it's finished except for some final text edits and will be a final RFC soon too:
https://www.rfc-editor.org/current_queue.php#draft-ietf-gnap...
The group closed because it didn't have any more work to do.
As for adoption, we've seen it implemented in a handful of spaces around the internet, most of them in places where there are core problems with the OAuth model or GNAP offers cleaner support for some key feature like ephemeral clients or key management.
PS. I submitted GNAP RFC separately: https://news.ycombinator.com/item?id=42105487