Non-bearer Authorization Directive

[expede]

Today most (all?) of us are using the Authorization: bearer header. Due to the delegation semantics, this isn't a pure bearer token; it must be delegated to the recipient.

The Authorization header spec leaves space for more directives.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization

Do we want to use something like Authorization: cap <token> or Authorization: ucan <token>?

[expede]

cc @dholms & @cdata I waffle back and forth on the above, but I'd love to get your take on this

[cdata]

To add some evidence, I cast a net to the interwebs and found this Express middleware which hardcodes the expectation of bearer in the header value:

https://github.com/auth0/express-jwt/blob/f0e41d6ee00c0e22148c0b45704c7b05494aa790/src/index.ts#L124-L140

[cdata]

Some Rust evidence from crates I'm using today:

https://github.com/seanmonstar/reqwest/blob/18dfac4fe2590f2e3a27e808c72fb26e6d9af98b/src/blocking/request.rs#L277-L294

Actually, the typed header implementation used in Axum is flexible enough to accommodate arbitrary directives if I am reading it correctly:

https://github.com/hyperium/headers/blob/ffca4a90482cc31875ac9a9364b7ea252f8c0afa/src/common/authorization.rs#L74-L107

But it only comes with built-in implementations for bearer and basic.

[expede]

Great feedback, thanks @cdata 👍

[bgins]

Axum can be set up with a custom RequireAuthorizationLayer like in the second example shown here: https://docs.rs/tower-http/latest/tower_http/auth/require_authorization/index.html. That gives you access to the request, and you can pull the authorization header off it.

It's also possible to write a custom extractor to examine the authorization header and convert that to a layer that is run before any protected routes.

[cdata]

Yes, my point is just that you don't have to do some amount of (trivial) parsing if you are using bearer. It's just a measurable amount of friction, not a blocking detail.