REST API design: How is it now customary to pass an authorization token?

Question

Layout

Disclaimer: I'm a dumb front-end javascripter and it's mostly not for me to do this. But it's better to ask than not to ask.
Now my colleagues are rewriting authorization in one web application.
There is a restful json api, and a part of the api is provided for use by external consumers (a trusted list and not everyone in a row), that is, cross-domain is needed.
Theoretical customer support: browsers, the oldest being IE11. Such a client exists and works for a long time.
Mobile devices of the latest versions. There is nothing there, only in the plans and the one who could say something about this is also not there.
And we had a small dispute, how to actually transfer authorization tokens?
There are actually three options, in descending order of occurrence.
one). In request url by type. /?auth_token=.
2). Authorization HTTP header
3). Custom HTTP header.
The first option is very common and popular, but I don't quite understand why. The only advantage of this option that I see is the support for all sorts of JSONP crutches, which we don’t seem to need if our target clients are able to cross-domain without it.
The second option is the most attractive to me, for me it looks, for example, more secure in terms of protection from csrf and, for example, the need to control whether something superfluous, for example, third-party pixels, has gone.
I don’t dismiss the third option because I saw it somewhere, but I don’t really understand why the hell.
Actually, the questions are:
1. Where is it considered good practice to pass an authorization token in the current year 2018?
2. What are the advantages of the 1st option that I did not see? Do I understand correctly that it is held by inertia and legacy support considerations in the main?
3. Are there any rakes that will tickle your forehead when implementing the second option?
Well, yes, everyone understands that it’s better not to write bicycles, but *historically established* features of the application require you to cycle somewhere, unfortunately.
Beck is sharp there, but I don’t get into it, so I can’t say more right off the bat. So this is such a trick to see the question more)

Answer 1

Answer 2

codepen.io

Answer 3

The Authorization header is standard. Within it, the authentication scheme is already specified.
Digestis a challenge-response scheme where the server sends a unique nonce value and the browser sends an MD5 hash of the user's password computed using the specified nonce. A more secure alternative to the Basic scheme for insecure connections, but subject to man-in-the-middle attacks (with the scheme replaced by basic). In addition, using this scheme does not allow using modern hash functions to store user passwords on the server.
NTLM(known as Windows authentication) - also based on the challenge-response approach, where the password is not transmitted in its pure form. This scheme is not an HTTP standard, but is supported by most browsers and web servers. Primarily used to authenticate Windows Active Directory users in web applications. Vulnerable to pass-the-hash attacks.
Negotiate is another Windows authentication scheme that allows the client to choose between NTLM and Kerberos authentication. Kerberos is a more secure protocol based on the Single Sign-On principle. However, it can only function if both the client and the server are in the intranet zone and are part of a Windows domain.
https://habrahabr.ru/company/dataart/blog/262817/
It makes sense to create your own heading if none of the methods is suitable.
But as a rule, Basic is more than enough. Instead of a login, we pass an authorization key and an empty password. I agree that it's ugly.

Answer 4

The OAuth 2.0 spec (if you're using it) explicitly states the format:
https://tools.ietf.org/html/rfc6749#section-7.1
I think it's a good idea to follow it.

Answer 5

IMHO the third option is the most convenient. The request body contains only data, while no data is transmitted in the GET part of the request (as in the first option).
+ the third option, compared to simple authorization, allows you to throw anything into the headers (additional parameters - if you suddenly need it)

Answer 6

Always if allowed by customers I use option 2. Minimum steps. Simple and understandable

Answer 7

Your questions in order:
1. It is considered good practice to pass the Authorization http header (all methods known to me: Basic auth, JWT token, Oauth2 assume its use).
2. One of the advantages that I see is the ability to quickly check any results right in the browser, because. when using HTTP header authorization, you need to use some kind of API testing tool. But I would add this only as an alternative authorization option, for example, only on a test server / in a local environment, and not use it in production.
3. I did not meet any rake with the second option, because. this is the default header. I suppose that you can stumble upon a rake with the third option, for example, non-standard headers will be cut by some proxies, caches.