I'm creating a web api that queues messages and routes webhooks to individual sites. The transactional email service MailGun provides an api key to all users, which is used as the HTTP basic auth password. All accounts use api as the HTTP basic auth username. This results in api:SPECIFIC_API_TOKEN for all accounts.

Is this an acceptable practice, and is there a specific situation where the service I'm building could or shouldn't use this method of authentication?

2 Answers 2


It is used to facilitate the use of Basic Authentication functionality, Basic Auth requires you to send a username too (rfc2617):

The "basic" authentication scheme is based on the model that the client must authenticate itself with a user-ID and a password for each realm.

In MailGun's case, they just use the API token to both identify the user (which is what a username normally does) as well as authenticate that user (password).

They could have used a custom header, but it's probably (or - arguably) easier to use basic authentication to be able to reuse existing functionality with legacy clients.


Having only one username potentially makes it much more easier for someone to gain unauthorized access. Having separate usernames means there is only one valid token per username. If everybody uses the same username, there are multiple tokens that are valid. The unauthorized user only has to guess one of them. I don't suggest doing this especially if the api gives access to any sort of confidential data, or tracks anything related to a specific account.

  • You're assuming that your hypothetical control system with multiple usernames has the same length passwords as the one with only one username. I don't think that's a fair assumption - it would be quite possible for the service provider to decide to only have one username but make all passwords twice as long as they would be otherwise.
    – bdsl
    May 29, 2017 at 18:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .