Posted:
Дек 23, 2022
Comments:
0 Comments

Аутентификация на сайте: Обзор способов и протоколов аутентификации в веб-приложениях / Хабр

Содержание

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

Spread the love

Оригинальная статья: Kim Maida — Authorization and Authentication For Everyone

Аутентификация и авторизация необходимы для многих приложений. Допустим, вы разработали приложение и внедрили в него аутентификацию и авторизацию — использовали для этого стороннюю библиотеку аутентификации или платформу идентификации. Выполнив свою работу, как обычно вы не стали разбираться, что происходит за кулисами, или почему что-то происходит определенным образом. Но если вы хотите получить общее представление о том, что происходит на самом при использовании стандартов OAuth 2.0 и OpenID Connect, читайте дальше!

Аутентификация — это сложно. Почему так? Стандарты Auth хорошо определены, но в них сложно разобраться. И это нормально! Мы собираемся пройти через это максимально доступным способом. Мы рассмотрим концепции идентификации шаг за шагом, опираясь на наши знания по мере продвижения вперед. К тому времени, когда мы закончим, вы должны иметь фундамент и знать, куда нужно обратиться если вам нужно будет больше информации.

  • Введение
  • OAuth 2.0
  • Проблема входа в систему
  • OpenID Connect
  • Аутентификация с ID Tokens
  • Доступ к API с Access Tokens
  • Делегирование с Scopes
  • Ресурсы и что дальше?

Введение

Когда я говорил семье или друзьям, что я «работаю в identity», они часто предполагали, что это означает, что я работал в правительстве, в организации выдающей водительские права, или что я помогал людям разрешать мошенничество с кредитными картами.

Однако ни то, ни другое не было правдой. Ранее я работал в компании Auth0,, которая управляет цифровой идентификацией. (Сейчас я являюсь участником программы Auth0 Ambassadors и являюсь экспертом Google Developer по SPPI: Security, Privacy, Payments, and Identity — безопасность, конфиденциальность, платежи и идентификация.)

Цифровая идентификация

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

Что это значит?

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

Это приводит нас к …

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

В широком смысле, аутентификация относится к процессу проверки того, что пользователь является тем, кем он себя заявляет.

Как только система сможет установить это, мы приходим к …

Авторизация

Авторизация касается предоставления или отказа в правах доступа к ресурсам.

Стандарты

Вы можете вспомнить, что я упомянул, что аутентификация основывается на четко определенных стандартах. Но откуда эти стандарты берутся?

Есть много разных стандартов и организаций, которые управляют работой Интернета. Два органа, которые представляют для нас особый интерес в контексте аутентификации и авторизации, — это Инженерная рабочая группа по Интернету (Internet Engineering Task Force — IETF) и Фонд OpenID (OpenID Foundation — OIDF).

IETF (Internet Engineering Task Force)

IETF — это большое открытое международное сообщество сетевых инженеров, операторов, поставщиков и исследователей, которые занимаются развитием интернет-архитектуры и бесперебойной работой интернета.

OIDF (OpenID Foundation)

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

Теперь, когда нам известны спецификации и кто их пишет, давайте вернемся к авторизации и поговорим о:

OAuth 2.0

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

OAuth не является спецификацией аутентификации. OAuth имеет дело с делегированной авторизацией. Помните, что аутентификация — это проверка личности пользователя. Авторизация касается предоставления или отказа в доступе к ресурсам. OAuth 2.0 предоставляет доступ к приложениям от имени пользователей.

Как было до OAuth

Чтобы понять цель OAuth, нам нужно вернуться назад во времени. OAuth 1.0 был создан в декабре 2007 года. До этого, если нам требовался доступ к сторонним ресурсам, это выглядело так:

Допустим, вы использовали приложение под названием HireMe123. HireMe123 хочет настроить событие календаря (например, встречу на собеседование) от вашего имени (пользователя). HireMe123 не имеет собственного календаря; поэтому нужно использовать другой сервис под названием MyCalApp для добавления событий.

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

Затем HireMe123 используя ваш логин получить доступ к API MyCalApp, и затем сможет создавать события календаря с использованием ваших учетных данных.

Совместное использование учетных данных — это плохо!

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

Так как, HireMe123 поставил на карту защиты вашей учетной записи MyCalApp гораздо меньше. Если HireMe123 не защитит ваши учетные данные MyCalApp надлежащим образом, и они в конечном итоге будут украдены или взломаны, кто-то сможет написать несколько неприятных статей в блоге, но HireMe123 как бы останется в стороне.

