HTTP — механизмы аутентификации

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

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

HTTP предлагает два протокола аутентификации:

• Обычная проверка подлинности
• Дайджест-проверка подлинности

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

Структура аутентификации запроса/ответа

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

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

Связанные с аутентификацией заголовки запросов/ответов

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

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

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

Области безопасности

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

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

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

/admin/statistics/financials.txt -> Realm = «Статистика администратора»

/images/img1.jpg -> Realm = «Изображения»

Когда вы пытаетесь получить доступ к financials.txt, сервер запрашивает у вас данные для авторизации, и ответ будет выглядеть следующим образом:

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="Admin Statistics"

Пример простой HTTP-аутентификации

Теперь давайте объединим точки, рассмотрев простейший пример проверки подлинности по протоколу HTTP (обычная проверка подлинности, описанная ниже):

1. Пользовательский клиент -> Сервер

Пользователь запрашивает доступ к изображению на сервере.

GET /gallery/personal/images/image1. jpg HTTP/1.1
Host: www.somedomain.com

1. Сервер -> Пользовательский клиент

Сервер отправляет пользователю запрос.

HTTP/1.1 401 Access Denied
WWW-Authenticate: Basic realm="gallery"

3. Пользовательский клиент -> Сервер

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

GET /gallery/personal/images/image1.jpg HTTP/1.1
Authorization: Basic Zm9vOmJhcg==

4. Сервер -> Пользовательский клиент

Сервер проверяет учетные данные и отправляет статус 200 OK, код и данные изображения.

HTTP/1.1 200 OK
Content-type: image/jpeg
...<image data>

Не все так сложно, правда?

Теперь давайте перейдем к базовой аутентификации.

Базовая проверка подлинности (Basic)

Самый распространенный и поддерживаемый протокол. Он существует с HTTP/1.0, и каждый крупный клиент его реализует.

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

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

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

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

GET /gallery/personal/images/image1.jpg HTTP/1.1
Authorization: Basic Zm9vOmJhcg==

«Zm9vOmJhcg ==» из этого примера — не что иное, как строка «foo: bar» в кодировке Base64.

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

Хуже того, кодирование имени пользователя и пароля не поможет. Третья злонамеренная сторона по-прежнему может отправить зашифрованную последовательность для достижения того же эффекта.

Также отсутствует защита от прокси или любого другого типа атак, которые изменяют тело запроса и оставляют заголовки запроса нетронутыми.

Итак, как видите, обычная аутентификация — это далеко не идеальный механизм аутентификации.

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

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

Некоторые утверждают, что безопасность зависит от вашего транспортного механизма.

Дайджест-аутентификация (Digest)

Дайджест-аутентификация — более безопасная и надежная альтернатива простой, но небезопасной базовой аутентификации.

Итак, как это работает?

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

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

Пример Digest Authentication

1. Пользовательский клиент -> Сервер

GET /dir/index.html HTTP/1.0
Host: localhost

Клиент отправляет неаутентифицированный запрос.

2. Сервер -> Пользовательский клиент

HTTP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="[email protected]",
                        qop="auth,auth-int",
                        nonce="cmFuZG9tbHlnZW5lcmF0ZWRub25jZQ",
                        opaque="c29tZXJhbmRvbW9wYXF1ZXN0cmluZw"
Content-Type: text/html
Content-Length: 153
<!DOCTYPE html>
  
    <meta charset="UTF-8" />
    <title>Error</title>
  
  
    <h2>401 Unauthorized. </h2>
  

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

3. Пользовательский клиент -> Сервер

GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Gandalf",
                     realm="[email protected]",
                     nonce="cmFuZG9tbHlnZW5lcmF0ZWRub25jZQ",
                     uri="/dir/index.html",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="5a1c3bb349cf6986abf985257d968d86",
                     opaque="c29tZXJhbmRvbW9wYXF1ZXN0cmluZw"

Клиент вычисляет значение ответа и отправляет его вместе с именем пользователя, областью, URI, nonce, opaque, qop, nc и cnonce. Много всего.

Подробное объяснение

Давайте определим это:

• nonce и opaque — определенные сервером строки, которые клиент возвращает после их получения.
• qop (качество защиты) — одно или несколько предопределенных значений («auth» | «auth-int» | токен). Эти значения влияют на вычисление дайджеста.
• cnonce — одноразовый номер клиента, должен генерироваться, если задано qop. Он используется, чтобы избежать атак на выбранный открытый текст и предоставить сообщению защиту целостности.
• nc — счетчик одноразовых номеров, должен быть отправлен, если задано qop. Эта директива позволяет серверу обнаруживать повторы запросов, сохраняя свою собственную копию этого счетчика — если одно и то же значение nc появляется дважды, то запрос является повтором.

Атрибут ответа рассчитывается следующим образом:

HA1 = MD5("Gandalf:[email protected]:Lord Of The Rings")
       = 681028410e804a5b60f69e894701d4b4
HA2 = MD5("GET:/dir/index.html")
       = 39aff3a2bab6126f332b942af96d3366
