Аутентификация сервера что это

Сервер аутентификации

Сервер аутентификации (англ. Authentication Server) – это программный или программно-аппаратный комплекс, реализующий различные методы аутентификации для различных приложений. Сервер аутентификации обладает огромной функциональностью, включая поддержку различных методов и каналов аутентификации. Такие возможности позволят организациям гибко производить его настройки в соответствии со своими требованиями. В качестве примера можно рассмотреть использование различных методов аутентификации и подтверждения транзакций для различных групп клиентов, которые определяются в соответствии со степенями риска при выполнении операций в системе «Банк-Клиент». Другой пример использования сервера аутентификации — удаленный доступ к корпоративным ресурсам, который компания дает своим пользователям или партнерам.

На современном рынке информационной безопасности представлено большое количество серверов аутентификации, которые обеспечивают теми или иными функциями. Однако на какие особенности прежде всего следует обращать внимание при выборе продукта такого класса.

Ключевые особенности

• Поддержка различных моделей и типов генераторов одноразовых паролей
• Интеграция с сервисами
• Поддержка различных каналов аутентификации, методов аутентификации
• Безопасный доступ к серверу аутентификации
• Поддержка HSM-модулей
• Поддержка протокола RADIUS
• Поддержка стандартов OAuth 2.0, SAML 2.0

Использование многофакторной аутентификации непременно снижает риски компрометации аутентификационных данных клиента. Применение одноразовых паролей (One-Time Password; OTP) в качестве одного из факторов в разы уменьшает риск несанкционированного доступа к системе. Ключевой особенностью ОТР является их однократное использование в процессе выполнения каждой операции (аутентификация, подтверждение транзакции…). Таким образом, знание одноразового пароля не предоставляет злоумышленнику дополнительной информации о данных пользователя. Для получения ОТР используются программные или аппаратные генераторы. Примером программного генератора может служить генерация пароля сервером аутентификации или мобильным приложением, а аппаратного – генерация ОТР посредством отчуждаемого носителя (аутентификатора). Разумеется, использование аппаратных генераторов является более безопасным методом. Поэтому сервер аутентификации должен обладать необходимыми функциями поддержки различных ОТР-генераторов, включая различные типы банковских карт с поддержкой стандарта OATH (TOTP, HOTP, OCRA) или EMV, сертифицированных по стандарту VISA и MasterCard в качестве платежных банковских карт.

Пример: банки обеспечивают клиентов платежными картами. Таким образом, для определенной категории клиентов использование одной банковской карты было бы удобным вариантом как для осуществления платежных операций, так и для работы с системой «Банк-Клиент». Дополнительно к этому, банку удалось бы обеспечить клиента максимально удобным и безопасным решением и избежать расходов на дополнительные аутентификаторы.

С увеличением спроса на дистанционное обслуживание появляются и новые сервисы, разрабатываемые организациями для своих клиентов. Возможность сервера аутентификации интегрироваться с различными типами систем и приложений позволит реализовать доступ к этим сервисам по различным каналам аутентификации. Каналы аутентификации могут использоваться для разграничения доступа клиентов к сервисам в зависимости от типа производимых операций, выполняемых ими действий, либо в качестве дополнительного канала, используемого с целью повышения уровня безопасности для доступа к какому-то определенному сервису. Примеры каналов аутентификации: web, мобильный клиент, корпоративный «толстый» клиент, 3D Secure, IVR.

Для доступа к различным сервисам могут использоваться один или несколько аутентификаторов. Поэтому наряду с поддержкой различных каналов аутентификации, сервер должен обеспечивать и различными методами, на основе которых могут использоваться следующие типы аутентификаторов: PKI-токены (X.509), матричные карты, SMS-сообщения, аппаратные и программные генераторы одноразовых паролей. Такая функциональность позволит организациям не ограничиваться одним методом аутентификации для разрешения доступа клиента к различным сервисам, а, наоборот, обеспечит его максимально удобным и безопасным способом работы с системой в рамках единого комплексного решения. К тому же клиенты могут использовать дополнительные аутентификаторы для подключения к новым сервисам или же использовать несколько устройств сразу в зависимости от уровня риска и решаемых задач.