HireMe123 также получает слишком большой доступ к MyCalApp от вашего имени. HireMe123 получает все те же привелегии, что и вы, потому что он использовал ваши учетные данные для получения этого доступа. Это означает, что HireMe123 может читать все ваши события календаря, редактировать их, изменять настройки и т. д.

Появление OAuth

Все эти недостатки приводит нас к OAuth.

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

Используя OAuth, пользователь теперь может делегировать HireMe123 для вызова MyCalApp от имени пользователя. MyCalApp может ограничить доступ к своему API при вызове сторонними клиентами без риска совместного использования информации для входа или предоставления слишком большого доступа. Это делается с помощью:

Сервер авторизации

Сервер авторизации — это набор конечных точек (методов API) для взаимодействия с пользователем и выдачи токенов. Как это работает?

Давайте вернемся к ситуации с HireMe123 и MyCalApp, только теперь у нас есть OAuth 2.0:

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

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

HireMe123 отправляет запрос авторизации на сервер авторизации MyCalApp. В ответ сервер авторизации MyCalApp предлагает вам — пользователю — войти в систему с помощью MyCalApp (если вы еще не вошли в систему). Вы аутентифицируетесь с MyCalApp.

Затем сервер авторизации MyCalApp запросит у вас согласие разрешить HireMe123 получать доступ к API MyCalApp от вашего имени. В браузере откроется приглашение, в котором будет запрошено ваше согласие на добавление в календарь событий HireMe123 (но не более того).

Если вы скажете «да» и дадите свое согласие, то сервер авторизации MyCalApp отправит код авторизации в HireMe123. Это позволяет HireMe123 знать, что пользователь MyCalApp (вы) действительно согласился разрешить HireMe123 добавлять события с использованием пользовательского (вашего) MyCalApp.

MyCalApp затем выдаст токен доступа для HireMe123. HireMe123 может использовать этот токен доступа для вызова MyCalApp API в рамках разрешенных вами разрешений и создания событий для вас с помощью MyCalApp API.

Ничего плохо больше не происходит! Пароль пользователя знает только MyCalApp. HireMe123 не запрашивает учетные данные пользователя. Проблемы с совместным использованием учетных данных и слишком большим доступом больше не являются проблемой.

А как насчет аутентификации?

На данный момент, я надеюсь, стало ясно, что OAuth предназначен для делегированного доступа. Это не распространяется на аутентификацию. В любой момент, когда аутентификация включалась в процессы, которые мы рассмотрели выше, вход в систему осуществлялся любым процессом входа в систему, который HireMe123 или MyCalApp реализовали по своему усмотрению. OAuth 2.0 не прописывал, как это должно быть сделано: он только покрывал авторизацию доступа сторонних API.

Так почему же аутентификация и OAuth так часто упоминаются вместе друг с другом?

Проблема входа в систему

То, что происходит после того, как OAuth 2.0 установил способ доступа к сторонним API, заключается в том, что приложение также требуется регистрировать пользователей у себя. Используя наш пример: HireMe123 нужно, чтобы пользователь MyCalApp мог залогиниться, используя свою учетную запись MyCalApp, даже несмотря на то, что он не был зарегистрирован в HireMe123.

Но, как мы упоминали выше, OAuth 2.0 предназначен только для делегированного доступа. Это не протокол аутентификации. Но это не помешало людям попытаться использовать его и для аутентификации, и это представляет проблему.

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

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

Например:

  • Кто-то мог украсть токен доступа у другого пользователя
  • Маркер доступа мог быть получен от другого клиента (не HireMe123) и введен в HireMe123

Это называется запутанной проблемой делегирования. HireMe123 не знает, откуда взялся этот токен и кому он был выдан. Если мы помним: аутентификация — это проверка того, что пользователь — это тот, кем он себя заявляет. HireMe123 не может знать это из-за того, что он может использовать этот токен доступа для доступа к API.

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

OpenID Connect

Это подводит нас к спецификации под названием OpenID Connect, или OIDC. OIDC — это спецификация OAuth 2.0, в которой говорится, как аутентифицировать пользователей. OpenID Foundation (OIDF) является руководителем стандартов OIDC.

