Started looking at api-key

[markusahlstrand]

This is work in progress.

The idea is that you can use static api keys to limit access to other handlers and origins.

From my perspective it's basically swapping a static api-token for another token that probably expires after a short time.

It seems that api-tokens typically are passed in headers (either as basic auth or as a custom api-header) and as querystrings.

On the output side I can imagine supporting jwt's with refresh-tokens, pre-signed url's, basic auth and maybe custom text-blobs that are added to some header. I'm not sure what the scope of this handler should be? Should it just add some auth info to the state and a separate handler can use this info or should it add all headers so that the request can be passed on to an origin or loadbalancer handler?

How should the auth-data/tokens be handled that are stored in kv-storage? I don't really like storing anything as clear text so I think it needs to be encrypted somehow. In a normal server perspective the passwords are hashed, but in this case it's rather the tokens stored that are sensitive. I think we could use a similar approach to the oauth2-handler where part of the api-key is used to encrypt the tokens.