Говоря об аутентификации клиентов в различных системах и сервисах, необходимо обращать внимание и на безопасный доступ к самому серверу аутентификации. Имеет ли смысл использовать решение по безопасности, не позволяющее реализовать собственную защиту? Очевидно, нет. Доступ к интерфейсу (консоли) управления сервером аутентификации получают специально уполномоченные лица – администраторы, менеджеры, операторы и пр. Они могут конфигурировать сервер, создавать пользователей, назначить им роли. Для входа в консоль управления необходимо предоставлять одновременный доступ нескольким уполномоченным лицам. Разграничение прав доступа таким образом позволит предоставить только необходимые полномочия выше указанным лицам и избежать полного доступа одним сотрудником, тем самым, уменьшая риск НСД и принятия важных решений одним лицом. А использование при аутентификации смарт-карт и PIN-кодов позволит дополнительно увеличить уровень безопасности системы.

Сервер аутентификации выполняет различные криптографические операции и хранит различные данные аутентификации. Чтобы достичь максимального уровня защищенности этих процессов, необходима поддержка аппаратных модулей безопасности (Hardware Security Module; HSM). К сожалению, не каждый сервер поддерживает эти модули. Поэтому при выборе сервера аутентификации в зависимости от требуемого уровня защищенности необходимо рассматривать то решение, которое поддерживает различные HSM (Thales nShield, SafeNet, Utimaco, функционирующих в режиме FIPS).

Ключевым процессом является построение отношений между организацией и клиентом как напрямую, так и через Интернет. Однако не стоит упускать из виду, что у организаций есть целый штат сотрудников, часть которых может работать удаленно. В этом случае важным требованием к серверу аутентификации является поддержка протокола RADIUS для реализации безопасного удаленного доступа для сотрудников или при администрировании сетевого оборудования.

Поддержка протокола SAML 2.0 позволяет быстро подключать веб-ресурсы, которые могут работать в режиме SAML Service Provider. Для аутентификации мобильных приложений более удобным является использование стандатра OAuth 2.0.

Требования аутентификации и авторизации API

Прежде чем пользователи смогут отправлять запросы с помощью API, им обычно необходимо зарегистрироваться для получения ключа API или изучить другие способы аутентификации запросов. API-интерфейсы различаются по способу аутентификации пользователей. Некоторые API требуют включения ключа API в заголовок запроса, в то время как другие API требуют тщательной защиты из-за необходимости защиты конфиденциальных данных, подтверждения личности и обеспечения того, чтобы запросы не были подделаны. В этом разделе мы изучим аутентификацию и авторизацию, а также то, на чем следует сосредоточиться в документации.

Определяем термины

Во-первых, давайте определимся с некоторыми ключевыми терминами:

• Аутентификация: подтверждение правильности личности
• Авторизация: разрешение определенного действия

API может аутентифицировать, но не разрешит делать определенный запрос.

аутентификация и авторизация

Последствия нехватки безопасности API

Почему даже API-интерфейсы нуждаются в аутентификации? Для API, которые предназначены только для чтения, иногда пользователям не нужны ключи. Но большинство коммерческих API требуют авторизации в виде ключей API или других методов. Если нет никакой защиты API, пользователи могут совершать неограниченное количество запросов API без какой-либо регистрации. Разрешение неограниченных запросов усложнит модель дохода для вашего API.

Вдобавок, без аутентификации не было бы простого способа связать запросы с конкретными данными пользователя. И не было бы способа защиты от запросов от злонамеренных пользователей, которые могут удалить данные другого пользователя (например, путем удаления запросов DELETE для учетной записи другого пользователя).

Наконец, не получится отследить, кто использует API или какие конечные точки используются чаще всего. Очевидно, что разработчики API должны подумать о способах аутентификации и авторизации запросов к своим API.

В целом, аутентификация и авторизация с помощью API служат следующим целям:

• аутентификация запросов в API только для зарегистрированных пользователей;
• отслеживание, кто делает запросы;
• отслеживание использования API;
• блокировка или замедление пользователя, превышающего ограничения скорости;
• применение разных уровней разрешений для разных пользователей.

Разные виды авторизации

Существует несколько методов авторизации. Ниже рассмотрим несколько вариантов авторизации, которые встречаются чаще всего:

API ключ

Большинство API требуют авторизации ключом API, чтобы использовать API. Ключ API представляет собой длинную строку, которую обычно включают либо в URL запроса, либо в заголовок запроса. Ключ API в основном служит способом идентификации лица, выполняющего запрос API (аутентифицируя для использования API). Ключ API также может быть связан с конкретным приложением, которое регистрируется.

Ключи APK используют строку в свойстве заголовка для авторизации запросов

API могут дать как открытый, так и закрытый ключ. Открытый ключ обычно включается в запрос, в то время как закрытый ключ рассматривается скорее как пароль и используется только при обмене данными между серверами. На некоторых сайтах документации API, при заходе на сайт, ключ API автоматически заполняется в примере кода и API Explorer.