OIDC — это уровень идентификации для аутентификации пользователей на сервере авторизации. Помните, что сервер авторизации выдает токены. Токены представляют собой закодированные фрагменты данных для передачи информации между сторонами (такими как сервер авторизации, приложение или API ресурса). В случае OIDC и аутентификации сервер авторизации выдает токены ID.

ID

Токены

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

OIDC объявляет фиксированный формат для токенов ID, которым является JWT.

JSON Web Token (JWT)

JSON Web Tokens, или JWT (иногда произносится как «jot»), состоит из трех URL-безопасных сегментов строки, соединенных точками. Сегмент заголовка, сегмента полезной нагрузки и крипто сегмента.

Сегмент заголовка

Первый сегмент является сегментом заголовка (header segment). Он может выглядеть примерно так:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9

Сегмент заголовка — это объект JSON, содержащий в закодирован виде алгоритм и тип токена. Он закодирован в base64Url (байтовые данные представлены в виде текста, который является URL-адресом и безопасным для имени файла).

Декодированный заголовок выглядит примерно так:

{
  "alg": "RS256",
  "typ": "JWT"
}
Сегмент полезной нагрузки

Второй сегмент — это сегмент полезной нагрузки (payload segment). Он может выглядеть так:

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0

Это объект JSON, содержащий фрагмент данных называемый claim, который содержат информацию о пользователе и событии аутентификации. Например:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

Оно также кодируется в base64Url.

Крипто сегмент

Последний сегмент — крипто сегмент (crypto segment) или подпись (signature). JWT подписаны, поэтому они не могут быть изменены в процессе использования. Когда сервер авторизации выдает токен, он подписывает его с помощью ключа.

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

Claim

Claim можно перевести как требование, утверждение или как заявление.

Теперь, когда мы знаем об анатомии JWT, давайте поговорим подробнее об claim, этом фрагменте данных из сегмента полезной нагрузки. Согласно его названию, токены ID предоставляют идентификационную информацию, которая присутствует в формуле claim.

Аутентификационный Claim

Начнем с информации о событии аутентификации. Вот несколько примеров:

{
   "iss": "https://{you}.authz-server.com",
    "aud": "RxHBtq2HL6biPljKRLNByqehlKhN1nCx",
    "exp": 1570019636365,
   "iat": 1570016110289,
   "nonce": "3yAjXLPq8EPP0S",
  ...
}

Некоторые строки аутентификации в токене ID включают:

  • iss (issuer — эмитент): издатель JWT, например, сервер авторизации
  • aud (audience — аудитория): предполагаемый получатель JWT; для идентификаторов токенов это должен быть идентификатор клиента приложения, получающего токен
  • exp (expiration time — время истечения): время истечения; идентификационный токен не должен быть принят после этого времени
  • iat (issued at time — время выпуска): время, когда выдан идентификационный токен

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

Идентификационные данные (Identity Claim)

Claim также включают информацию о конечном пользователе. Вот несколько примеров таких данных:

{
  "sub": "google-oauth3|102582972157289381734",
  "name": "Kim Maida",
  "picture": "https://gravatar[...]",
  "twitter": "https://twitter.com/KimMaida",
  "email": "[email protected]",
  ...
}

Некоторые из стандартных строк профиля в токене ID включают:

  • sub (subject): уникальный идентификатор пользователя; строка обязательна
  • email
  • email_verified
  • birthdate
  • etc.

После того как мы рассмотрели спецификации OAuth 2.0 и OpenID Connect пришло посмотреть, как применить наши знания в области идентификации.

Аутентификация с помощью ID токенов

Давайте посмотрим на OIDC аутентификацию на практике.

Обратите внимание, что это упрощенная схема. Есть несколько разных потоков в зависимости от архитектуры вашего приложения.

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

Затем клиентское приложение декодирует маркер идентификатора (который является JWT) и проверяет его. Это включает в себя проверку подписи, и мы также должны проверить данные claim. Вот некоторые примеры проверок:

  • issuer (iss): был ли этот токен выдан ожидаемым сервером авторизации?
  • audience (aud): наше приложение — целевой получатель этого токена?
  • expiration (exp): этот токен в течение допустимого периода времени для использования?
  • nonce (nonce): мы можем связать этот токен с запросом на авторизацию, сделанным нашим приложением?

После того как мы установили подлинность токена ID, пользователь проходит аутентификацию. Теперь у нас есть доступ к identity claims и мы знаем, кто этот пользователь.

