Какой из протоколов ааа объединяет в один запрос аутентификация и авторизацию

Обновлено: 04.07.2024

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

СОДЕРЖАНИЕ

С увеличением количества достоверной информации, доступной по сети, возникла потребность в ограничении доступа посторонних лиц к этим данным. В компьютерном мире украсть чью-то личность легко - пришлось изобрести специальные методы проверки, чтобы выяснить, действительно ли человек / компьютер, запрашивающий данные, является тем, кем он себя называет. Задача протокола аутентификации - указать точную последовательность шагов, необходимых для выполнения аутентификации. Он должен соответствовать основным принципам протокола:

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

Иллюстрация аутентификации на основе пароля с использованием простого протокола аутентификации:

Алиса (объект, желающий быть проверенным) и Боб (объект, удостоверяющий личность Алисы) оба знают о протоколе, который они договорились использовать. Боб хранит пароль Алисы в базе данных для сравнения.

Протоколы аутентификации, разработанные для протокола точка-точка PPP

Протоколы используются в основном серверами двухточечного протокола (PPP) для проверки подлинности удаленных клиентов перед предоставлением им доступа к данным сервера. Большинство из них используют пароль как краеугольный камень аутентификации. В большинстве случаев пароль должен быть передан между взаимодействующими объектами заранее.

PAP - протокол аутентификации пароля

CHAP - протокол аутентификации запрос -рукопожатие

Процесс аутентификации в этом протоколе всегда инициализируется сервером / хостом и может выполняться в любое время в течение сеанса, даже повторно. Сервер отправляет случайную строку (обычно длиной 128 Б). Клиент использует пароль и строку, полученные в качестве параметров для хеш-функции MD5, а затем отправляет результат вместе с именем пользователя в виде обычного текста. Сервер использует имя пользователя для применения той же функции и сравнивает вычисленный и полученный хэш. Аутентификация успешна или неудачна.

EAP - расширяемый протокол аутентификации

Первоначально EAP был разработан для PPP (протокол точка-точка), но сегодня широко используется в IEEE 802.3 , IEEE 802.11 (WiFi) или IEEE 802.16 как часть структуры аутентификации IEEE 802.1x . Последняя версия стандартизирована в RFC 5247. Преимущество EAP состоит в том, что это только общая структура аутентификации для аутентификации клиент-сервер - конкретный способ аутентификации определен во многих его версиях, называемых EAP-методами. Существует более 40 EAP-методов, наиболее распространенными из которых являются:

Протоколы архитектуры AAA (аутентификация, авторизация, учет)

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

TACACS , XTACACS и TACACS +

Самый старый протокол AAA, использующий аутентификацию на основе IP без какого-либо шифрования (имена пользователей и пароли передавались в виде простого текста). В более поздней версии XTACACS (Extended TACACS) добавлены авторизация и учет. Оба эти протокола позже были заменены на TACACS +. TACACS + разделяет компоненты AAA, поэтому они могут быть отделены и обрабатываться на отдельных серверах (он даже может использовать другой протокол, например, для авторизации). Он использует TCP (протокол управления передачей) для транспортировки и шифрует весь пакет. TACACS + является собственностью Cisco.

РАДИУС

Служба удаленной аутентификации пользователей с телефонным подключением (RADIUS) - это полный протокол AAA, обычно используемый интернет-провайдером . Учетные данные в основном основаны на комбинации имени пользователя и пароля, для транспорта используются протоколы NAS и UDP .

ДИАМЕТР

Диаметр (протокол) произошел от RADIUS и включает в себя множество улучшений, таких как использование более надежного транспортного протокола TCP или SCTP и более высокий уровень безопасности благодаря TLS .

Другой

Kerberos (протокол)