Basic Auth

Другой тип авторизации называется Basic Auth. С помощью этого метода отправитель помещает пару имя пользователя:пароль в заголовок запроса. Имя пользователя и пароль кодируются с помощью Base64, который представляет собой метод кодирования, который преобразует имя пользователя и пароль в набор из 64 символов для обеспечения безопасной передачи. Вот пример Basic Auth в заголовке запроса:

API, использующие Basic Auth, также будут использовать HTTPS, что означает, что содержимое сообщения будет зашифровано в транспортном протоколе HTTP. (Без HTTPS людям было бы легко расшифровать зашифрованные данные)

Когда сервер API получает сообщение, он дешифрует сообщение и проверяет заголовок. После декодирования строки и анализа имени пользователя и пароля он решает, принять или отклонить запрос.

В Postman можно настроить базовую авторизацию, щелкнув вкладку Authorization, выбрав Basic Auth в раскрывающемся списке и введя имя пользователя и пароль справа от двоеточия в каждой строке. На вкладке Заголовки будет показана пара ключ-значение, выглядящая следующим образом:

Postman обрабатывает кодировку Base64 автоматически, при вводе имени пользователя и пароля с выбранным Basic Auth.

HMAC (код авторизации сообщений на основе хэша)

HMAC расшифровывается как Hash-based message authorization code — код авторизации сообщений на основе хэша и является более строгим типом аутентификации, более распространенным в финансовых API. В HMAC только отправитель, и получатель знают секретный ключ, который больше неизвестен никому. Отправитель создает сообщение на основе некоторых системных свойств (например, отметка времени запроса плюс идентификатор учетной записи).

Затем сообщение кодируется секретным ключом и проходит через алгоритм безопасного хеширования (SHA — secure hashing algorithm). (Хеш — это зашифрованная строка на основе алгоритма.) Результирующее значение, называемое сигнатурой, помещается в заголовок запроса.

Сервер API (получатель), получая запрос, принимает те же системные свойства (отметка времени запроса плюс идентификатор учетной записи) и использует секретный ключ (который известен только запрашивающей стороне и серверу API) и SHA для генерации одной и той же строки. Если строка соответствует подписи в заголовке запроса, запрос принимается. Если строки не совпадают, запрос отклоняется.

Вот диаграмма, отображающая процесс авторизации HMAC:

Важным моментом является то, что секретный ключ (критический для восстановления хэша) известен только отправителю и получателю. Секретный ключ не включается в запрос. Безопасность HMAC используется, когда нужно убедиться, что запрос является подлинным и не может быть подделан.

OAuth 2.0

Одним из популярных методов аутентификации и авторизации пользователей является OAuth 2.0. Такой подход опирается на сервер аутентификации для связи с сервером API для предоставления доступа. Понять, что используется метод OAuth 2.0, можно когда предлагается войти в систему при помощи сторонних сервисов, как Twitter, Google или Facebook.

окно входа в систему, использующую Oauth2.0

Существует несколько разновидностей OAuth, а именно «one-legged OAuth» и «three-legged OAuth». One-legged OAuth используется, когда нет конфиденциальных данных для защиты. Например, в том случае, если просто получаем общую информацию только для чтения.

Three-legged OAuth используется, когда нужно защитить конфиденциальные данные. В этом сценарии взаимодействуют три группы:

• сервер аутентификации;
• сервер API;
• пользователь или приложение.

Вот базовый процесс Oauth2.0:

Сначала пользовательское приложение отправляет ключ приложения и секретные данные на страницу входа в систему на сервере аутентификации. Если аутентификация пройдена, сервер аутентификации возвращает пользователю токен доступа (авторизации).

Токен доступа (авторизации) упакован в параметр запроса в перенаправлении ответа (302) на запрос. Перенаправление направляет запрос пользователя обратно на сервер ресурсов (сервер API).

Затем пользователь отправляет запрос на сервер ресурсов (сервер API). Токен доступа (авторизации) добавляется в заголовок запроса API со словом Bearer , за которым следует строка токена. Сервер API проверяет токен доступа (авторизации) в запросе пользователя и решает, аутентифицировать ли пользователя.

Токены доступа (авторизации) не только обеспечивают аутентификацию для запрашивающей стороны, но и определяют права пользователя на использование API. Кроме того, токены доступа (авторизации) обычно истекают через некоторое время и требуют от пользователя повторного входа в систему. Для получения дополнительной информации об OAuth 2.0 можно посмотреть ресурсы:

