Repository navigation
[OID4VCI] Issuance with Authorization Code Flow assumes same client_id for offer creation and redemption - #50576
Conversation
There was a problem hiding this comment.
Pull request overview
Adjusts OID4VCI credential-offer creation so that Authorization Code Grant offers no longer assume the same client_id is used for both offer creation and subsequent redemption, addressing #48188 (wallets may authenticate/redeem using their own client).
Changes:
- Stop binding authorization-code credential offers to the creating client (
targetClientId = nullfor auth-code offers). - Keep pre-authorized code offers bound to the authenticated client.
- Update Javadoc section headings to explicitly name the corresponding grant types.
Comments suppressed due to low confidence (1)
services/src/main/java/org/keycloak/protocol/oid4vc/issuance/OID4VCIssuerEndpoint.java:446
- The Javadoc for the authorization-code offer section doesn’t mention the newly introduced behavior that these offers are no longer bound to the client_id used to create them (only pre-authorized offers are). Adding an explicit bullet here would help prevent future regressions and clarify the intended security model (client authorization is enforced via configured credential scopes/policies, not by matching the creator client_id).
* <b>Authorization Code Grant Offer</b>
* <ul>
* <li>If targetUser is null or empty, the generated offer is "anonymous"</li>
* <li>If targetUser is equal to the current login, the offer is "self issued"</li>
* <li>If targetUser is none of the above, the offer is "targeted"</li>
f496177 to
6267e81
Compare
6267e81 to
74e363e
Compare
74e363e to
57b9979
Compare
|
@tdiesler LGTM but i just wonder why no test has to be changed for this? Maybe you should add one? |
57b9979 to
0b1cf55
Compare
Yes, good catch - I added the wanted test coverage |
0b1cf55 to
5c2a54b
Compare
5c2a54b to
5fc887a
Compare
5fc887a to
9e21a77
Compare
9e21a77 to
5fc887a
Compare
5fc887a to
1f19a27
Compare
1f19a27 to
b2a132e
Compare
234c341 to
b2a132e
Compare
b2a132e to
5fc887a
Compare
…d for offer creation and redemption closes keycloak#48188 Signed-off-by: Thomas Diesler <tdiesler@proton.me> * Stop binding authorization-code credential offers to the creating client (targetClientId = null for auth-code offers). * Keep pre-authorized code offers bound to the authenticated client. * Update Javadoc section headings to explicitly name the corresponding grant types.
5fc887a to
6b8ed25
Compare
There was a problem hiding this comment.
@tdiesler @dominikschlosser @IngridPuppet Thanks for the PR and for the reviews!
closes #48188
Adjusts OID4VCI credential-offer creation so that Authorization Code Grant offers no longer assume the same client_id is used for both offer creation and subsequent redemption, addressing "wallets may authenticate/redeem using their own client".