Теперь пользователь аутентифицирован. Пришло время взаимодействовать с API.

Доступ к API с помощью токенов доступа

Мы немного поговорили о токенах доступа ранее, еще когда мы смотрели, как делегированный доступ работает с OAuth 2.0 и серверами авторизации. Давайте посмотрим на некоторые детали того, как это работает, возвращаясь к нашему сценарию с HireMe123 и MyCalApp.

Токены доступа

Токены доступа (Access Token) используются для предоставления доступа к ресурсам. С токеном доступа, выданным сервером авторизации MyCalApp, HireMe123 может получить доступ к API MyCalApp.

В отличие от токенов ID, которые OIDC объявляет как веб-токены JSON, токены доступа не имеют определенного формата. Они не должны быть (и не обязательно) JWT. Однако во многих решениях для идентификации используются JWT как маркеры доступа, поскольку есть готовый формат и он обеспечивает хорошую проверку.

В итоге HireMe123 получает два токена от сервера авторизации MyCalApp: токен идентификации (Token ID) (если проверка пользователя прошла успешна) и токен доступа (Access Token) для доступа к ресурсам конечному пользователю.

Токены доступа прозрачны для клиента

Токены доступа предназначены для API ресурса, и важно, чтобы они были прозрачны для клиента. Зачем?

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

Доступ к ресурсным API

Допустим, мы хотим использовать токен доступа для вызова API из одностраничного приложения. Как это выглядит?

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

Затем, когда наше приложение хочет взаимодействовать с API, мы присоединяем токен доступа к заголовку запроса, например, так:

# HTTP заголовок запроса
Authorization: 'Bearer eyj[...]'

Затем авторизованный запрос отправляется в API, который проверяет токен с помощью промежуточного программного обеспечения middleware. Если все проверено, то API возвращает данные (например, JSON) в приложение, запущенное в браузере.

Это замечательно, но есть кое-что, что может произойти с вами прямо сейчас. Ранее мы заявляли, что OAuth решает проблемы с излишним доступом. Как это решается здесь?

Делегирование со Scopes

Как API узнает, какой уровень доступа он должен предоставить приложению, запрашивающему использование его API? Мы делаем это с помощью scopes.

Scopes (Области действия) «ограничивают возможности приложения от имени пользователя». Они не могут предоставлять привилегии, которых у пользователя еще нет. Например, если у пользователя MyCalApp нет разрешения на создание новых корпоративных учетных записей MyCalApp, scopes, предоставленные HireMe123, также никогда не позволят пользователю создавать новые корпоративные учетные записи.

Scopes делегируют управление доступом к API или ресурсу. Затем API отвечает за объединение входящих scopes с фактическими правами пользователя для принятия соответствующих решений по управлению доступом.

Давайте рассмотрим это на нашем примере.

Я использую приложение HireMe123, и HireMe123 хочет получить доступ к стороннему API MyCalApp для создания событий от моего имени. HireMe123 уже запросил токен доступа для MyCalApp с сервера авторизации MyCalApp. Этот токен содержит некоторую важную информацию, такую как:

  • sub: (пользовательский ID на MyCalApp )
  • aud: MyCalAppAPI (то есть этот токен предназначен только для API MyCalApp)
  • scope: write: events (scope — область действия, в которой говорится, что HireMe123 имеет право использовать API для записи событий в мой календарь)

HireMe123 отправляет запрос в API MyCalApp с токеном доступа в своем заголовке авторизации. Когда MyCalApp API получает этот запрос, он может увидеть, что токен содержит scope write: events.

Но MyCalApp размещает учетные записи календаря для сотен тысяч пользователей. В дополнение к рассмотрению scope в токене, промежуточному программному обеспечению (middleware) API MyCalApp необходимо проверить sub идентификатор пользователя, чтобы убедиться, что этот запрос от HireMe123 может только использовать мои привилегии для создания событий с моей учетной записью MyCalApp.

В контексте делегированной авторизации scopes (области действия) показывают, что приложение может делать от имени пользователя. Они являются подмножеством общих возможностей пользователя.

Предоставление согласия

Помните, когда сервер авторизации спрашивал пользователя HireMe123 о его согласии разрешить HireMe123 использовать привилегии пользователя для доступа к MyCalApp?

Этот диалог согласия может выглядеть примерно так:

