The short version is that the creators of this API are doing something more secure than what the client wants to do.
A reasonable analogy would be trying to access a building locked by a biometric scanner vs. a guard looking for a piece of paper with a password on it. In the first case, only people entered into the scanner can get in (this is the cookie scenario). In the second case, anyone with a piece of paper with the right password on it will be let in (this is the Bearer token scenario).
More technical version: the API is made more secure because the “HttpOnly” cookie - which, basically, means the cookie’s contents can’t be read with JavaScript in the browser - is used to hold the credentials the server is looking for.
By allowing a third party to access the application, this means you have to allow methods that can be set “client-side” (e.g. via JavaScript in a browser). The most common method is in the “Authorization” HTTP Header - headers are metadata sent along with a request, they include things like the page you’re coming from and cookies associated with the domain. A “Bearer” token is one of the methods specified by the “Authorization” header. It’s usually implemented via passing the authorization credentials prefixed with the word “Bearer” (hence the name) and, often, are static, password-like text.
Basically, because this header has to be settable by a script, that means an attacker/hacker could possibly inject malicious code to steal the tokens because they must, at some point, be accessible.
Ok il attempt again, take in mind though i am no expert in this field either.
An api is a system that allows software to talks to eachother. It does this by sending structural packages back and forth that can be read by software.
Such package usually includes a secure identifier to confirm authorized acces ( like a token) as well as a formal request (show me/edit/remove this specific data)
The api receives the data package, and if the authorization is valid executes the request.
The way I understand it (i am no expert on this ) onlyhttp is a way to provide authorization tokens through a browser cookie (you know those right?), meaning only that browser can have access with that token. The client person never sees the token so its pretty secure in the background.
The bearer token is similar to the one in the browser coockie but the client person needs to enter it inside the package for the api. This can happen from any browser or script by anyone who knows the bearer token. Except Apparantly you cant enter such tokens at all if the api is set to onlyhttp.
Basically it means that the API calls won’t work in a browser and would only realistically work in things like Python scripts.
If API calls are being handled by JavaScript in the browser, they’re going to run into issues, because the HttpOnly flag means the JavaScript code can’t read the auth token.
Things like Python scripts have no such limitations though, so this can be used in cases where you aren’t expecting an actual browser.
the OG “goat” style says the only things that can request the server are those that get their badges from the server (or some place the server trusts) beforehand.
then comes the client that wants to be able to supply their own badges.
Can a non-programmer get some explanation?
The short version is that the creators of this API are doing something more secure than what the client wants to do.
A reasonable analogy would be trying to access a building locked by a biometric scanner vs. a guard looking for a piece of paper with a password on it. In the first case, only people entered into the scanner can get in (this is the cookie scenario). In the second case, anyone with a piece of paper with the right password on it will be let in (this is the Bearer token scenario).
More technical version: the API is made more secure because the “HttpOnly” cookie - which, basically, means the cookie’s contents can’t be read with JavaScript in the browser - is used to hold the credentials the server is looking for.
By allowing a third party to access the application, this means you have to allow methods that can be set “client-side” (e.g. via JavaScript in a browser). The most common method is in the “Authorization” HTTP Header - headers are metadata sent along with a request, they include things like the page you’re coming from and cookies associated with the domain. A “Bearer” token is one of the methods specified by the “Authorization” header. It’s usually implemented via passing the authorization credentials prefixed with the word “Bearer” (hence the name) and, often, are static, password-like text.
Basically, because this header has to be settable by a script, that means an attacker/hacker could possibly inject malicious code to steal the tokens because they must, at some point, be accessible.
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
An API lets different software talk to each other. HttpOnly uses secure tokens (think password) that a server uses to confirm identity.
Bearer tokens also confirm identity but the added security provided by HttpOnly does not allow passing such within the api information.
They asked for ELI5 and you gave them ELI CS undergrad
To be completely fair to the attempt, there is a reason we have decent incomes.
Ok il attempt again, take in mind though i am no expert in this field either.
An api is a system that allows software to talks to eachother. It does this by sending structural packages back and forth that can be read by software.
Such package usually includes a secure identifier to confirm authorized acces ( like a token) as well as a formal request (show me/edit/remove this specific data)
The api receives the data package, and if the authorization is valid executes the request.
The way I understand it (i am no expert on this ) onlyhttp is a way to provide authorization tokens through a browser cookie (you know those right?), meaning only that browser can have access with that token. The client person never sees the token so its pretty secure in the background.
The bearer token is similar to the one in the browser coockie but the client person needs to enter it inside the package for the api. This can happen from any browser or script by anyone who knows the bearer token. Except Apparantly you cant enter such tokens at all if the api is set to onlyhttp.
Basically it means that the API calls won’t work in a browser and would only realistically work in things like Python scripts.
If API calls are being handled by JavaScript in the browser, they’re going to run into issues, because the HttpOnly flag means the JavaScript code can’t read the auth token.
Things like Python scripts have no such limitations though, so this can be used in cases where you aren’t expecting an actual browser.
it’s a security style.
the OG “goat” style says the only things that can request the server are those that get their badges from the server (or some place the server trusts) beforehand.
then comes the client that wants to be able to supply their own badges.