Which is more better between basic auth and token auth as security perspective

Question

I am currently developing a RESTful API server, and I am choosing between using ID and password or using a token to authenticate a user.

Let me, explain my situation first. I need to include static authentication information to my library to communicate between a client and my server or provide it to a partnership company to communicate between their server and my server. And when I was researching other services which are in a similar situation as us, they are using token now (for example, Bugfender is using a token to specify a user).

However, what I think is that using ID and PW and using the token are the same or using ID and PW is better because there are two factors to compare it is correct or incorrect.

Is there any reason why other services are using a token ?

Which one is better as a security perspective or is there a better way to do this?

Answer 1

I think, if you are going go use on your client fixed username/password, or some fixed token, then the level of the security is the same.

Username and password is not considered as multi-factor authentication. Multi factor means that you are authenticating someone by more than one of the factors:

• What you know. This can be the combination of username and password, or some special token.
• What you have. Might be some hardware that generates an additional one time password - Google authenticator app on your telephone, or SMS with OTP received with some time expiration.
• What you are. This is for example your fingerprint or retina of the eye.
• Where you are. This can be the IP address of the origin if it is applicable for your setup.
• How you behave. What is your normal way of using the service.

etc.

Maybe not needed to mention that both - the token and the username/password combination have to be carried in an encrypted requests (I believe you are using HTTPS). Otherwise the client's identity can be stolen.

How are you going to provide the credentials to your client library? I thnk this is the most tricky part. If those credentials are saved as a configuration (or worse hard coded) on their server, is that storage secure enough? Who is going to have access to it. Can you avoid it?

What would happen if your partner company realize that the username/password is compromised? Can they change it easily themselves? Or how fast you can revoke the permissions of stolen credentials?

My advice is also to keep audit logs on your server, recording the activity of the client requests. Remember also the GDPR if you work with Europe servers, check for similar regulations in your country based on what you are going to audit log.

Answer 2

In case the credentials (ID and password) and the token are being transferred the same way (say: by a header in a REST request) over a TLS secured channel, the only difference lies in the entropy of the password VS entropy of the token. Since it is something for you to decide in both cases, there is no real difference from the security perspective.

NOTE: I don't count the ID as a secret, as it usually is something far easier to guess than a secret should be.

I'd go for a solution that is easier to implement and manage.

IMHO this would be HTTP basic authentication, as you usually get full support from your framework/web server with little danger of making security mistakes in authentication logic. You know, friends don't let friends write their own auth. ;)