Why is 'Bearer' required before the token in 'Authorization' header in a HTTP request?
What exactly is the difference between following two headers:
Authorization : Bearer cn389ncoiwuencr vs Authorization : cn389ncoiwuencr
All the sources which I have gone through, sets the value of 'Authorization' header as 'Bearer' followed by the actual token. However, I have not been able to understand the significance of it. What if I simply put the token in the Authorization header?
The question is specifically about Token based authentication, which is usually done after basic authentication so that user doesn't have to provide the username and password with each request.
I had a similar question as well. I wanted to choose a scheme for a short lived token implementation, which is not fully Oauth 2.0 compliant. I was wondering if i could use Bearer or any non-standard value without getting in trouble with proxies' and servers' interpretation. The closest i came to finding an answer was : http://stackoverflow.com/questions/7802116/custom-http-authorization-header and http://stackoverflow.com/questions/8463809/customize-the-authorization-http-header
Do servers generally return a token via the same route i.e. "Authorization: Bearer" of the HTTP response? Or is it nearly always part of the response body?
With all that encoding you would think the scheme (Bearer) could be baked into the token?
Authorization: <type> <credentials>pattern was introduced by the W3C in HTTP 1.0, and has been reused in many places since. Many web servers support multiple methods of authorization. In those cases sending just the token isn't sufficient.
Sites that use the
Authorization : Bearer cn389ncoiwuencr
format are most likely implementing OAuth 2.0 bearer tokens.The OAuth 2.0 Authorization Framework sets a number of other requirements to keep authorization secure, for instance requiring the use of HTTPS/TLS.
If you're integrating with a service that is using OAuth 2.0 it is a good idea to get familiar with the framework so that the flow you're using is implemented correctly, and avoiding unnecessary vulnerabilities. There are a number of good tutorials available online.
Thats what i was thinking. Given your knowledge of Bearer Tokens and tokens in general, can you see any security implications by the fact that the API accepts the token without the Bearer keyword?
Not really, but I agree with one comment in that question - if their implementation differs on this point, what else is different? That being said there are a number of OAuth-like implementations out there that deviate from the RFCs. It does not automatically mean that their implementations are less secure, though.
Long before bearer authorization, this header was used for Basic authentication. For interoperability, the use of these headers is governed by W3C norms, so even if you're reading and writing the header, you should follow them. Bearer distinguishes the type of Authorization you're using, so it's important.
A Bearer Token is set in the Authorization header of every Inline Action HTTP Request and Bearer itself determines the type of authentication.