HireMe123 может запросить множество различных областей, например:

  • write:events
  • read:events
  • read:settings
  • write:settings
  • …etc.

В общем, мы должны избегать увеличения количества областей с правами пользователя. Тем не менее, можно добавить разные области для отдельных пользователей, если ваш сервер авторизации обеспечивает управление доступом на основе ролей (Role-Based Access Control — RBAC).

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

Ресурсы и что дальше?

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

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

Если вы хотите узнать больше, гораздо больше по этим темам, вот несколько полезных ресурсов для вас:

Выучить больше

Серия видеороликов Learn Identity в документах Auth0 — это лекционная часть нового учебного курса по найму для инженеров в Auth0, представленного главным архитектором Витторио Берточчи. Если вы хотите лично узнать, как это делается в Auth0, она абсолютно бесплатна и доступна для всех.

Спецификации OAuth 2.0 и OpenID Connect являются сложными, но как только вы ознакомитесь с терминологией и получите базовые знания об идентификации, они будут полезны, информативны и станут намного более удобочитаемыми. Почитать их можно здесь: The OAuth 2.0 Authorization Framework и OpenID Connect Specifications..

JWT.io — это ресурс о JSON Web Token, который предоставляет инструмент отладчика и каталог библиотек подписи/проверки JWT для различных технологий.

OpenID Connect Playground — это отладчик, который позволяет разработчикам шаг за шагом исследовать и тестировать вызовы и ответы OIDC.

Спасибо!

Если вы хотите пообщаться, я доступен в Твиттере на @KimMaida, и я также выступаю на конференциях и мероприятиях. Я надеюсь увидеть вас когда-нибудь, и большое спасибо за чтение!

Была ли вам полезна эта статья?

[18 / 4.9]

Spread the love

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

Edit me

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • API ключ
  • Basic Auth
  • HMAC
  • OAuth 2.0

API ключ

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

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

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

Basic Auth

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

Authorization: Basic bG9sOnNlY3VyZQ==

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

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

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

Authorization: Basic RnJlZDpteXBhc3N3b3Jk

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.

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

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

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

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

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

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

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

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

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

  • Learn API Technical Writing 2: REST for Writers (Udemy), Питера Грюнбаума;
  • OAuth simplified, Аарона Парецки.

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

В документации 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. Ответьте на следующие вопросы:

  • Какого рода авторизация требуется для отправки запросов к API?
  • Существуют ли разные уровни доступа в рамках авторизации (например, платные и бесплатные), которые определяют, сколько запросов можно сделать или какие типы информации можно получить?
  • Можно ли вы получить ключ API или какой-либо другой метод авторизации, необходимый для выполнения тестовых вызовов API?
  • Как информация об авторизации интегрируется в раздел “Начало работы”?

🔙

Go next ➡

Полное руководство с часто задаваемыми вопросами

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

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

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

  1. Что такое веб-аутентификация?
  2. Почему важна аутентификация веб-сайта?
  3. Как работает веб-аутентификация?
  4. Каковы распространенные методы проверки подлинности веб-сайтов?
  5. Какая форма веб-аутентификации является наиболее эффективной?
  6. Какие передовые методы проверки подлинности веб-сайтов можно использовать?

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

Готовы начать? Давайте прыгать!

1. Что такое веб-аутентификация?

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

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

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

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

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

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

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

2. Почему важна аутентификация на веб-сайте?

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

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

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

Эффективная веб-аутентификация обеспечивает лучший пользовательский опыт.

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

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

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

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

Эффективная веб-аутентификация защищает пользователей (и вас!) от утечки данных и обеспечивает безопасность данных пользователей.

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

Как вы вскоре увидите, пароли создают ненужные риски для безопасности по сравнению с беспарольными альтернативами, такими как решение Swoop для проверки подлинности электронной почты.

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

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

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

3. Как работает веб-аутентификация?

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

Взгляните на этот общий обзор процесса аутентификации веб-сайта:

  1. Пользователь попадает на страницу входа на веб-сайт, на котором он ранее создал учетную запись.
  2. Пользователь предоставляет свой уникальный идентификатор и ключ для подтверждения своей личности.
  3. Учетные данные для входа сравниваются с оригиналами, хранящимися на сервере веб-сайта.
  4. Если они совпадают, пользователь проходит аутентификацию и получает доступ к своей учетной записи.

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

4. Каковы распространенные методы аутентификации на веб-сайтах?

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

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

