Search code examples
authenticationsecuritydjango-rest-frameworksingle-page-applicationbearer-token

Is basic Token authentication appropriate for a Web Application?


Lets say we build an API for a single-page web application. The API will provide routes for registration, login, and so on. It also provides protected routes that only a authenticated user can access.

As well as for the web application, we also want to make the protected routes available as an restricted API Service. Authenticated users can then generate their own Token and access our routes via their own clients/scripts by passing their Token in the request header. For that, we cannot use Session authentication or JWT authentication, since we need non-refreshing, non-expiring Tokens.

Is it appropriate to use a basic, non-refreshing, non-expiring Token authentification system across our whole API? That would include all user-related registration/login routes.

I am working with the Django Rest Framework, and in the documentation about basic Token Authentication it says:

Token authentication is appropriate for client-server setups, such as native desktop and mobile clients.

The documentation does not state its inappropriate and I could not find any resources on Basic Token authentification for web applications, every article on Token auth is about JWT.


Solution

  • Basic Authentication is considered to be a poor man solution inferior to all other solutions like HTTP Session or JWT tokens because of many reasons:

    1. It sends user credentials which have usually low entropy as compared to session IDs or JWT tokens.
    2. They always stay the same. Once they leak, even if they are discovered by the attacker a month after, they leave an open door behind.
    3. They reveal the information about the users credentials which may have been reused elsewhere.
    4. If the Basic Auth token is managed by the browser, how do you make it log out from the page?

    For me personally Basic Auth is only acceptable in machine-to-machine or service-to-service communication. Never client-to-service.