, Питера Грюнбаума; , Аарона Парецки.

Что документируется в разделе аутентификации

В документации API не нужно подробно объяснять внешним пользователям, как работает аутентификация. Отсутствие объяснений внутренних процессов аутентификации, является лучшей практикой, поскольку хакерам будет сложнее злоупотреблять API.

Тем не менее нужно объяснить необходимую информацию:

• как получить API ключ;
• как пройти аутентификацию запроса;
• сообщения об ошибках, связанных с неверной аутентификацией;
• чувствительность информации аутентификации;
• период действия токена доступа (авторизации).

Если есть открытый и закрытый ключи, нужно объяснить, где следует использовать каждый ключ, и отметить, что закрытые ключи не должны использоваться совместно. Если разные уровни лицензий предоставляют разный доступ к вызовам API, эти уровни лицензирования должны быть явно указаны в разделе авторизации или в другом месте.

Поскольку раздел API ключей важен, и нужен разработчикам до того, как они начнут использовать API, этот раздел должен быть в начале руководства.

Образцы разделов авторизации

Ниже приведены несколько примеров разделов авторизации в документации API.

SendGrid

API ключ SendGrid

SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.

Twitter

авторизация Twitter

В Twitter подробный пример оправдан и предоставлен, поскольку требования к авторизации OAuth 2.0 немного сложнее.

Amazon Web Services

авторизация Amazon

Amazon использует HMAC. Процесс достаточно сложный, чтобы включить полноценную диаграмму, показать шаги, которые должны выполнить пользователи.

Dropbox

Авторизация в Dropbox

Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.

��‍�� Практическое занятие: Авторизация

В своем найденном опен-сорс проекте найдем информацию об авторизации для запросов к API. Ответьте на следующие вопросы:

What is an Authentication Server

An authentication server is used to verify credentials when a person or another server needs to prove who they are to an application.

To better understand what an authentication server is, let's look at what it does by taking a peek into what happens when an authentication request is made.

Day in the Life of an Authentication Server

Authentication, in short, is the process of identifying a person or computer to make sure they are who they say they are.

An application or device may ask for several different identifiers to verify this. Each identifier generally falls in one of these three categories:

Something you know — Usually something like a username and password or PIN. It is the most common identification method.

Something you have — This covers physical things that you possess, such as a smartphone, key, etc.

Something you are — This category involves verifying through biometric methods, such as a fingerprint or retinal scan.

There are several different types of authentication, but for brevity, we'll go through what happens in two scenarios: single-factor authentication and multi-factor authentication.

Single-factor authentication

Single-factor authentication is the process of verifying an identity using only one factor. The different factors generally fall into one of the categories above: something you know, something you have, or something you are. The most common form of single-factor authentication is simply a username and password.

Let's look at what happens when a user authenticates with a username and password.

User:Navigates to a website and types in username and password

Authentication Server:

Whoa, what's this? Who are you??

Authentication Server:puts on glasses

Authentication Server:

Ahh yes, bobbysmith3. Let me verify that your secret password is correct. ��

User:Waiting

Authentication Server:

I have run my checks, and I can confirm you are indeed bobbysmith3! Welcome!

In this scenario, what was the authentication server checking for when the user entered their username and password? Here's the more in depth flow about what happened behind the scenes while the user was waiting to be authenticated:

• The username and hashed password are sent to the server.
• The server accesses its database of users that holds the username and hashed/salted password.
• It checks the provided username and hashed password against the one in the database.
• If the credentials match, the user's identity is verified, and the application decides what's next.
• If not, a generic error message is returned.

Note: The error message should not reveal too much information about why the request failed. For example, messages such as "This username does not exist" can also be used by an attacker to determine if a username does exist, as they would get a different error message if they try a valid username.

While this may seem like a foolproof method of verifying a user's identity, there's a lot left to be desired. What happens if someone figures out your password?

Over the years, there has been a huge increase in the number of credential stuffing attacks. When a data breach occurs, and usernames/passwords are leaked, they're compiled into huge lists that attackers can use to try to sign into several different websites. Since password reuse is so common, there's a decent chance that some of the usernames and passwords leaked from one application may be valid for another.

Tweet This

This is where multi-factor authentication comes into play. Unlike single-factor, which relies on just one form of identification, multi-factor authentication requires more than one identifier to verify a user.

Multi-factor authentication

Let's look at what happens when an authentication request is made using two identification factors.