Response = MD5( "681028410e804a5b60f69e894701d4b4:
                 cmFuZG9tbHlnZW5lcmF0ZWRub25jZQ:
                 00000001:0a4f113b:auth:
                 39aff3a2bab6126f332b942af96d3366" )
         = 5a1c3bb349cf6986abf985257d968d86

Если вам интересно узнать, как вычислить ответ в зависимости от qop, вы можете найти его в RFC 2617.

4. Сервер -> Пользовательский клиент

HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 2345
... <content data>

Сервер вычисляет хэш самостоятельно и сравнивает их. Если они совпадают, он передает клиенту запрошенные данные.

Краткое резюме

Как видите, дайджест-аутентификацию сложнее понять и реализовать.

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

Итак, вкратце дайджест-аутентификация:

• Не отправляет пароли в виде обычного текста по сети.
• Предотвращает повторные атаки
• Защита от подделки сообщений

Некоторые из слабых мест:

• Уязвимость к атаке «человек посередине».
• Многие параметры безопасности не требуются, и поэтому дайджест-проверка подлинности будет менее безопасной, если не задана.
• Предотвращает использование надежных алгоритмов хеширования паролей при хранении паролей.

В связи с этим дайджест-аутентификация пока не получила широкого распространения. Базовая аутентификация намного проще и в сочетании с SSL еще более безопасна, чем дайджест-аутентификация.

Заключение

Мы рассмотрели различные механизмы аутентификации, которые HTTP предлагает по умолчанию, и обсудили их преимущества и недостатки.

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

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

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

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, и я также выступаю на конференциях и мероприятиях. Я надеюсь увидеть вас когда-нибудь, и большое спасибо за чтение!

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

[19 / 4.9]

Spread the love

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

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

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

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

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) — это еще один способ повысить безопасность и одновременно повысить удобство использования. Традиционно большинство веб-сайтов использовали многофакторный процесс входа, который требовал от пользователей повторного ввода своих учетных данных на каждом этапе или новом запросе.

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

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

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

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

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

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

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

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

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

Цены — Auth0

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

Мы обеспечим успех вашей компании с первого дня.

Вы некоммерческая организация? Узнайте, имеете ли вы право →

100010 000+

1 000

B2C — Essentials

Лучше всего подходит для простых проектов или приложений.

$23/мес

До 10 000 внешних MAU

Неограниченное количество социальных связей

Пользовательские домены

Управление ролями пользователей

5 действий

Кредитная карта не требуется.

240 долл. США/мес.

До 10 000 внешних MAU

Pro MFA

Внешние базы данных

Роли администратора

10 действий 0007

Кредитная карта не требуется

Кредитная карта не требуется требуется

Enterprise

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

Настраиваемое подключение и уровни пользователей

Нет ограничений администратора или действий

99,99% SLA и поддержка предприятия

Дополнительные параметры развертывания

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

Что такое управление идентификацией и когда лучше создавать, а когда покупать? Загрузите эту бесплатную всеобъемлющую электронную книгу на 22 страницах.

Загрузить технический документ

Токены Machine to Machine

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

Начиная с

20 долларов США в месяц

Защита от атак

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

Enterprise MFA

Enterprise MFA позволяет доставлять одноразовые коды с помощью SMS/голоса/электронной почты, а также с помощью WebAuthn и push-уведомлений в приложение Auth0 Guardian или ваше приложение White Label.

HIPAA BAA и PCI

Auth0 может обеспечить соответствие нескольким стандартам, включая HIPAA, посредством соглашения о деловом партнерстве и сред, совместимых с PCI.

Планы Premier Success

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

Adaptive MFA

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

Частное облако

Простая выделенная модель развертывания Auth0 для повышения производительности, безопасности и соответствия требованиям по сравнению с нашим стандартным общедоступным облаком.

Почему я должен доверять пользователям Auth0?

Безопасность — наш главный приоритет. Во-первых, мы следуем передовым методам безопасности для хранения учетных данных пользователей: они никогда не хранятся в виде простого текста, а все пароли хэшируются и солируются с использованием алгоритма bcrypt, современного алгоритма, разработанного для предотвращения атак грубой силы даже в случае нарушения. Кроме того, наша реализация TLS получила оценку «A+» в тесте Qualsys SSL Labs SSL Server.
Мы также внедряем упреждающие меры безопасности для ваших проектов, такие как обнаружение взлома паролей, использование огромной базы данных утечек паролей и обнаружение атак методом грубой силы. Также применяются автоматизированные проверки ограничения скорости и процедуры смягчения последствий отказа в обслуживании.
Вы можете узнать больше о безопасности на Auth0 на нашей странице безопасности.

Что произойдет, если я перестану использовать Auth0? Как я узнаю, что данные моего пользователя в безопасности?

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

Если я превыслю 7000 пользователей бесплатного плана, нужно ли мне выбирать платный план с более высокой квотой MAU?

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

Какие существуют модели развертывания?

Auth0 может работать как сторонняя служба в общедоступном облаке Auth0 или в изолированном частном развертывании. В частности, Auth0 поддерживает четыре различных типа развертывания:

• Общедоступное облако : мультиарендатор (общий экземпляр)
• Private Cloud Basic : выделенный вариант, основанный на производительности и управлении общедоступного облака, который удовлетворяет конкретные потребности в хранении данных
• Производительность частного облака : Включает все возможности Private Cloud Basic и увеличивает количество запросов в секунду (RPS) до 500, а также включает параметры для управления обновлением, нагрузочного тестирования и надстройки GEO-HA.
• Private Cloud Performance Plus : включает все возможности Private Cloud Performance и увеличивает количество запросов в секунду до 1500

Какое время работы и состояние Auth0? Системы

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

Как долго длится моя пробная версия?

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

Есть ли у вас специальные предложения для стартапов?

Да, Auth0 и наша партнерская сеть хотят, чтобы вы добились успеха! Мы предоставляем специальный план для стартапов, который включает в себя 100 000 внешних активных пользователей в месяц, поставщиков корпоративных удостоверений, Pro MFA и защиту паролем, а также SSO для панели инструментов Auth0 бесплатно в течение всего года.

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