Basic HTTP and Bearer Token Authentication

Question

I am currently developing a REST-API which is HTTP-Basic protected for the development environment. As the real authentication is done via a token, I'm still trying to figure out, how to send two authorization headers.

I have tried this one:

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Authorization: Bearer mytoken123"

I could for example disable the HTTP-Authentication for my IP but as I usually work in different environments with dynamic IPs, this is not a good solution. So am I missing something?

Answer 1

You can use Body with x-www-form-url-encoded to send with multiple headers.

curl --location --request POST 'http://dev.myapp.com/api/users' \
--header 'Authorization: Basic Ym9zY236Ym9zY28=' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'access_token=mytoken123'

Answer 2

With nginx you can send both tokens like this (even though it's against the standard):

Authorization: Basic basic-token,Bearer bearer-token

This works as long as the basic token is first - nginx successfully forwards it to the application server.

And then you need to make sure your application can properly extract the Bearer from the above string.

Answer 3

There is another solution for testing APIs on development server.

• Set HTTP Basic Authentication only for web routes
• Leave all API routes free from authentication

Web server configuration for nginx and Laravel would be like this:

location /api {
    try_files $uri $uri/ /index.php?$query_string;
}

location / {
    try_files $uri $uri/ /index.php?$query_string;
    
    auth_basic "Enter password";
    auth_basic_user_file /path/to/.htpasswd;
}

Authorization: Bearer will do the job of defending the development server against web crawlers and other unwanted visitors.

Answer 4

Standard (https://www.rfc-editor.org/rfc/rfc6750) says you can use:

• Form-Encoded Body Parameter: Authorization: Bearer mytoken123
• URI Query Parameter: access_token=mytoken123

So it's possible to pass many Bearer Token with URI, but doing this is discouraged (see section 5 in the standard).

Answer 5

Try this one to push basic authentication at url:

curl -i http://username:password@dev.myapp.com/api/users -H "Authorization: Bearer mytoken123"
               ^^^^^^^^^^^^^^^^^^

If above one doesn't work, then you have nothing to do with it. So try the following alternates.

You can pass the token under another name. Because you are handling the authorization from your Application. So you can easily use this flexibility for this special purpose.

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Application-Authorization: mytoken123"

Notice I have changed the header into Application-Authorization. So from your application catch the token under that header and process what you need to do.

Another thing you can do is, to pass the token through the POST parameters and grab the parameter's value from the Server side. For example passing token with curl post parameter:

-d "auth-token=mytoken123"

Answer 6

I had a similar problem - authenticate device and user at device. I used a Cookie header alongside an Authorization: Bearer... header. One header authenticated the device, the other authenticated the user. I used a Cookie header because these are commonly used for authentication.

---

You can only have one Authorization header. I used this to send a bearer token, which is a large random nonce provided from the server to the client to authenticate the client - the device. These are stored in a database, and if a device presents the nonce, we know we've authorized that device before.

We cared about users at the device as well as devices, so every user account also had a nonce. When the user authenticated on the device, this then was supplied to the device which also stored it and presented it on each request, in this case as a Cookie header, since Cookie headers often: 1) contain nonces and 2) are used for authentication.

It's been more than 6 years since I wrote the original answer. The nonces might have been bearer tokens instead which delivered a symmetrically encrypted payload from the server to itself to avoid using a database. Done properly they have at least a user identifier and an expiration. They then can't be revoked before they expire without using a database again, but if revocation is infrequent this could still be a smaller/faster lookup.

Hopefully this brief tutorial on authentication tokens helps those who are confused about what kinds of things can be set in the headers to authenticate a request from a device or a user.

---

It frankly doesn't matter "what I send as a cookie", or in other words, which technique I used for authentication. The useful part of the answer is the choice of headers informed by their semantic meaning and common use.

Answer 7

The real answer is

1. You can not use two headers with the same name (with a single exception for Set-Cookie).
2. Bearer token is an authorization scheme, while Basic is an authentication scheme.

Thus, you have an error in your question to begin with, and a problem in your application logic flow.

• If you want to authenticate client as specific user, use Basic authentication scheme in request, in which case authorization token is useless (user proved himself with a matching secret).
• If all you want is to ensure client is authorized to perform certain action, use bearer token authorization without authentication (user provides a secret only authorized person should know, and you trust it without additional verification).

You do not, and often may not, know both username/password and bearer token at client side. In most common workflow, you perform authentication once, receive bearer token and use it in all following requests. Additionally, token could have an expiration time, which application should indicate with each response as a basic courtesy.

In most simple terms, Bearer token authorization is a special case of your old, trusty session cookie.

Answer 8

If you are using a reverse proxy such as nginx in between, you could define a custom token, such as X-API-Token.

In nginx you would rewrite it for the upstream proxy (your rest api) to be just auth:

proxy_set_header Authorization $http_x_api_token;

... while nginx can use the original Authorization header to check HTTP AUth.

Answer 9

curl --anyauth

Tells curl to figure out authentication method by itself, and use the most secure one the remote site claims to support. This is done by first doing a request and checking the response- headers, thus possibly inducing an extra network round-trip. This is used instead of setting a specific authentication method, which you can do with --basic, --digest, --ntlm, and --negotiate.