User:Navigates to a website and types in username and password

Authentication Server:

Ahh, it's you again, bobbysmith3! Let me check that your password matches the one I have on file.

Authentication Server:

Well, it checks out. But I'm still skeptical. I'm sending a code to the phone number I have on file. Please type in the code once you receive it.

User's phone:DING!

User:Receives a text message and types in the code

Authentication Server:

The code matches! Since you have bobbysmith3's password and phone on hand, I'm confident that you are indeed bobbysmith3! Welcome!

One of the most common forms of multi-factor authentication is a username and password combined with something sent to a device or account you own.

For example, you have probably signed into an application with your username and password, and then received a text message or email with a code that you have to provide back to the application to be authenticated. This code is called a one-time password (OTP).

The process for authenticating a user with username/password and an OTP is the same as above, but there's an additional step — the authentication server must send the OTP to the user's registered device and verify that the code is correct.

To do this, the authentication server must perform the following actions:

• Generate the OTP.
• Send it to the application where the user is attempting to sign in.
• Once the application sends the OTP back that the user submitted, verify that it's correct.
• If so, the user is authenticated.
• If not, return an error and allow them to regenerate another OTP. To prevent brute force attacks, there should be a limit to how many times a new OTP can be requested before the user is blocked.

With this additional requirement, an attacker's attempt to fake their identity is greatly stunted! Let's revisit the question that was posed with single-factor username/password authentication.

What happens if someone figures out your password?

In this case, simply having someone's password isn't enough. The attacker must also gain access to the real user's OTP to verify the identity.

As you can see, multi-factor authentication greatly reduces the chances of an attacker impersonating a user.

What an Authentication Server Doesn't Do

An authentication server does a lot of work in the background, but it's also important to understand what it's not responsible for doing.

Authentication vs. authorization

In the examples so far, the authentication server has taken steps to verify a user's identity and return it to the requesting application. What happens next is up to the application.

Once the application knows who the user is, it usually has to decide what the user can access. This is known as authorization.

Authorization — Authorization refers to the process of verifying what a user has access to.

Authentication — Authentication refers to the process of confirming identity.

It's easy to confuse authentication and authorization, but it's important to understand the difference. The authentication process does not determine what a user can access.

Tweet This

The authentication server simply verifies the identity of the user and then passes that information back to the application. The application then uses this identity information to determine what the current user can access.

To manage access control, an authorization server will issue access tokens to the client that lists what permissions the current user has. If you'd like to learn more about access tokens, please check out the free ebook below. It goes in-depth about a popular web token standard, JSON Web Token (JWT).

Interested in getting up-to-speed with JWTs as soon as possible?

So even though these two terms have entirely different meanings, the authorization process depends on authentication. Authorization cannot be granted unless the identity of the user is verified.

Because these two processes go hand-in-hand, it's common to see a solution that can handle both ends: authentication and authorization. Auth0, for example, is an all-in-one solution that serves as both an authentication server and an authorization server.

About Auth0

Auth0 by Okta takes a modern approach to customer identity and enables organizations to provide secure access to any application, for any user. Auth0 is a highly customizable platform that is as simple as development teams want, and as flexible as they need. Safeguarding billions of login transactions each month, Auth0 delivers convenience, privacy, and security so customers can focus on innovation. For more information, visit https://auth0.com.

Conclusion

Although the authentication process may seem simple to an end-user, what goes on behind the scenes is very complex. Every time you sign in to a website, there's a lot happening behind the scenes to verify that you are who you say you are.

Hopefully, this article was able to shed a little bit of light on some of the major tasks an authentication server performs, as well as tasks that it isn't responsible for performing.

Thank you for reading and reach out below if you have any questions or if you'd like to learn more about using Auth0 as your authorization and authentication service!

Holly Guevara

Former Developer Content Manager

Holly Guevara

Former Developer Content Manager

More like this

Follow the conversation

Powered by the Auth0 Community. Sign up now to join the discussion. Community links will open in a new window.

HTTP authentication

HTTP provides a general framework for access control and authentication. This page is an introduction to the HTTP framework for authentication, and shows how to restrict access to your server using the HTTP «Basic» schema.

The general HTTP authentication framework

RFC 7235 defines the HTTP authentication framework, which can be used by a server to challenge a client request, and by a client to provide authentication information.

The challenge and response flow works like this:

1. The server responds to a client with a 401 (Unauthorized) response status and provides information on how to authorize with a WWW-Authenticate response header containing at least one challenge.
2. A client that wants to authenticate itself with the server can then do so by including an Authorization request header with the credentials.
3. Usually a client will present a password prompt to the user and will then issue the request including the correct Authorization header.

