…so allow…either?
What’s so hard about checking two headers (Authorization: and Cookie:) for the authtoken?
It’s a security thing. The HttpOnly cookie can’t be stolen using XSS or something like that, while a bearer token must be stored somewhere where javascript can see it.
That’s assuming the client wants to make a web app. They may need to connect something else to that API.
It’s perfectly normal to be able to cater to more authentication scenarios than “web app logging in directly to the target API and using its cookies”.
If they want to make a web app they should use the cookie mechanism but ultimately each client app is responsible for how it secures its access.
Okay.
So make your webpage send the authtoken in a cookie and leave off the Authorization header, and have your third party (presumably native) clients send an Authorization header but not any cookies, and write your server software to check for both.
This seems trivial. What am I missing?
The point of the cookies being HttpOnly is that it makes them completely inaccessible to client side JavaScript, making a whole load of session hijack/XSS attacks impossible.
The request for a bearer token here circumvents this protection because then there’s a way for a client to avoid cookies all together, making the API vulnerable again.