Факторы знаний

Факторы знаний просто требуют, чтобы пользователи подтвердили свою личность, используя часть информации, которую (в идеале) знали бы только они. Чаще всего это делается с помощью логина и пароля.

Однако часто имя пользователя заменяется адресом электронной почты пользователя, как в примере справа. Это часто более удобно для пользователя, хотя и не так безопасно.

Недостатки: Мы уже упоминали, что пароли далеко не самый безопасный вариант аутентификации на сайте. Большинство паролей просты и следуют хорошо известным шаблонам, что позволяет киберпреступникам легко их взломать. Кроме того, средний пользователь Интернета жонглирует более 90 онлайн-аккаунтов. Это может означать либо необходимость отслеживать почти сотню разных паролей (что крайне нереально), либо повторное использование паролей для нескольких учетных записей (что создает уязвимость для атаки).

Факторы владения

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

Недостатки: Физические предметы могут быть украдены или утеряны, что может представлять угрозу безопасности, если они окажутся в руках кого-либо, кроме предполагаемого пользователя. Кроме того, это может быть неудобно для пользователя, который должен носить с собой и отслеживать дополнительный элемент⁠, и может быть заблокирован в случае его потери или забвения.

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

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

Факторы наследования

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

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

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

5. Какая форма веб-аутентификации является наиболее эффективной?

Итак, при всех этих вариантах, как узнать, какой из них лучше всего подходит для вас и ваших пользователей? Важно взвесить все «за» и «против» каждого варианта в зависимости от ваших потребностей, но наше главное предложение — аутентификация по электронной почте.

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

Беспарольная аутентификация Swoop

Здесь, в Swoop, мы предлагаем два уникальных и инновационных решения для аутентификации электронной почты без пароля: Magic Link™ и Magic Message™. Давайте рассмотрим различия между ними.

Magic Link ™

Magic Link™ — это безопасная ссылка, которую Swoop отправляет конечному пользователю по электронной почте. Они просто вводят свой адрес электронной почты и щелкают ссылку, отправленную им, чтобы завершить цикл аутентификации. Затем пользователю предоставляется доступ к учетной записи.

Волшебное сообщение ™

Волшебное сообщение ™ — это защищенное электронное письмо, которое автоматически создается, когда они щелкают ссылку Swoop mailto в своем браузере. Аутентификация происходит, когда конечный пользователь отправляет электронное письмо. Давайте рассмотрим процесс шаг за шагом:

  1. Пользователь перенаправляется в сервис Swoop по протоколу OAuth 2.0 для аутентификации.
  2. В окне браузера пользователь нажимает кнопку «Отправить Magic Message™»: Эта кнопка активирует ссылку mailto, которая создает предварительно написанное электронное письмо для отправки пользователем.
  3. Пользователь отправляет электронное письмо: Вот где происходит волшебство. После отправки электронной почты сервер исходящей электронной почты генерирует и встраивает полностью зашифрованный цифровой ключ 1024/2048 бит в заголовок электронной почты. Сервер аутентификации Swoop следует криптографической процедуре с открытым ключом для расшифровки этого ключа. Каждое отправленное электронное письмо получает уникальный ключ для этого сообщения. Уровень безопасности этих зашифрованных ключей несравним с традиционными паролями.
  4. Пользователь вошел в свою учетную запись: Когда ключ расшифровывается и проходит все уровни проверки, сервер аутентификации Swoop указывает веб-сайту открыть учетную запись пользователя и начать сеанс. Все это происходит за считанные секунды и обеспечивает чрезвычайно упрощенный пользовательский интерфейс.

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

Чтобы узнать больше, посмотрите нашу демонстрацию. Просто нажмите «Войти» и следуйте инструкциям, чтобы испытать магию Swoop!

6. Каковы передовые методы аутентификации на веб-сайтах?

1. Изучите аутентификацию без пароля.

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

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

2. Поощряйте использование надежных паролей, если они используются.

Иногда пароли не могут быть полностью удалены с веб-сайта по какой-либо причине. В этом случае не забудьте поощрять (если не требовать) усиленные стандарты паролей на своем сайте.

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

Применяя эти стандарты (и запрещая распространенные ошибки), вы можете обеспечить более высокий уровень безопасности для своих пользователей.

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

3. Внедрить многофакторную аутентификацию.

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

