Basic Authorization in header vs Username and password in body

Question

I am facing two different situations. First method i can send username and password in body as model. Second method is to use basic auth in Header. Both methods are working fine. Both methods are used only for first call just to authenticate, and the api returns a jwt token.

First Method:

curl -X 'POST' \
  'https://localhost:7122/api/Authentication/token' \
  -H 'accept: text/plain' \
  -H 'Content-Type: application/json' \
  -d '{
  "userName": "test",
  "password": "test"
}'

Second Method:

curl -L -X POST 'https://localhost:7122/api/Authentication/token' \
 -H 'Content-Type: application/x-www-form-urlencoded' \
 -H 'Authorization: Basic ZzI0N2NmbnlwYzV3cmszaHAwZnU2cTk3N2YzZzYxY2hnODV1NzJzZmJkb3c3LmFwcHMudml2YXBheW1lbnRzLmNvbTowYk9xOHRkMzhMQVF4b3ptaWVqUDYwUzdzQnJkVkQ=' \
 --data-urlencode 'grant_type=client_credentials'

Are they rules for what should i use in jwt token? What is good practice to use?

Answer 1

Just to ensure everyone's on the same page let me outline a typical JWT-authentication workflow here:

1. User calls an anonymous POST API (no authorization required), with a username and password. API then returns a JWT. That's your Login API at line 3.

2. All other API calls require authorization, and so the client sends that as Bearer [JWT] . The server then determines if the token is valid and if not returns 401.

As I understand the question, you're asking whether, for (1), it's better to send the u/p through the authorization header using the Basic Authentication protocol (base64 etc) or to just post it in plaintext in the body of the login request.

There are two drawbacks I can see with using the auth header-

• Sometimes headers are logged along the way while request bodies rarely are. Grant you, I think it would be unusual (if not unforgivable) for a system to be logging auth headers, but it's possible. The base64 encoding of course provides no security.
• I have had difficulty in the past with basic auth headers actually going through. I'll just refer you to this thread which explores some of the possible pitfalls.

Other than the possibe logging issue, I can't think of any inherent issues with using one vs. other though. FWIW, I see APIs all the time that use the plaintext body approach while I've never seen an API that has you log in using basic auth and then returns a JWT.

Hopefully it goes without saying that you MUST ensure your APIs are only accessible through HTTPS. Otherwise you're hosed no matter where you put the password.

That said, if you're designing this from scratch and have access to both ends of the system and they will always be in sync, I'd consider sending a hashed password, regardless whether you use the auth header or POST body. As long as your client and server agree on the hashing method and iteration count, that significantly lowers the impact of that data possibly leaking or being logged somewhere. This would require a little homegrown security work though.

As for your other question,

Are they rules for what should i use in jwt token? What is good practice to use?

Rules? No. Conventions, definitely. Ultimately it's whatever information the application needs to be able to trust the user and give them access. These will be in the form of "claims". There's lots of literature on this but the definitive authority would be the RFC .