| HN Mirror

> I think that's a good idea, and is plainly allowed by the standard.

Watch out, "secret-token:domain/authtype/code" is not a valid secret-token by the standard!

The standard has grammar:

  [RFC8959]
  secret-token-URI    = secret-token-scheme ":" token
  secret-token-scheme = "secret-token"
  token               = 1*pchar

  [RFC3986]
  pchar               = unreserved / pct-encoded / sub-delims / ":" / "@"
  pct-encoded         = "%" HEXDIG HEXDIG
  unreserved          = ALPHA / DIGIT / "-" / "." / "_" / "~"
  sub-delims          = "!" / "$" / "&" / "'" / "(" / ")"
                        / "*" / "+" / "," / ";" / "="

That means "/" cannot be part of a secret-token, and a strictly standard-compliant scanner will not pattern-match on "secret-token:domain/authtype/code".

I think that may be a design mistake as people will inevitably build tokens with those characters (using the same reasoning you did), and they won't show up in some scanners (any that are strictly compliant). "/" is allowed in query strings despite being a path delimiter before the query string; allowing it in secret-token would make sense too.

Fortunately it's not a security problem as long as "/"-delimited paths in tokens don't start with "/", because the preceding characters will be enough to match anyway. However, if you have a scanner where you whitelist some strings after being shown matches, the fact it doesn't match the security part of the token introduces a risk of mistakenly whitelisting too broadly (just the domain in this example), and of course there's a chance someone may use a path starting with "/" without realising this is a problem.