Вот общий взгляд на процесс двухфакторной аутентификации, который дает краткий обзор необходимых шагов:

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

4. Интегрируйте аутентификацию единого входа.

Аутентификация единого входа (или SSO) — это еще один способ повысить безопасность и одновременно повысить удобство использования. Традиционно большинство веб-сайтов использовали многофакторный процесс входа, который требовал от пользователей повторного ввода своих учетных данных на каждом этапе или новом запросе.

Это может стать чрезвычайно повторяющимся и часто приводит к тому, что пользователи создают короткие и простые пароли, которые легче ввести повторно⁠, что, как вы уже догадались, представляет угрозу безопасности. Введите, процесс SSO.

Благодаря аутентификации Single Sign-On пользователи могут легко переходить из одного домена в другой без необходимости постоянно повторно подтверждать свою личность. Таким образом, они могут создавать более сложные (и безопасные) пароли, которые им нужно будет вводить только один раз за сеанс.

Типичным примером этого является набор инструментов Google. Когда пользователь успешно входит в свою учетную запись Gmail, он также может быстро открыть свой календарь, программное обеспечение для обработки текстов и хранилище документов.

5. Ограничьте количество попыток и сбросов пароля.

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

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

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

Для получения дополнительной информации ознакомьтесь с этими основными ресурсами:

  • 6 способов создать современный пароль и имя пользователя. Процесс входа в систему: обеспечение соблюдения стандартов паролей высшего уровня на вашем веб-сайте может повысить безопасность и значительно затруднить работу с неавторизованными пользователями. чтобы получить доступ. Ознакомьтесь с этими советами, чтобы обеспечить надежность пароля.
  • Три лучших альтернативных пароля для повышения безопасности веб-сайта. Многие организации начали внедрять альтернативные пароли для более эффективной проверки подлинности веб-сайта. Узнайте больше о наших трех лучших предложениях для входа без пароля.
  • 6 обязательных плагинов входа в WordPress [оценено и проверено!]: если ваша организация использует веб-сайт WordPress, плагины, вероятно, станут вашими лучшими друзьями. Взгляните на шесть наших любимых плагинов для упрощения и улучшения процесса входа в систему.

Объяснение методов веб-аутентификации — RisingStack Engineering

Мы заботимся о безопасности — недавно мы опубликовали Контрольный список безопасности Node.js. В качестве продолжения давайте углубимся в мир файлов cookie, токенов и других методов веб-аутентификации. Если вы хотите узнать больше об основных стратегиях аутентификации с помощью Passport.js, ознакомьтесь с нашим руководством для начинающих здесь.

Мы начнем с самого простого, HTTP Basic аутентификации , продолжим с куки  и токены , и в завершение подписей  и одноразовых паролей .

Методы аутентификации HTTP

Базовая аутентификация HTTP — это простой метод аутентификации, позволяющий клиенту предоставить имя пользователя и пароль при выполнении запроса.

Это самый простой способ обеспечить контроль доступа, поскольку он не требует файлов cookie, сеансов или чего-либо еще. Чтобы использовать это, клиент должен отправить Authorization вместе с каждым запросом, который он делает. Имя пользователя и пароль не зашифрованы, а составлены следующим образом:

  • имя пользователя и пароль объединены в одну строку: имя пользователя:пароль
  • эта строка закодирована с помощью Base64 закодированное значение

Пример для пользователя с именем john с паролем secret :

 curl --header "Авторизация: Basic am9objpzZWNyZXQ=" my-website.com

То же самое можно наблюдать и в Chrome:

Реализовать это довольно просто в Node.jsNode.js — это асинхронная управляемая событиями среда выполнения JavaScript, наиболее эффективная при создании масштабируемых сетевых приложений. Node.js свободен от блокировок, поэтому нет возможности заблокировать какой-либо процесс. также — следующий фрагмент показывает, как вы можете сделать промежуточное ПО Express для этого.

Конечно, вы можете сделать это на более высоком уровне, например, в nginx.

Выглядит просто, правда? Итак, каковы недостатки , использующие Базовую HTTP-аутентификацию ?

Минусы:

  • имя пользователя и пароль отправляются с каждым запросом, потенциально раскрывая их — даже если они отправляются через безопасное соединение
  • подключены к SSL/TLS, если веб-сайт использует слабое шифрование или сломайте его, имена пользователей и пароли будут немедленно раскрыты
  • нет возможности выйти из системы, используя базовую аутентификацию
  • Истечение срока действия учетных данных не является тривиальным — вы должны попросить пользователя сменить пароль, чтобы сделать это

