I have a question related to Authorization when creating API. I often see people using Bearer Token, OAuth 2.0 to authenticate an accessToken is valid or not.

So which difference if I use headers with a param is accessToken and stored accessToken value.

In server side, I also get token from Authorization or token from Headers.

I do not actually know which difference between them.

Example: In js, I send request by two ways with accessToken value:

headers.Authorization = 'Bearer '   cookie.get('accessToken')

headers.accessToken = cookie.get('accessToken')

Can everyone explains me?

CodePudding user response：

To respond to the question "why we should follow standard RFC when arbitrary parameters works too?" applied to the "Authorization" header specifically.

The easy answer is: to avoid rethinking what has already been though of extensively.

The complicated answer is:

• To avoid collision, if everyone was using arbitrary header parameters, they are bound to collide at some point and break things.

• To make it easier to use, if there is no standard, someone using Authorization with "Bearer" access token might use a "bearer" without the capital "B" or whithout leaving the space between "Bearer" and the access token or just doesnt put the "Bearer" altogether . If i want to use that person's package, I would have to do a "try and fail" sequence to understand how it works or worse, read his code. Same thing if he uses the header "authorisation" without the proper format or the right syntax.

  Some servers even block non standard headers altogether, and even block non standard format in known headers. Like if you want to send a whole file base64 encoded in the "Authorization" header, the server will block it since any documented use of it should never exceed a specific size (even if the size limit itself is not documented but deduced).

• Good practice: The internet is what it is now because of standards. standards of different protocols, their usage and their limits. If there were no standards followed, we will end up with "pocket" sub-internets everywhere.

It is not required to follow RFCs exactly, but considering them is highly recommended. Considering RFCs will lead to better technical decisions. While programming is primarily an individual act, building software is a social exercise and standards help facilitating decisions between groups.

Imagine someday you decide to make your code a package to be used in any project. Following standards will make it easy for other developers to implement your package into their systems. For example, if your package handles JWT token in the frontend, another package that consume the JWT in the backend will have no issue doing so, since it knows that it will be in the "Authorization" header, in the format of "Bearer [TOKEN]" using a Base64 encoded double json object followed by the signature hash that..... You get the point.

Disclamer: this is a rushed (slightly opinionated) answer and in no way a complete one. dont hesitate to edit it if you see the need to.