Авторизационный запрос
Смотреть что такое «Авторизационный запрос» в других словарях:
Авторизация, авторизационный запрос по таможенной карте — Авторизация, авторизационный запрос процедура проверки таможенной карты с целью получения подтверждения о возможности совершения запрашиваемой операции. Источник: Приказ ГТК РФ от 18.01.2001 N 51 Об использовании таможенных карт при получении… … Официальная терминология
Платёжные карты — Банковские карты Visa и Mastercard Банковская карта пластиковая карта, привязанная к лицевому счёту одного из банков. Используются для платежей, в том числе через Интернет. Часто используется выражение «кредитная карта» или «кредитка», но оно… … Википедия
Банковская карта — Банковские карты Visa и Mastercard Банковская карта пластиковая карта, привязанная к лицевому счёту одного из банков. Используются для платежей, в том числе через Интернет. Часто используется выражение «кредитная карта» или «кредитка», но оно… … Википедия
Зарплатная карта — Банковские карты Visa и Mastercard Банковская карта пластиковая карта, привязанная к лицевому счёту одного из банков. Используются для платежей, в том числе через Интернет. Часто используется выражение «кредитная карта» или «кредитка», но оно… … Википедия
Зарплатная карточка — Банковские карты Visa и Mastercard Банковская карта пластиковая карта, привязанная к лицевому счёту одного из банков. Используются для платежей, в том числе через Интернет. Часто используется выражение «кредитная карта» или «кредитка», но оно… … Википедия
Кредитная карточка — Банковские карты Visa и Mastercard Банковская карта пластиковая карта, привязанная к лицевому счёту одного из банков. Используются для платежей, в том числе через Интернет. Часто используется выражение «кредитная карта» или «кредитка», но оно… … Википедия
Кредитные карты — Банковские карты Visa и Mastercard Банковская карта пластиковая карта, привязанная к лицевому счёту одного из банков. Используются для платежей, в том числе через Интернет. Часто используется выражение «кредитная карта» или «кредитка», но оно… … Википедия
Платежные карты — Банковские карты Visa и Mastercard Банковская карта пластиковая карта, привязанная к лицевому счёту одного из банков. Используются для платежей, в том числе через Интернет. Часто используется выражение «кредитная карта» или «кредитка», но оно… … Википедия
Платёжная карта — Банковские карты Visa и Mastercard Банковская карта пластиковая карта, привязанная к лицевому счёту одного из банков. Используются для платежей, в том числе через Интернет. Часто используется выражение «кредитная карта» или «кредитка», но оно… … Википедия
Банковская платежная карта — Банковские карты Visa и Mastercard Банковская карта пластиковая карта, привязанная к лицевому счёту одного из банков. Используются для платежей, в том числе через Интернет. Часто используется выражение «кредитная карта» или «кредитка», но… … Википедия
Что такое авторизация банковской карты
Авторизация банковской карты — это проверка ее на возможность выполнения финансовой операции. Она всегда случается, когда держатель желает оплатить покупку, списав деньги с карточного счета. Для клиента это проходит практически моментально, но за эти пару секунд успевают пройти разные проверки и запросы.
Разберемся, что такое авторизация банковской карты, как вообще проходит этот процесс. По каким причинам может быть отказано в авторизации и выполнении платежа. Все особенности проверки карточки — на Бробанк.ру.
Что означает авторизация банковской карты
В последнее время все больше финансовых операций уходят в онлайн. Оборот наличных средств снижается, граждане все чаще оплачивают свои покупки картой. И каждый раз, когда они это делают, происходит авторизация карты или проще говоря — ее проверка на возможность выполнения операции.
Авторизация по карте — это механизм “общения” между банком-эмитентом, банком-эквайером и процессинговым центром. В результате такого диалога определяется, возможно ли проведение оплаты. Если да, авторизация проходит успешно, система дает добро.
Если по каким-то причинам финансовая операция не может быть проведена, авторизация отменяется. На терминале, через который совершалась покупка, появляется соответствующая надпись. Если транзакция проводилась онлайн, сообщение об отмене появляется в отдельном окне.
Как проходит авторизация банковской карты при онлайн-оплате
Для покупателя все предельно просто — он прикладывает (вставляет) карту к терминалу, система пару секунд думает, после выносит решение и одобряет проведение платежа. Но за эти пару секунд происходит авторизация банковской карты, состоящая из следующих шагов:
Несмотря на много задействованных “лиц” и множество запросов операция для покупателя проводится предельно быстро. Весь процесс автоматизированный и занимает не больше пары секунд. В некоторых случаях, если есть проблемы со связью, может случиться небольшая задержка.
Причины отказа в проведении операции
Бывает так, что операция проведения оплаты с карточки невозможна, тогда система после обработки запроса дает отрицательное решение. Это значит, что по каким-то причинам оплата невозможна, продавец не сможет получить деньги, поэтому в сделке отказывается.
Поводы для отказа:
В этом случае банк-эмитент не сможет передать деньги за покупку продавцу, списав их с карточного счета, поэтому случается отмена операции.
Если вы не понимаете, почему так случилось, звоните на горячую линию банка, обслуживающего пластик.
Когда сумма покупки уйдет в магазин
Деньги с карточного счета сразу списываются, но они никуда не уходят, а просто зависают на некоторое время. Если заглянуть в онлайн-банк в перечень проведенных расходных операций, эти транзакции будут отмечены значком. Это значит, что средства просто заблокированы, но никуда не ушли.
Авторизация операций занимает до трех дней. Это время нужно для сообщений между банками и передачи средств на счет продавца. То есть магазин не получает деньги моментально, они будут у него примерно через 3 дня. Несмотря на то, что деньги фактически еще не ушли со счета, воспользоваться ими будет невозможно.
Голосовая авторизация при оплате картой
Это метод авторизации, который можно назвать устаревшим, он практически не применяется. Можно сказать, что в этом случае подтверждение операции проводится продавцом вручную.
Голосовая авторизация предполагает, что сам продавец звонит банку-эквайеру с целью узнать, возможна ли такая операция. И только после ручной проверки и положительном ответе товар отдается покупателю.
По факту такая авторизация платежа давно канула в Лету и не применяется на рынке. Это пережиток прошлого, на замену которого пришли автоматически технологии.
Что такое код авторизации банковской карты
После совершения операции в торговой точке покупатель получает чек, который содержит различную информацию. Это не только сведения о покупке, но и платежные данные. В том числе код авторизации.
При положительном решении о покупке банк присваивает операции нужный код, по факту он покупателю не нужен. Но если вдруг произошел отказ, и клиент не понимает, в чем причина, тогда при обращении на горячую линию поможет указание кода отказа. Оператор его расшифрует и даст ответ.
Авторизация пластиковых карт при получении займа
МФО, выдающие онлайн-займы, применяют свою авторизацию платежных средств потенциальных заемщиков. Им нужно убедиться, что карта действующая, принадлежит самому заемщику, на нее может быть совершен перевод одобренного займа.
Для этого микрофинансовая организация после указания клиентом реквизитов своей карты (для зачисления одобренного микрокредита) блокирует на карточном счету небольшую сумму. Эти деньги вскоре возвращаются обратно. При этом совершается классическая авторизация. Если все прошло успешно, карта проверена, она может использоваться для получения займа.
Вопросы и ответы
Что такое авторизация кредитной карты?
При проведении авторизации не имеет значения тип карты. Если она кредитная, делается аналогичный запрос на возможность проведения операции. Отказ может случиться по причине недостатка кредитного лимита или в случае блокировки банком-эмитентом кредитного счета.
Как узнать код авторизации банковской карты?
Если операция совершалась в магазине, код будет указан на чеке. Даже если операция была отказной, продавец все равно выдаст чек, где будет отражаться нужная информация. При выполнении оплаты онлайн код найдете в электронной квитанции или в банкинге.
Что такое неоплаченные авторизации по карте?
Это финансовые операции, которые пока что не проведены. После оплаты деньги фактически уходят со счета в течение 3-х дней. На этот срок они зависают на счету заблокированными и являются пока что неоплаченными. Пользоваться этими деньгами невозможно, вскоре они окончательно уйдут с карточного счета.
Что значит превышена сумма авторизации по карте?
Это означает, что клиент превысил предусмотренные лимиты на расходные операции. Поэтому банк отказал в проведении следующей. Она будет возможна, когда откроется новый лимит. Ограничения бывают ежесуточными и ежемесячными.
Когда нужно подтверждать авторизацию ПИН-кодом?
Обычно достаточно приложить карту к терминалу или вставить ее в устройство. Но если сумма операции большая, требуется введение ПИН-кода. Если речь о карточке Виза, ПИН нужен при оплате на сумму более 3000. Если МИР — от 1000 рублей.
Комментарии: 2
Если у вас есть вопросы по этой статье, вы можете сообщить нам. В нашей команде только опытные эксперты и специалисты с профильным образованием. В данной теме вам постараются помочь:
Здравствуйте, оплата за услуги предоставленных товаров в приложении списана дважды, первая оплата не прошла, вторая успешно, была написана претензия в банк. ответили на карте был зарегистрирован авторизационный запрос на сумму1900 средства на эту сумму были заблокированы указанная сумму 1900 не была списана. а сумма на услугу была списана, с этой суммы 1900 и осталось 1600 которая стала доступна для расходования причем днем позже, в выписке из банка оплата произведена один раз, в мобильном приложении телефона отражена дважды, подскажите какие мои действия в плане этой проблемы
Уважаемая Татьяна, закажите электронную выписку по счету. После ее получения напишите заявление в банк с требованием о детализации операций по карте, приложив выписку, отражающую задвоенное списание. Дополнительно сообщите специалисту банка о наличии проблемы по телефону горячей линии.
Как работает OAuth 2.0 и OpenID Connect
Разбираемся, как работает протокол OAuth 2.0 и OpenID Connect. Почему Authorization Code Grand лучший способ получения access token.
Если коротко OAuth 2.0 — протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе. Протокол избавляет от необходимости доверять приложению логин и пароль, а также позволяет выдавать ограниченный набор прав, а не все сразу.
В этой статье рассмотрим историю возникновения и схему работы. Разберемся в чем отличие OAuth 2.0 от OpenID Connect и что такое SSO.
История возникновения OAuth
Авторизацией через социальные сети никого уже не удивишь. Нажимаешь кнопку соц сети, вжух и ты авторизовался на новом сайте. Сайт получил твоё ФИО, фотку и прочие данные. Но так было не всегда.
В «каменном веке» интернета все было проще. Вы просто давали свой логин и пароль от одного сервиса другому, чтобы тот вошел в вашу учетную запись и получил любую необходимую ему информацию.
На заре становления Facebook просил у пользователей логин и пароль от Gmail аккаунта, чтобы отправить контактам приглашение. Такой подход имеет большую проблему: логин и пароль дают полный доступ к сервису. Поэтому был разработан стандарт OAuth.
С помощью этого стандарта вы позволяете приложению считать данные или использовать функции другого приложения от вашего имени, не сообщая ему свой пароль. Класс!
OAuth 1.0 не используется. Забудьте о нем. Используйте OAuth 2.0
Главным недостатком OAuth 1.0 была слишком большая сложность данной версии.
Начнем разбор OAuth 2.0 с ролей. Всего есть 4 роли:
Далее мы рассмотрим каждую из ролей.
Владелец ресурса
Ресурсом являются данные, например ФИО, фотография, ваши сообщения в соц сетях, и прочее. Владелец ресурса это пользователь. При межсерверном общении владельцем ресурса может быть один из серверов.
Сервер ресурсов
На сервере ресурсов лежат ваши данные. В случае с примером выше ваши контакты Gmail это ресурс, а лежат они на серверах Gmail.
Клиент
Клиент это сервис, которому требуется доступ к вашим ресурсам. Например, Facebook требуется доступ к контактам Gmail.
Авторизационный сервер
В данном примере он принадлежит Google, так как он хранит ваши данные.
Стандарт не запрещает вам объединить Сервер ресурсов и Авторизационный сервер
Базовая схема протокола
OAuth 2.0 основан на использовании базовых веб-технологий: HTTP-запросах, редиректах и т. п. Поэтому использование OAuth возможно на любой платформе с доступом к интернету и браузеру: на сайтах, в мобильных и desktop-приложениях, плагинах для браузеров.
Вернемся к нашему примеру про Facebook и Gmail. На анимации ниже, я постарался схематично изобразить, как реализовать этот пример правильно с помощью Oauth2. Стоит учитывать, что у Google есть свой сервер авторизации, который отвечает за авторизацию на любом сервисе Google. Поэтому Gmail только хранит ресурсы, но не отвечает за авторизацию.
Это строка, которая является альтернативой логину и паролю.
Особенности Access Token:
Помимо access_token Авторизационный сервер может выдавать также refresh_token. Это токен, который позволяет запросить новый access_token без участия Владельца ресурсов. Время жизни у такого токена намного больше access_token и его потеря гораздо серьезнее.
Вернемся к базовой схеме. Авторизационный сервер должен знать про каждого клиента, который делает к нему запрос. То есть, каждый клиент должен быть зарегистрирован. Зарегистрировав клиента мы получаем client_id и client_secret и обязаны передавать, как минимум client_id в каждом запросе.
Существует возможность регистрировать клиентов динамически: RFC 7591 и RFC 7592.
Способы получения Access Token
Всего есть 4 способа:
Client Credentials
Начнем разбор с самой простой схемы. Этот способ придуман для межсерверного взаимодействия. У нас есть два сервера API1 и API2, и им надо как-то общаться.
3. API 1 обращается к API 2.
4. API 2 получает запрос с access_token и обращается к авторизационному серверу для проверки действительности переданного токена (RFC 7662).
Resource Owner Password Credential
Эта схема не рекомендуется к использованию! В стандарте так и написано, если вы никакие другие схемы не можете сделать, то используйте эту.
Authorization Code Grand
Является одним из наиболее распространённых типов разрешения, поскольку он хорошо подходит для серверных приложений, где исходный код приложения и секрет клиента не доступны посторонним.
Этот способ рекомендуемый. Используйте его, и только если это невозможно, посмотрите на другие способы. Исключением является межсерверное общение.
Пример авторизационного запроса
В настройках Авторизационного сервера можно настроить url адреса, на которые разрешен редирект.
Так как code попадает в браузер и ничем не защищен, то это точка уязвимости. Поэтому на авторизационный код накладываются следующие ограничения:
5. Теперь, когда у вас есть код авторизации, вы должны обменять его на токены. Используя извлеченный код авторизации из предыдущего шага, вам нужно будет выполнить POST на URL-адрес токена.
7. Чтобы вызвать ваш API из обычного веб-приложения, приложение должно передать полученный токен доступа в заголовке авторизации вашего HTTP-запроса.
Implicit Grant
Так как access_token попадает в браузер, то существует возможность его достать.
OpenID Connect
OAuth 2.0 разработан только для авторизации — для предоставления доступа к данным и функциям от одного приложения другому. OpenID Connect (OIDC) — это тонкий слой поверх OAuth 2.0, добавляющий сведения о логине и профиле пользователя, который вошел в учетную запись.
OpenID Connect позволяет реализовывать сценарии, когда единственный логин можно использовать во множестве приложений, — этот подход также известен как single sign-on (SSO)
Заключение
Подведем итог. OAuth 2.0 это простой протокол авторизации, основанный на HTTP, что дает возможность применять его практически на любой платформе. Он имеет хорошую документацию, и большинство крупных площадок его поддерживают. Так что если вы решили использовать этот протокол в своем проекте — это хороший выбор.
HTTP авторизация
HTTP предоставляет набор инструментов для разграничения доступа к ресурсам и авторизацией. Самой распространённой схемой HTTP авторизации является «Basic» (базовая) авторизация. Данное руководство описывает основные возможности HTTP авторизации и показывает способы ограничения доступа к вашему серверу с её использованием.
Общий механизм HTTP авторизации
В случае базовой авторизации как на иллюстрации выше, обмен должен вестись через HTTPS (TLS) соединение, чтобы обеспечить защищённость.
Прокси-авторизация
Этот же механизм запроса и ответа может быть использован для прокси-авторизации. В таком случае ответ посылает промежуточный прокси-сервер, который требует авторизации. Поскольку обе формы авторизации могут использоваться одновременно, для них используются разные заголовки и коды статуса ответа. В случае с прокси, статус-код запроса 407 (Proxy Authentication Required) и заголовок Proxy-Authenticate (en-US), который содержит хотя бы один запрос, относящийся к прокси-авторизации, а для передачи авторизационных данных прокси-серверу используется заголовок Proxy-Authorization (en-US).
Доступ запрещён
Аутентификация с помощью изображений
Аутентификация с помощью изображений, загружаемых из разных источников, была до недавнего времени потенциальной дырой в безопасности. Начиная с Firefox 59, изображения, загружаемые из разных источников в текущий документ, больше не запускают диалог HTTP-аутентификации, предотвращая тем самым кражу пользовательских данных (если нарушители смогли встроить это изображение в страницу).
Кодировка символов HTTP аутентификации
WWW-Authenticate and Proxy-Authenticate headers
WWW-Authenticate (en-US) и Proxy-Authenticate (en-US) заголовки ответа которые определяют методы, что следует использовать для получения доступа к ресурсу. Они должны указывать, какую схему аутентификации использовать, чтобы клиент, желающий авторизоваться, знал, какие данные предоставить. Синтаксис для этих заголовков следующий:
Here, 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 (en-US) 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 used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.
The most common authentication scheme is the «Basic» authentication scheme which is introduced in more details below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:
AWS4-HMAC-SHA256 (see AWS docs).
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 in conjunction 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
Restricting access with nginx and basic authentication
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:
Требования аутентификации и авторизации 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 представляет собой длинную строку, которую обычно включают либо в 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 (код авторизации сообщений на основе хэша)
Сервер 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 используется, когда нужно защитить конфиденциальные данные. В этом сценарии взаимодействуют три группы:
Вот базовый процесс Oauth2.0:
Сначала пользовательское приложение отправляет ключ приложения и секретные данные на страницу входа в систему на сервере аутентификации. Если аутентификация пройдена, сервер аутентификации возвращает пользователю токен доступа (авторизации).
Токен доступа (авторизации) упакован в параметр запроса в перенаправлении ответа (302) на запрос. Перенаправление направляет запрос пользователя обратно на сервер ресурсов (сервер API).
Токены доступа (авторизации) не только обеспечивают аутентификацию для запрашивающей стороны, но и определяют права пользователя на использование API. Кроме того, токены доступа (авторизации) обычно истекают через некоторое время и требуют от пользователя повторного входа в систему. Для получения дополнительной информации об OAuth 2.0 можно посмотреть ресурсы:
Что документируется в разделе аутентификации
В документации API не нужно подробно объяснять внешним пользователям, как работает аутентификация. Отсутствие объяснений внутренних процессов аутентификации, является лучшей практикой, поскольку хакерам будет сложнее злоупотреблять API.
Тем не менее нужно объяснить необходимую информацию:
Если есть открытый и закрытый ключи, нужно объяснить, где следует использовать каждый ключ, и отметить, что закрытые ключи не должны использоваться совместно. Если разные уровни лицензий предоставляют разный доступ к вызовам API, эти уровни лицензирования должны быть явно указаны в разделе авторизации или в другом месте.
Поскольку раздел API ключей важен, и нужен разработчикам до того, как они начнут использовать API, этот раздел должен быть в начале руководства.
Образцы разделов авторизации
Ниже приведены несколько примеров разделов авторизации в документации API.
SendGrid
SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.
В Twitter подробный пример оправдан и предоставлен, поскольку требования к авторизации OAuth 2.0 немного сложнее.
Amazon Web Services
Amazon использует HMAC. Процесс достаточно сложный, чтобы включить полноценную диаграмму, показать шаги, которые должны выполнить пользователи.
Dropbox
Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.
👨💻 Практическое занятие: Авторизация
В своем найденном опен-сорс проекте найдем информацию об авторизации для запросов к API. Ответьте на следующие вопросы:
