Authorization safety

[obo20]

I noticed that we're allowing the user to pass their authentication tokens via query parameters to the API instead of using a bearer token. Is there a specific reason for this?

There's a few security issues with passing credentials via query parameters in certain environments. A few notable ones:

• Query parameters get saved in browser history and often in server logs

• Browser extensions are often given access by users to query parameters from any site. While headers and cookies are only available to domains that the user permits.

I'm not sure the full context in which this API is going to be utilized but this was something I at least wanted to point out.

[lidel]

IIRC it was suggested in https://github.com/ipfs/pinning-services-api-spec/issues/6#issuecomment-655056961:

Authorization: Bearer <key> has the benefit of limiting the problems you’re taking on. If you accept it via header and querystring you’d have a fast path to adoption in pretty much any client.

@mikeal how strongly do you feel about querystring? Removing qurystring and leaving http header only would simplify the spec and remove concerns mentioned above. I believe most of HTTP clients will be capable of setting Authorization: Bearer <key> header anyway, including fetch in browser contexts.

[mikeal]

There’s a tradeoff either way so I would just go with whatever is easiest.