Authentication mechanism is not compliant with HTTP grammar

[josegomezr]

By complete random chance I was going over grep.app looking for real-world examples of authorization headers and stumbled upon this repo

Didn't want to open a full issue as it's not really critical, is rather a rigor thing, but would like to lay down the observations and see what y'all think.

This is the odd example I found:

payload/docs/authentication/api-keys.mdx

Lines 51 to 65 in 034a267

	### HTTP Authentication
	To authenticate REST or GraphQL API requests using an API key, set the `Authorization` header. The header is case-sensitive and needs the slug of the `auth.useAPIKey` enabled collection, then " API-Key ", followed by the `apiKey` that has been assigned. Payload's built-in middleware will then assign the user document to `req.user` and handle requests with the proper [Access Control](../access-control/overview). By doing this, Payload recognizes the request being made as a request by the user associated with that API key.
	**For example, using Fetch:**
	```ts
	import Users from '../collections/Users'
	const response = await fetch('http://localhost:3000/api/pages', {
	headers: {
	Authorization: `${Users.slug} API-Key ${YOUR_API_KEY}`,
	},
	})
	```

The documentation says that the authorization header value must match:

Authorization: ${Users.slug} API-Key ${YOUR_API_KEY}
; for example
Authorization: foo API-Key bar

However RFC 9110 (what I believe to be the current normative RFC for HTTP semantics) defines the Authorization header as follows (Took the liberty to collect all the relevant ABNF grammar):

Authorization = credentials
credentials = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS "," OWS auth-param ) ] ) ]

auth-scheme = token
auth-param = token BWS "=" BWS ( token / quoted-string )

tchar = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
token = 1*tchar
token68 = 1*( ALPHA / DIGIT ) *"="

quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = HTAB / SP / "!" / %x23-5B / %x5D-7E / obs-text
obs-text = %x80-FF
quoted-pair = %x5c ( HTAB / SP / VCHAR / obs-text )

OWS = *( SP / HTAB )
BWS = OWS
SP = %x20
DQUOTE = %x22
HTAB = %x09
DIGIT = %x30-39
ALPHA = %x41-5a / %x61-7a
VCHAR = %x21-7E

The header value foo API-Key bar can't be matched against credentials, the token68 alternative does not allow anything afterwards, is an stop condition.

At best it could fit the syntax if we ignore the last invalid token and interpret it as:

auth-scheme = foo
token68 = API-Key

But that'd lose the API key which is effectively useless to authenticate.

In order to be HTTP Compliant the header value I think the easiest is to use the auth-param syntax, this also would align with the recommendation on § 16.4.2

The "token68" notation was introduced for compatibility with existing authentication schemes and can only be used once per challenge or credential. Thus, new schemes ought to use the auth-param syntax instead, because otherwise future extensions will be impossible.

Maybe something along the lines of:

Authorization: API-Key key=${YOUR_API_KEY},username=${Users.slug}
; for example
Authorization: API-Key key=bar,username=foo

However that'd be a breaking change, in case being compliant is a desire, a different auth scheme name would make things easier to interop:

; legacy
Authorization: foo API-Key bar
; compliant
Authorization: Payload-API key=bar,username=foo

In case it's desired to be compliant, the suggestions above can pave the way to it, and also provide extensibility for future features in authentication :)

That was my ted talk ™️ /s