> Clients MUST NOT pass access tokens in a URI query parameter
I've been wondering about this lately. This makes sense from a security perspective, but the primary alternative is setting a header like Authorization: Bearer, which makes your request subject to browser cross-origin restrictions, and all the fun that comes with CORS. In my case, the extra round-trip required for the CORS preflight in this situation is simply a non-starter for my application.
It would be nice if there was an escape hatch for developers who understand the risks. More background in this SO question I asked a couple days ago:
Can you give more details on how you'd use a cookie here? SameSite=Strict/Lax can't be used cross domain, and none is no good for mutating requests due to CSRF.
Request body works, but it forces you to split your API if you want to be cache friendly. What I mean is ideally you want public data to be GETable and thus cacheable. In the system I'm building, any given path can change back and forth from being public vs requiring authorization, so if I use requests bodies (ie POSTs), I would need to detect whether the data is public or not before making the request and choose between GET or POST at request time. That might not actually be that bad; I'll have to think about it more.
I've been wondering about this lately. This makes sense from a security perspective, but the primary alternative is setting a header like Authorization: Bearer, which makes your request subject to browser cross-origin restrictions, and all the fun that comes with CORS. In my case, the extra round-trip required for the CORS preflight in this situation is simply a non-starter for my application.
It would be nice if there was an escape hatch for developers who understand the risks. More background in this SO question I asked a couple days ago:
https://stackoverflow.com/q/61563348/943814