-
assigned issue to
FAPI2 Baseline + jarm & iss draft
I think when using JARM with FAPI2 baseline, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-iss-auth-resp the iss draft is essentially a ‘no op’ - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-iss-auth-resp#section-2.4 says:
Note: The "JWT Secured Authorization Response Mode for OAuth 2.0
(JARM)" [JARM] defines a mechanism that conveys all authorization
response parameters in a JWT. This JWT contains an "iss" claim that
provides the same protection if it is validated as described in
Section 2.4. Therefore, an additional "iss" parameter outside the
JWT is not necessary when JARM is used.
(although ‘not necessary’ is subtly different to ‘MUST NOT’)
Although according to JARM all auth response parameters must be inside the JWT, so it would arguably be an error to have iss outside the JWT.
However https://datatracker.ietf.org/doc/html/draft-ietf-oauth-iss-auth-resp#section-2.4 also says this, which really says that when the iss draft is used clients MUST check for the value outside the JWT:
Clients that support this specification MUST extract the value of the
"iss" parameter from authorization responses they receive if the
parameter is present. Clients MUST then decode the value from its
"application/x-www-form-urlencoded" form according to [RFC6749],
Appendix B, and compare the result to the issuer identifier of the
authorization server where the authorization request was sent to.
I think just to make things clear it would be worth adding “if JARM is not used” to both of these clauses in FAPI2 baseline:
shall return an
iss
parameter in the authorization response according to [@!I-D.ietf-oauth-iss-auth-resp]shall check the
iss
parameter in the authorization response according to [@!I-D.ietf-oauth-iss-auth-resp] to prevent Mix-Up attacks
Comments (8)
-
reporter -
reporter - changed status to closed
FAPI2 iss + JARM
Make clear that the iss draft isn't necessary if using JARM.
closes
#478→ <<cset d3188abf52fc>>
-
reporter -
- changed status to open
-
In RFC9207 we added a very detailed description on how the parameter is to be checked. JARM lacks this check. Therefore we said in the note you quoteed “This JWT contains an iss claim that provides the same protection if it is validated as described in Section 2.4.”
I don’t think, however, that the differences are really relevant here. They concern, for example “clients [that] interact with both authorization servers supporting this specification and authorization servers not supporting this specification” - a case we hopefully don’t see in FAPI.
It would be nicer to have unified normative requirements here, but I’m fine with the wording from the pull request.
-
@Joseph Heenan are you ok for us to close this issue?
-
reporter - changed status to resolved
Yes - the PR resolved the potential issue, thanks Dave.
-
- changed component to FAPI2: Security Profile
- Log in to comment