Kerberos - это централизованная система сетевой аутентификации, разработанная в Массачусетском технологическом институте и доступная как бесплатная реализация от Массачусетского технологического института, а также во многих коммерческих продуктах. Это метод проверки подлинности по умолчанию в Windows 2000 и более поздних версиях. Сам процесс аутентификации намного сложнее, чем в предыдущих протоколах - Kerberos использует криптографию с симметричным ключом , требует доверенной третьей стороны и может использовать криптографию с открытым ключом на определенных этапах аутентификации, если это необходимо.

AAA (от англ. Authentication, Authorization, Accounting) — используется для описания процесса предоставления доступа и контроля за ним.

Authentication (аутентификация) — сопоставление персоны (запроса) существующей учётной записи в системе безопасности. Осуществляется по логину, паролю, сертификату, смарт-карте и т. д.

Accounting (учёт) — слежение за потреблением ресурсов (преимущественно сетевых) пользователем.

Классификация ааа

Среди технологий ААА можно выделить следующие:

Radius (англ. Remote Authentication in Dial-In User Service) — протокол AAA (Authentication, Authorization и Accounting), разработанный для передачи сведений между центральной платформой AAA и оборудованием Dial-Up доступа (NAS, Network Access Server) и системой биллинга (то есть, системой тарификации использованных ресурсов конкретным абонентом/пользователем). Первичными данными (то есть, традиционно передаваемыми по протоколу RADIUS) являются величины входящего и исходящего трафиков: в байтах/октетах (с недавних пор в гигабайтах). Однако протокол предусматривает передачу данных любого типа, что реализуется посредством VSA (Vendor Specific Attributes).

Сервер radius использует протокол UDP для работы. Стандартно radius сервер прослушивает 1812 порт. Для аккаунтинга используется другой порт - 1813(radius-acct).

Рассмотрим как отреагирует NAS (Network Access Server ) при поступлении запроса пользователя на аутентификацию:

пользователь пытается пройти аутентификацию на NAS

NAS смотрит в первый попавшийся radius сервер и посылает пакет для установки связи(запрос на доступ)

если ответ не получен в течение определённого тайм-аута, то NAS либо опрашивает radius сервер ещё раз, либо ищет альтернативный сервер

radius сервер смотрит ip адрес NAS и проверяет ключ симметричного шифрования, если ip адрес и ключ соответствуют тому, что написано в конфигурационном файле, то связь продолжается, иначе клиенту посылается пакет Invalid Key. Проверка осуществляется генерацией и шифрацией случайной строки. Далее передаваемые между клиентом и сервером radius данные шифруются данным ключом.

сервер radius проверяет пароль пользователя(по сети передается md5 хеш пароля), помимо пароля сервер может также проверить ip адрес и порт NAS, если эти данные неверны, то сервер посылает NAS пакет "Доступ запрещён", содержащий код ошибки, который также может содержать текстовое описание ошибки, отображаемое для пользователя

если же данные пользователя верны, то сервер посылает NAS пакет "Доступ разрешён", содержащий данные о сервисе(PPP, SLIP, login) и некоторые специфические параметры сервиса, например, ip адрес, номер подсети, MTU для PPP сервиса в виде пар параметр=значение(AV пар).

TACACS (англ. Terminal Access Controller Access Control System) — сеансовый протокол, использовавшийся на серверах доступа ARPANET. Центральный сервер, который принимает решение, разрешить или не разрешить определённому пользователю подключиться к сети. TACACS не предусматривает сбора какой-либо статистики. Таким образом от AAA (англ. authentication, authorization, accounting) остаётся AA (англ. authentication, authorization).

