Maybe we could add a "reminder" line like: The client SHOULD consider browser URL length limits when creating the state parameter and leave sufficient buffer for the AS to attach additional parameters to the redirect_uri.
Emelia, another possibility for you is to recommend clients to use POST, and also POST back to them. All: OAuth says the AS may accept POST authorization requests, but without a corresponding response mechanism, it may not help. OIDC defines response_mode=form_post to address this. Is there any precedent for trying to reconcile specs/extensions across working groups? (I know there's a large overlap in people, at least.) On Mon, Feb 24, 2025 at 9:58 AM Filip Skokan <panva...@gmail.com> wrote: > > Is there anything I've missed here? > > No, there is no upper limit defined. You can generally expect random > values as well as larger JSON objects, even JWTs (e.g. as per > https://datatracker.ietf.org/doc/html/draft-bradley-oauth-jwt-encoded-state-09 > ). > > S pozdravem, > *Filip Skokan* > > > On Mon, 24 Feb 2025 at 18:52, Emelia S. <emelia= > 40brandedcode....@dmarc.ietf.org> wrote: > >> Hi all, >> >> I've looked through both the OAuth 2 and Current Security Best Practices >> documents, and no where does it seem to mention a max-length for the >> user-supplied "state" parameter for use in authorization code grant flows. >> Should the server implement a maximum length? Is the server allowed to set >> a maximum allowable length for the state parameter? >> >> The issue we're seeing is that some clients are encoding large json >> values in the state parameter (which feels wrong, but is technically >> allowable), and this causes an error with nginx and other software where >> the resulting Location header is too large, causing a 502 error. >> >> See: >> - https://github.com/mastodon/mastodon/issues/12915 >> - https://github.com/doorkeeper-gem/doorkeeper/issues/1554 >> >> The ABNF for `state` is just: state = 1*VSCHAR — there is no mention of >> an upper limit, per >> https://www.rfc-editor.org/rfc/rfc6749.html#appendix-A.5 >> >> Is there anything I've missed here? >> >> Yours, >> Emelia >> >> >> >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-le...@ietf.org >> > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > -- Nick Watson | Software Engineer | nwat...@google.com | (781) 608-3352
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
