Help with RFC implementation
Hello there!
Currently I'm trying to implement support for RFC-9126 in self-hosted fork of Zitadel to help migration from Keycloak
I'd like some help to understand the best way to implement this one:
1. Add new type of event and all wrapping staff (commands/interfaces etc) for PAR and reuse common event store
2. Try auth_request-like approach with separated cache and Postgres-based storage: OPStorage -> AuthRequesrRepo -> AuthRequestCache
Both can live but after internal discussion with my team I think that second one makes more sense since it'll generate much less useless data in storage since event won't handle any unique data itself
Main problem is that we still not sure if it's a good idea at all to extend existing repos since we'd like to merge our solution to upstream once it'll be done. Some help on this topic will be very helpful
P.S. created issue for more general talk about OAuth2/OIDC extentions: https://github.com/zitadel/zitadel/issues/10164
GitHub
Support of popular OAuth2 extentions · Issue #10164 · zitadel/zit...
Preflight Checklist I could not find a solution in the existing issues, docs, nor discussions I have joined the ZITADEL chat Describe your problem There are actually a lot of RFCs extending OAuth2 ...
5 Replies
Hey there @migregal, thanks for sharing the challenge you're facing with us. Let me tag in one of our engineers @Matías who can provide more insight on your case and what next steps could be.
Hello there
@Matías, can u give any feedback on this topic?
As for now, I'd like some help with choosing proper way to implement RFC-9126 (eventstore or direct access of postgres table)
My main concern is about way it'll be merged in upstream if team is OK with extending existing OAuth2/OIDC implementation (being discussed in linked github issue)
Hi @migregal, thanks for reaching out! Sorry about the late reply.
As for now, I'd like some help with choosing proper way to implement RFC-9126 (eventstore or direct access of postgres table)Understood, allow me to check with our Product Manager internally, and I will get back to you shortly with a reply on the best way to implement this.
Hello there!
@Matías, I'd researched current source code in main branch and it seems like the best option is just to reuse some shared internal/cache implementation to store data and that's all
I'll try my best to impl MVP for RFC-9126 and share results as contribution PR on github
Hi @migregal, thank you! I believe that's the correct approach. I discussed this internally and this is basically what was said:
- ZITADEL is shifting to a “relational-source + event-log” architecture: state lives in Postgres, events are just an immutable audit stream.
- For RFC 9126 (PAR), follow the same pattern:
1. CRUD PAR records in a par_requests table (reuse the AuthRequestRepo/AuthRequestCache style).
2. After each create/delete, emit a lightweight par.added / par.used event to the event store for audit/CDC.
- This keeps the event store slim, avoids “useless data,” and matches our roadmap—so your PR is far more likely to be accepted upstream.
- Wrap it in a feature flag (e.g. par.enable), add tests + docs, and you’re good to open the PR.