TACACS+ - это протокол, реализованный по технологии клиент-сервер, причем почти всегда клиент - это NAS (Network Access Server - сервер сетевого доступа; например, Cisco AS5300 и Shiva Corp. 's Access Manager 3.0), а сервер - некоторая программа, запущенная на хост-машине (UNIX, NT или другая, необходимо отметить что UNIX системы наиболее распространены в роли серверов TACACS+). Примером таких серверов являются CiscoSecure Access Control Server (ACS) и Shiva's LAN Rover/E Plus.

Протокол TACACS+ позволяет объединить несколько NAS в общую систему обеспечения аутентификации в рамках системы обеспечения сетевой безопасности, функционируя в 2 режимах:

1. проведение аутентификации, используя централизованную базу учетных записей.

2. посредничество для внешних систем аутентификации (т. н. proxy-режим).

Благодаря этому он может использоваться и в глобальных системах предоставления безопасного сетевого доступа, таких как CiscoSecure Global Roaming Server (GRS).

Принципиально важной особенностью протокола TACACS+ является то, что он позволяет разделить аутентификацию, авторизацию и учет (AAA - Authentication, Authorization, Accounting) и реализовать их на отдельных серверах. Это является существенным прогрессом по сравнению как с исходным протоколом TACACS, в который понятие учета вообще не входило, так и с протоколом RADIUS, в котором аутентификация и авторизация совмещены.

Процесс аутентификации TACACS+

Заголовок пакета TACACS+ содержит поле типа, являющееся признаком того, что пакет представляет собой часть процесса ААА. Аутентификация TACACS+ различает три типа пакетов: START (начало), CONTINUE (продолжение) и REPLY (ответ). Рассмотрим процесс аутентификации TACACS+, в котором сервер сетевого доступа обменивается пакетами аутентификации с сервером TACACS+

Сервер сетевого доступа посылает пакет START серверу защиты TACACS+, чтобы начать процесс аутентификации.

Процесс аутентификации на сервере защиты TACACS+ обычно возвращает серверу сетевого доступа пакет GETUSER, содержащий запрос имени пользователя.

Сервер сетевого доступа запрашивает имя пользователя и посылает введенное имя серверу защиты TACACS+ в пакете CONTINUE.

Сервер защиты TACACS+ посылает серверу сетевого доступа пакет GETPASS, содержащий запрос пароля. Сервер сетевого доступа выдает запрос пароля пользователю.

Сервер сетевого доступа посылает серверу защиты TACACS+ пакет CONTINUE, содержащий пароль, введенный пользователем.

Сервер защиты TACACS+ проверяет пароль, используя для этого информацию из файла конфигурации TACACS+, и решает, успешно ли завершен процесс аутентификации данного пользователя. В результате серверу сетевого доступа возвращается либо пакет PASS (успех), либо пакет FAIL (неудача), указывающий результат аутентификации.

Процесс авторизации TACACS+

В процессе авторизации TACACS+ используется два типа пакетов: REQUEST (запрос) и RESPONSE (ответ). Данный процесс авторизации пользователя контролируется посредством обмена парами "атрибут/значение" между сервером защиты TACACS+ и сервером сетевого доступа. Рассмотрим процесс авторизации TACACS+, в котором сервер сетевого доступа обменивается пакетами авторизации с сервером TACACS+.

Сервер сетевого доступа посылает пакет REQUEST серверу защиты TACACS+. Данный пакет содержит фиксированный набор полей, идентифицирующих пользователя или процесс, а также переменный набор аргументов, описывающих сервисы и параметры, необходимые для авторизации.

Сервер защиты TACACS+ возвращает серверу сетевого доступа пакет RESPONSE, содержащий переменный набор аргументов ответа (пары "атрибут/значение"). Эти пары строятся на основе ранее заданных разрешений для данного пользователя, хранимых в файле конфигурации TACACS+. Вот несколько примеров таких пар.

service = ррр - исходно доступный сервис

protocol = ip - протокол, доступный для использования с указанным сервисом

addr = 172.16.10.1 - авторизованный сетевой адрес

timeout = 12 - абсолютный таймер, ограничивающий длительность соединения в минутах

Сервер сетевого доступа использует пары "атрибут/значение" для того, чтобы запретить, разрешить или модифицировать возможности использования команд и сервисов, запрашиваемых пользователем.

Процесс Аудита

AAA - authentication, authorization and accounting.

The commonest unwanted side effects of Viagra are headache, flushing with the face, and dyspepsia cialis online professional Yellow Pear Shaped Pill w jelly cialis buy online. This material is provided for educational purposes only and is not created for medical advice, diagnosis or treatment india generic cialis.

Authentication отвечает на вопрос "Кто ты?". Т.е. определяет что пользователь тот кто должен быть. Другими словами это комбинация логин - пароль.

Authorization отвечает на вопрос "Что этот пользователь вправе делать?".

Accounting отвечает на вопрос "Что могут пользователи делать в сети?". Т.е. ведется статистика о том чем занимаются пользователи.

Важно заметить что Authorization и Accounting могут использоваться только после Authentication.

AAA режимы

Character (буквенный режим) mode - используется на vty, TTY, AUX, CONSOLE портах, которые в основном используются для конфигурирования устройств

Packet mode (пакетный режим) - используется на ASYNC, BRI, PRI, serial портах в основном для обеспечения аутентификации с другим устройством посредством dialer портов.

Понимание TACACS+ и RADIUS протоколов.

RADIUS описан в протоколе RFC 2865. TACACS+ более свежая версия описана в RFC 1492.

RADIUS использует UDP протокол. TACACS+ использует TCP протокол. При этом:

TCP обеспечивает определение недоступности сервера через TCP reset (RST) и TCP keepalive механизм.
TCP более приспособлен к большим сетям.
TCP обеспечивает несколько одновременных соединений к нескольким серверам.

TACACS+ полностью шифрует содержимое своего пакета, указывая в заголовке включено ли шифрование.
RADIUS шифрует только пароль внутри пакета.

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

TACACS+ полностью разделяет авторизацию и аутентификацию. Для примера авторизация может проходить на сервере TACACS+, а аутентификация на сервере Kerberos. RADIUS комбинирует авторизацию и аутентификацию в одном запросе. В отличие от TACACS+, RADIUS не понимает следующие протоколы:

AppleTakl Remote Access (ARA) protocol
NetBIOS Frames Protocol Control Protocol
Novell Asynchronous Services Interface (NASI)
X.25 PAD connection

RADIUS не позволяет использовать проверку вводимых команд пользователем и предоставляет только доступ к устройству.

TACACS+ позволяет контролировать вводимые пользователем команды посредством 2х методов:

Определить команды на TACACS+ сервере которые доступны пользователю или группе.
В зависимости от уровня привилегий TACACS+ сервер определяет доступные команды пользователю или группе.

Настройка AAA используя CLI.

Пример настройки RADIUS

aaa new-model
radius-server host 10.10.1.5
radius-server key TheRADIUSServerKey
username root password MySecretPassword
aaa authentication ppp mydiallist radius local
aaa authorization network radius local
aaa accounting network mynetwork start-stop group radius

Пример настройки TACACS+

aaa new-model
tacacs-server host 10.10.1.5
tacacs-server key TheTacacsServerKey
username root password MySecretPassword
aaa authentication ppp mydiallist tacacs+ local
aaa authorization commands 15 tacacs+ if-authenticated none
aaa accounting network start-stop tacacs+

Рассмотрим команды подробнее:

aaa new-model - включение AAA.

radius-server host hostname | ip-address> [auth-port port-number] [acct-port port-number] [timeout seconds] [retransmit retries] Какой из протоколов ааа объединяет в один запрос аутентификация и авторизацию [aliashostname | ip-address>]

tacacs-server host hostname | ip-address> Какой из протоколов ааа объединяет в один запрос аутентификация и авторизацию [nat] [port [integer]] [single-connection] [timeout [integer]]

параметры те же что и для RADIUS сервера
nat - nat адрес клиента.
port - по умолчанию 49.
single-connection - поддерживает только одно соединение между клиентом и сервером.

aaa authentication ppp default | list-name> method1 [method2. ]

default - Uses the authentication methods following the parameter as the default list when a user logs in
list-name - Character string used to name the list of methods used when the user logs in
method1 [method2. ] - At least one of the following methods is used:
if-needed = do not authenticate if the user is already authenticated
krb5 = use Kerberos 5 for authentication
local = use the local database
none = no authentication
radius = use RADIUS authentication
tacacs+ = use TACACS+ authentication

network - Runs authorization for all network-related service requests
exec - Runs authorization to determine if the user is authorized to run an EXEC shell
commands - Runs authorization for all commands at the specified level
level - Specific command level that should be authorized; level may be from 0 through 15
reverse-access - Runs authorization for reverse access connections (reverse Telnet)
default - Uses the authentication methods following the parameter as the default list when a user logs in
list-name - Character string used to name the list of methods used when the user logs in

auth-proxy - Performs accounting for all authenticated proxy events
system - Performs accounting for all system-level events not associated with users (reboots and so forth)
network - Performs accounting for all network-related requests
exec - Performs accounting for all EXEC shell sessions
connection - Performs accounting for all outbound connections from the network access server
commands level - Performs accounting for all commands at the specified level
default - Uses the listed accounting methods that follow
list-name - Character string used to name the list; valid options are
group radius = list of RADIUS servers
group tacacs = list of TACACS+ servers
group group-name = a subset of RADIUS or TACACS+ servers
vrf vrf-name - Specifies a VRF (Virtual Route Forwarding) configuration
start-stop - Sends a “start” notice at the beginning of a process and a “stop” notice at the termination of the process
stop-only - Sends a “stop” notice at the end of a process
broadcast - Enables sending accounting records to multiple AAA servers
group group-name - Character string used to name the list; valid options are
group radius = list of RADIUS servers
group tacacs = list of TACACS+ servers
group group-name = a subset of RADIUS or TACACS+ servers

Настройка AAA через SDM.

Configure ----> Additional Tasks -----> AAA

В нем необходимо настроить AAA Servers and Groups ----> Authentication policy -----> Authorization policy

Debug AAA.

debug aaa authentication
debug aaa authorization
debug aaa accounting
debug radius
debug tacacs

Прежде чем начать изучать Radius, важно, чтобы вы поняли:

Итак, давайте сначала разберемся с этими двумя темами.

Что такое ААА?

AAA означает Аутентификацию, Авторизацию и Учет.

Аутентификация

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

Выполняется путем представления личности и учетных данных.

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

Выполняется путем представления личности и учетных данных.

авторизация

Может основываться на ограничениях, например, ограничениях времени суток, ограничениях физического местоположения или ограничениях на несколько входов одного и того же пользователя.

Примеры услуг включают в себя фильтрацию IP-адресов, назначение адресов, назначение маршрутов, шифрование, QoS / дифференциальные услуги, управление полосой пропускания / управление трафиком и т. Д.

бухгалтерский учет

Относится к отслеживанию потребления сетевых ресурсов пользователями.

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

Может использоваться для управления, планирования, выставления счетов и т. Д.

Относится к отслеживанию потребления сетевых ресурсов пользователями.

Может использоваться для управления, планирования, выставления счетов и т. Д.

AAA-сервер предоставляет все вышеперечисленные услуги своим клиентам.

Протоколы ААА

Радиус — это протокол AAA для таких приложений, как доступ к сети или мобильность IP. Помимо Radius, у нас есть следующие протоколы в AAA:

Контроллер доступа к терминалу Система контроля доступа (TACACS)

TACACS — это протокол удаленной аутентификации, который используется для связи с сервером аутентификации, обычно используемым в сетях Unix. TACACS позволяет серверу удаленного доступа обмениваться данными с сервером аутентификации, чтобы определить, имеет ли пользователь доступ к сети.

TACACS +

TACACS + обеспечивает управление доступом для маршрутизаторов, серверов сетевого доступа и других сетевых вычислительных устройств через один или несколько централизованных серверов. Он использует TCP и предоставляет отдельные службы аутентификации, авторизации и учета. Он работает в порту 49.

ДИАМЕТР

Диаметр — плановая замена Радиуса.

Что такое сервер доступа к сети?

Сервер доступа к сети (NAS) — это элемент службы, который клиенты набирают для получения доступа к сети. NAS — это устройство, имеющее интерфейсы как к магистрали, так и к POTS или ISDN, и принимает вызовы от хостов, которые хотят получить доступ к магистрали через службы коммутируемого доступа. NAS находится в точке присутствия интернет-провайдера, чтобы обеспечить доступ в Интернет своим клиентам.

Сервер доступа к сети:

Единая точка доступа к удаленному ресурсу.

Сервер удаленного доступа, поскольку он обеспечивает удаленный доступ к сети.

Начальная точка входа в сеть.

Шлюз для защиты защищаемого ресурса.

Единая точка доступа к удаленному ресурсу.

Сервер удаленного доступа, поскольку он обеспечивает удаленный доступ к сети.

Начальная точка входа в сеть.

Шлюз для защиты защищаемого ресурса.

Примеры включают в себя:

Проверка доступа в Интернет с использованием идентификатора пользователя и пароля.

VoIP, FoIP и VMoIP требуют действительный номер телефона или IP-адрес.

Телефонная карта предоплаты использует номер карты предоплаты.

Проверка доступа в Интернет с использованием идентификатора пользователя и пароля.

VoIP, FoIP и VMoIP требуют действительный номер телефона или IP-адрес.

Телефонная карта предоплаты использует номер карты предоплаты.

На следующем рисунке показана базовая архитектура Radius.

RADIUS — это протокол для передачи информации, связанной с аутентификацией, авторизацией и настройкой, между сервером доступа к сети, который хочет аутентифицировать свои ссылки, и общим сервером аутентификации.

RADIUS расшифровывается как удаленная аутентификация Dial In User Service.

RADIUS — это протокол AAA для таких приложений, как доступ к сети или мобильность IP

Он работает в обеих ситуациях, локальных и мобильных.

Он использует протокол аутентификации по паролю (PAP), протокол аутентификации при вызове (CHAP) или протоколы расширяемого протокола аутентификации (EAP) для аутентификации пользователей.

Это смотреть в текстовом файле, серверах LDAP, базе данных для аутентификации.

После проверки подлинности параметры сервиса передаются обратно в NAS.

Он уведомляет, когда сеанс начинается и заканчивается. Эти данные используются для выставления счетов или статистики.

SNMP используется для удаленного мониторинга.

Может использоваться как прокси.

RADIUS расшифровывается как удаленная аутентификация Dial In User Service.

RADIUS — это протокол AAA для таких приложений, как доступ к сети или мобильность IP

Он работает в обеих ситуациях, локальных и мобильных.

Это смотреть в текстовом файле, серверах LDAP, базе данных для аутентификации.

После проверки подлинности параметры сервиса передаются обратно в NAS.

SNMP используется для удаленного мониторинга.

Может использоваться как прокси.

Вот простая сетевая диаграмма радиуса:

Вот список всех ключевых особенностей Radius:

Модель клиент / сервер

NAS работает как клиент для сервера Radius.

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

Сервер Radius может выступать в качестве прокси-клиента для других серверов Radius.

NAS работает как клиент для сервера Radius.

Сервер Radius может выступать в качестве прокси-клиента для других серверов Radius.

Прежде чем пользователи смогут отправлять запросы с помощью 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 представляет собой длинную строку, которую обычно включают либо в URL запроса, либо в заголовок запроса. Ключ API в основном служит способом идентификации лица, выполняющего запрос API (аутентифицируя для использования API). Ключ API также может быть связан с конкретным приложением, которое регистрируется.

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

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

Basic Auth

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

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

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

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

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

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

OAuth 2.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SendGrid

API ключ SendGrid

Twitter

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

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

Amazon Web Services

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

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

Dropbox

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

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

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

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

Читайте также: