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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
…so allow…either?
What’s so hard about checking two headers (
Authorization:andCookie:) 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.
Then again, cookie auth is vulnerable to CSRF. Pick your poison.
Although CSRF protection just adds a minor inconvenience, while there is never a guarantee your code is XSS vulnerability free.
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.
Can a non-programmer get some explanation?
HttpOnly cookies can’t be read by javascript, so there’s no way to set the bearer token in the Authorization header.
You have a very wild fantasy of what a non-programmer is.
Okay, well have you ever used a dinglehopper?
I’ve smoothed a schleem or two in my time