Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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?
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.