The general message flow above is the same for most (if not all) authentication schemes. The actual information in the headers and the way it is encoded does change!

Warning: The «Basic» authentication scheme used in the diagram above sends the credentials encoded but not encrypted. This would be completely insecure unless the exchange was over a secure connection (HTTPS/TLS).

Proxy authentication

The same challenge and response mechanism can be used for proxy authentication. As both resource authentication and proxy authentication can coexist, a different set of headers and status codes is needed. In the case of proxies, the challenging status code is 407 (Proxy Authentication Required), the Proxy-Authenticate response header contains at least one challenge applicable to the proxy, and the Proxy-Authorization request header is used for providing the credentials to the proxy server.

Access forbidden

If a (proxy) server receives invalid credentials, it should respond with a 401 Unauthorized or with a 407 Proxy Authentication Required , and the user may send a new request or replace the Authorization header field.

If a (proxy) server receives valid credentials that are inadequate to access a given resource, the server should respond with the 403 Forbidden status code. Unlike 401 Unauthorized or 407 Proxy Authentication Required , authentication is impossible for this user and browsers will not propose a new attempt.

In all cases, the server may prefer returning a 404 Not Found status code, to hide the existence of the page to a user without adequate privileges or not correctly authenticated.

Authentication of cross-origin images

A potential security hole (that has since been fixed in browsers) was authentication of cross-site images. From Firefox 59 onwards, image resources loaded from different origins to the current document are no longer able to trigger HTTP authentication dialogs (Firefox bug 1423146), preventing user credentials being stolen if attackers were able to embed an arbitrary image into a third-party page.

Character encoding of HTTP authentication

Browsers use utf-8 encoding for usernames and passwords.

Firefox once used ISO-8859-1 , but changed to utf-8 for parity with other browsers and to avoid potential problems as described in Firefox bug 1419658.

WWW-Authenticate and Proxy-Authenticate headers

The WWW-Authenticate and Proxy-Authenticate response headers define the authentication method that should be used to gain access to a resource. They must specify which authentication scheme is used, so that the client that wishes to authorize knows how to provide the credentials.

The syntax for these headers is the following:

Here, <type> is the authentication scheme («Basic» is the most common scheme and introduced below). The realm is used to describe the protected area or to indicate the scope of protection. This could be a message like «Access to the staging site» or similar, so that the user knows to which space they are trying to get access to.

Authorization and Proxy-Authorization headers

The Authorization and Proxy-Authorization request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the <type> is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.

Authentication schemes

The general HTTP authentication framework is the base for a number of authentication schemes.

IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS.

Some common authentication schemes include:

Basic

See RFC 7617, base64-encoded credentials. More information below.

Bearer

See RFC 6750, bearer tokens to access OAuth 2.0-protected resources

Digest

See RFC 7616. Firefox 93 and later support the SHA-256 algorithm. Previous versions only support MD5 hashing (not recommended).

HOBA

See RFC 7486, Section 3, HTTP Origin-Bound Authentication, digital-signature-based

Mutual

Negotiate / NTLM

VAPID

SCRAM

AWS4-HMAC-SHA256

See AWS docs. This scheme is used for AWS3 server authentication.

Schemes can differ in security strength and in their availability in client or server software.

The «Basic» authentication scheme offers very poor security, but is widely supported and easy to set up. It is introduced in more detail below.

Basic authentication scheme

The «Basic» HTTP authentication scheme is defined in RFC 7617, which transmits credentials as user ID/password pairs, encoded using base64.

Security of basic authentication

As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS/TLS should be used with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.

Restricting access with Apache and basic authentication

To password-protect a directory on an Apache server, you will need a .htaccess and a .htpasswd file.

The .htaccess file typically looks like this:

The .htaccess file references a .htpasswd file in which each line consists of a username and a password separated by a colon ( : ). You cannot see the actual passwords as they are hashed (using MD5-based hashing, in this case). Note that you can name your .htpasswd file differently if you like, but keep in mind this file shouldn’t be accessible to anyone. (Apache is usually configured to prevent access to .ht* files).

Restricting access with Nginx and basic authentication

For Nginx, you will need to specify a location that you are going to protect and the auth_basic directive that provides the name to the password-protected area. The auth_basic_user_file directive then points to a .htpasswd file containing the encrypted user credentials, just like in the Apache example above.

Access using credentials in the URL

Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this: