Am 18.05.2018 um 18:20 schrieb John Bradley: > I am not against having "as" as REQUIRED. > > While we are at it should we recommend that rfp be single use? If the state JWT is *not* signed and the client has no other means to check the integrity of the JWT (e.g., by storing a copy in the browser's session), rfp MUST be single use, where single use means that once a new authorization request has been sent, all old "rfp" values (for that browser session) become invalid. (Rationale: The state reuse attack across AS would still be possible, since an attacker could just replace the "as" value in an unsigned JWT.)
If the state JWT is signed and "as" is contained in the JWT, rfp does not need to be single use in this sense. To prevent defense-in-depth against the usage of leaked of state values, in both cases, a state value that has once been accepted at the redirection endpoint SHOULD be invalidated for future uses. In the the case of an unsigned JWT, this means that a specific rfp value SHOULD only be accepted once. If the JWT is signed, it would be sufficient to memorize the hashes of used JWTs or their jti values, and decline JWTs with the same hash/jti. (SHOULD since this is impossible for stateless clients.) (Overall, it seems like not signing state JWTs is not a good idea.) > > This draft hangs around as a ID and probably is not read by most > people. > > We may also want to mention it in security topics if we haven't. I will check the status there. > > I need to update this in the next couple of weeks to keep it from > expiring anyway. I took a cursory look at the draft and I see two more issues: (1) > The "as" claim if present MUST correspond to the URI endpoint registered as the "redirect_uri" for that AS. This wording is not sufficient: - The AS must be the expected AS (if there are means to check that, for example the browser session). - The redirection URI on which the authorization response was actually received matches the "as" value. (2) > The client parses it as a JWT. It then verifies the signature of the JWT (if signed) The client should check the signature if it expects the JWT to be signed, not only if the received JWT is signed. I may be nitpicking here, but developers should not be lead to believe that "if signed(received_jwt): check_sig(received_jwt)" would be a good implementation choice. - Daniel -- SEC - Institute of Information Security University of Stuttgart Phone +49 711 685 88468 Universitätsstraße 38 - 70569 Stuttgart - Room 2.434
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
