1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

Limits on overall url length

Issue #1055 open
Joseph Heenan created an issue

As discussed on https://github.com/openid-certification/oidctest/issues/134 there are interoperability issues associated with some fields being overly long, in particular with the state & nonce fields where the spec does not limit the size of values supplied by the RP.

The core spec should probably give some guidance on lengths.

Comments (11)

  1. Michael Jones
    • changed status to open

    Per the discussions on the certification issue, there are no hard limits. It's certainly true that deployments need to be mindful of the actual limits present in their operating environments.

  2. gffletch

    Hi Joseph,

    Given that operating environments are all different, is there any specific non-normative text you would like to see added to the core spec?

  3. Joseph Heenan reporter

    That's a good question.

    I think (and hopefully this is the not contentious) that the general should be the certified implementations should work together. That is not currently the case, and the certification team are reticent to add new tests because the standard doesn't say much.

    Here's a suggestion on text, though I have not given this a huge amount of thought:

    RP should keep the length of the authorization endpoint URL query below 1900 characters as there are known issues with various web browsers, proxies and servers above this size.

    OPs should not apply any limit the length of state. RPs should be aware that using overly long state values may hit URI length limits.

    OPs should not apply any limit the length of nonce. RPs should follow the implementation notes for nonce and hence not send nonces longer than 128 characters.

  4. gffletch

    In regards to the 1900 character limit for /authorize URLs... I'm assuming you have known implementations that fail if this is the case? To me, that limit seems too low to be giving guidance on and I'd prefer we encourage the suites to support at least 4K URLs.

    Maybe the converse of testing a max length in the certification suite is to test a minimum in the certification tests ensuring that implementations support at least a URL length of X.

  5. Joseph Heenan reporter

    It's perhaps not the implementations that fail but everything else involved :-)

    We've seen a bank in the UK ecosystem where likely the gateway server returned "Request-URI Too Long The requested URL's length exceeds the capacity limit for this server." for URLs over around 2069 characters. It may be this was a choice on their part rather than a hard limit in any software, but it certainly caused interoperability issues.

    https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers suggests various other limits (many of which don't affect this scenario), and it may be that in modern times we may not need to worry about IE9 and earlier, though if I remember correctly one UK bank was still very recently concerned about Windows XP (and hence I presume IE8) users being able to access their service.

    I wouldn't object to encouraging support of longer URIs.

  6. Joseph Heenan

    A similar issue got raised to the certification team again, https://gitlab.com/openid/conformance-suite/-/issues/928 - in that case the server has a limit on state of 36 characters maximum, whereas the FAPI tests have (dating back to the original OpenBanking UK security profile tests years ago) always insisted that servers support 128 character states, and we’ve seen RPs in the UK using states exceeding 300 characters.

    ‌

    I think it would be helpful if one of the working groups could reach consensus on a minimum values here, as it’s a potential interoperability minefield currently and there’s not really any guidance given to RPs that guides them down a path of being interoperable.

    I’d suggest something along the lines of:

    OPs MUST support state and nonce values that are 128 characters long and MAY support longer state and nonce values.

    To ensure interoperability, RPs SHOULD NOT use state or nonce values longer than 128 characters.

    (I think the exact choice of the limit is open for discussion, but until https://gitlab.com/openid/conformance-suite/-/issues/928 was opened we’d not had any real pushback against the 128 character choice. I think some kind of clear recommendation is would be good, otherwise there’s an argument that the de facto position is the requirement is 11 characters per the examples in OpenID Connect Core or 22 characters as per the FAPI spec examples, though it’s also arguable that in the absence of any stated limit the choice of state length is the RPs to make, in the same way that it’s the OPs decision how long an access token is.)

    ‌

  8. Joseph Heenan reporter

    Thanks Mike. I kind of understand the argument and the reluctance.

    Nevertheless I feel the need to strongly make the point that it is better to define some guidance on sizes in specs, rather than (as we are currently doing) rely on the certification tests to set some kind of de facto minimum that must be supported and isn’t really clearly documented.

    The reality of the situation is that, as of today, we are certifying RP and OP implementations that may not actually work together.

  9. Joseph Heenan reporter

    I continue to be uncomfortable with the fact that certified RPs & OPs may not work together due to different understandings on what acceptable lengths of nonce/state are.

    In an attempt to improve the situation, I’m suggesting the following to the FAPI WG:

    OP tests required that 128 character states and 45 character nonces work, and that 384 character states or nonces either work correctly or are refused. [currently the FAPI tests are only testing 10 character nonces, same as OIDCC tests]

    RP tests will warning if a state over 128 or a nonce of 45 characters is used. [there is currently no check for this in the FAPI tests, same as OIDCC tests]

    Relevant issue in certification suite is https://gitlab.com/openid/conformance-suite/-/issues/1217

    This is effectively sticking some pegs in the sand that are going to start to create a de-facto situation. An errata update to the Connect spec would be a sensible place to at least give some guidance to implementers so that they find out about the de-facto situation as early as possible - e.g. perhaps:

    There are interoperability considerations around the lengths of states and nonces that can relying parties can use, as well as potentially limits on the overall length of the authorization endpoint URL. The OpenID Connect certification tests require that an OpenID Provider correctly handles states of 128 characters and nonces of 45 characters. If relying parties wishes to use states/nonces longer than these values then this is a matter between those relying parties and the authorisation servers they intend to use.

    ‌

  12. Log in to comment
Assignee
Type
bug
Priority
major
Status
open
Component
Core
Milestone
–
Version
–
Votes
0
Watchers
0
Jira: the preferred issue tracker for Bitbucket. Join the team!