Файлы cookie

Когда сервер получает HTTP-запрос в ответе, он может отправить заголовок Set-Cookie . Браузер помещает его в банку с файлами cookie, и файл cookie будет отправляться вместе с каждым запросом к тому же источнику в заголовке Cookie  HTTP.

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

Всегда использовать файлы cookie HttpOnly

Чтобы снизить вероятность XSS-атак, всегда используйте флаг HttpOnly при настройке файлов cookie. Таким образом, они не будут отображаться в document.cookies .

Всегда использовать подписанные файлы cookie

С подписанными файлами cookie сервер может определить, был ли файл cookie изменен клиентом.

Это можно наблюдать и в Chrome — сначала посмотрим, как сервер устанавливает куки:

В дальнейшем все запросы используют куки, установленные для данного домена:

Минусы:

  • Необходимо приложить дополнительные усилия для смягчения CSRF-атак
  • Несовместимость с REST — поскольку он вводит состояние в протокол без сохранения состояния тем не менее стоит взглянуть на потенциальные проблемы безопасности.

    Сначала давайте посмотрим, что такое JWT!

    JWT состоит из трех частей:

    • Заголовок, содержащий тип токена и алгоритм хеширования
    • Полезная нагрузка, содержащая утверждения
    • Подпись, которую можно рассчитать следующим образом, если вы выбрали HMAC SHA256:  HMACSHA256( base64UrlEncode(заголовок) + ". " + base64UrlEncode(полезная нагрузка), секрет)

    Добавление JWT в Koa application — всего пара строк кода:

    Пример использования —  (чтобы проверить действительность/содержимое токена, вы можете использовать jwt.io) :

     curl --header "Авторизация: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ" my-website.com

    Как и предыдущие, токены можно наблюдать и в Chrome:

    Если вы пишете API для нативных мобильных приложений или SPA, JWT может подойти. Следует иметь в виду одну вещь: чтобы использовать JWT в браузере, вы должны хранить его либо в LocalStorage, либо в SessionStorage, что может привести к XSS-атакам.

    Минусы:

    • Необходимо приложить дополнительные усилия для смягчения последствий XSS-атак

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

    Возможный способ решения этой проблемы — по крайней мере, когда мы говорим об API, а не о браузере — подписывать каждый запрос. Как это работает?

    Когда потребитель API делает запрос, он должен подписать его, то есть создать хэш из всего запроса с использованием закрытого ключа. Для этого расчета хэша вы можете использовать:

    • Метод HTTP
    • Путь запроса
    • Заголовки HTTP
    • Контрольная сумма полезной нагрузки HTTP
    • и закрытый ключ для создания хэша

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

    Процесс подписания запроса AWS — источник

    Зачем выполнять все эти шаги? Потому что даже если транспортный уровень будет скомпрометирован, злоумышленник сможет только читать ваш трафик, не сможет действовать как пользователь , так как злоумышленник не сможет подписывать запросы — так как закрытый ключ не находится в его/ ее владения. Большинство сервисов AWS используют этот тип аутентификации.

    node-http-signature связан с подписью HTTP-запросов, и его стоит проверить.

    Минусы:

    • нельзя использовать в браузере/клиенте, только между API

    Одноразовые пароли

    Алгоритмы одноразовых паролей генерируют одноразовый пароль с общим секретом и либо текущим временем, либо счетчиком:

    • Время- Алгоритм одноразового пароля на основе текущего времени
    • Алгоритм одноразового пароля на основе HMAC на основе счетчика.

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

    В Node.js реализовать это с помощью notp относительно просто.

    Минусы:

    • с общим секретом (в случае кражи) пользовательские токены можно эмулировать
    • , потому что клиенты могут быть украдены / пойти не так, как надо, у каждого приложения реального времени есть способы обойти это, например сброс электронной почты, который добавляет дополнительные векторы атаки на приложение

    Какой метод аутентификации выбрать, когда?

    В этой статье мы обсудили несколько типов методов аутентификации для веб-приложений:

    Если вам нужно поддерживать только веб-приложение, подойдут либо файлы cookie, либо токены — для файлов cookie подумайте о XSRF, для JWT позаботьтесь о XSS.

    This entry was posted in Популярное