Не стоит создавать собственные решения для аутентификации пользователей / Хабр

Что такое аутентификация?

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

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

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

Начало

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

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

Основные поля

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

▍использование сервисов аутентификации пользователей не всегда бесплатно, особенно — для крупных проектов

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

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

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

Формы для регистрации в проекте и для входа в него — это лишь одна сторона «медали» системы аутентификации. Разработчику, создавая подобную систему, придётся решить гораздо больше задач, чем разработка пары форм.

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

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

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

То, что правильное управление паролями, это — непростая задача, не должно никого удивлять. А вы знали о том, что управление именами пользователей — это тоже сложно? Например, тот факт, что имена пользователей выглядят одинаково, ещё не означает, что система, при их сравнении, сочтёт их таковыми.

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

▍я — очень опытный разработчик, поэтому знаю о том, как создать безопасную систему аутентификации

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

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

Авторизация по номеру телефона

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

Плюсы: простота авторизации, минимум запрашиваемых у пользователя данных, сразу получаете достоверный номер телефон.

Минусы: не подходит для приложений, которые используют миллионы, рассылка SMS требует затрат. По состоянию на 01.04.2021 средняя стоимость SMS 3,5-4 рубля.

Авторизация с применением только номера телефона очень проста, но может быть использована, если количество пользователей приложения не превышает несколько сотен. Лучше если аудитория приложения локализована в рамках одной страны. Например, России. Это связано с необходимостью рассылки SMS.

Нет необходимости реализовывать процедуру восстановления пароля (сброс пароля), так как пароль не используется.

Смена номера телефона для пользователя не доступна. Сменить номер телефона пользователя может только администратор через Админ панель.

Авторизация по номеру телефона и паролю

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

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

Авторизация через Google-аккаунт

В данный момент такой вид авторизации в мобильных приложениях распространяемых в России встречается редко.

Cookies

Наверное вы часто слышали термин Cookies – это маленький фрагмент данных, которые система (сервер) хранит у пользователя. Каждый раз, когда пользователь открывает сайт – серверу отправляются данные Cookies, которые сервер сохранил у пользователя на устройстве.

Вы можете проектировать свои интерфейсы как с сохранением сессий пользователей, так и без сохранения.

Dropbox

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

Forms authentication

Google

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

Idaas

К счастью, у современного веб-разработчика нет необходимости в развёртывании собственной системы для аутентификации пользователей и для управления ими. Сейчас, в 2020 году, существует множество хороших IDaaS-решений (Identity as a Service, идентификация как сервис). Применение таких решения значительно упрощает оснащение веб-проектов возможностями по аутентификации пользователей.

Вот несколько популярных IDaaS-проектов (в алфавитном порядке): Auth0, Azure AD, Google Identity Platform и Okta.

Macos

Потребуется версия операционной системы El Capitan или выше.

Щёлкните по иконке яблока в верхнем левом углу экрана, выберите «Системные настройки» → iCloud → «Учётная запись». Можно ускорить процесс, введя слово iCloud в поиске Spotlight. Затем щёлкните по значку «Безопасность» и включите двухфакторную аутентификацию.

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

Microsoft

Войдите в аккаунт Microsoft и откройте меню «Безопасность». Внизу страницы согласитесь ознакомиться с дополнительными мерами безопасности и нажмите «Настройка двухшаговой проверки». Далее просто следуйте пошаговой инструкции.

Pinterest

Перейдите в настройки браузерной версии Pinterest и пролистайте до раздела «Безопасность». Там активируйте функцию «Запрашивать код при входе». Вам сразу же дадут резервный код восстановления на случай, если вы потеряете телефон или не сможете получить доступ к приложению для аутентификации.

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

Telegram

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

Whatsapp

Откройте настройки приложения через меню справа вверху. В разделе «Аккаунт» есть кнопка «Двухшаговая проверка». Нажмите на неё. Мессенджер попросит придумать шестизначный код, подтвердить его и добавить адрес электронной почты для сброса пин-кода и защиты аккаунта.

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

Авторизация через соцсети appmaster.io

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

В чем их особенность? Прежде всего, в простоте настройки. Только для модуля LinkedIn нужно указать Секрет клиента, URL перенаправления и ID клиента. Для остальных модулей достаточно ID клиента или приложения — в зависимости от модуля.

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

Если не хотите ждать — пишите в телеграм-чат сообщества AppMaster.io, чтобы напрямую задать вопросы нашим разработчикам.

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

Для всего остального, не перечисленного выше, рекомендуется использовать приложения-аутентификаторы. Они служат хранилищами кодов, к которым можно получить доступ без интернета. Среди самых популярных вариантов — Authy и Google Authenticator.

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

Взгляд сверху

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

Вконтакте

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

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

Выбор способа авторизации

Для выбора способов авторизации надо ответить на следующие вопросы.

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

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

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

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

Для кого эта статья

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

Запрос на аутентификацию

Authentication/Token Request — процесс запроса аутентификации.

В зависимости от того какие области (scopes) запрошены, сервис выдачи токенов вернет:

1. Только Identity Token, если запрошены только Identity scopes.
2. Identity Token и Access Token, если запрошены также и Resources scopes.
3. Access Token и Refresh Token, если запрошeн Offline Access.

Более подробно про процесс аутентификации можно прочесть в разделе «

Использование openid connect в клиент-серверных приложениях

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

На сайте jwt.io можно найти исчерпывающий список библиотек, которые можно использовать для верификации JWT-токенов.

Для некоторых стеков технологий, кроме того, можно воспользоваться решениями более высокого уровня. Например — это, в среде Node.js/Express, express-jwt или passport.

Использование openid connect на статических сайтах или в нативных приложениях

Статические веб-приложения (их ещё называют «JAMstack-сайтами») и нативные приложения (то есть — настольные или мобильные приложения) тоже могут пользоваться OpenID Connect, но делается это немного не так, как в случае с обычными веб-проектами. В спецификации OAuth 2.0 это называется «implicit flow», или получение токена доступа напрямую от пользователя.

При таком подходе не нужно использовать механизм, в котором применяется секретный ключ (Client Secret). Дело в том, что приложение выполняется на клиенте, поэтому не существует безопасного способа распространения подобных ключей. Здесь применяется следующая последовательность действий:

1. Приложение перенаправляет пользователя на аутентификационную конечную точку, проверяя, чтобы строка запроса содержала бы scope=id_token.
2. Пользователь выполняет аутентификацию, пользуясь возможностями поставщика идентификационной информации.
3. Пользователя перенаправляют к приложению, JWT-токен сессии прикрепляется к URL страницы в виде URL-фрагмента (URL-фрагмент — это то, что следует за знаком #). Он находится в поле, называемом id_token.
4. Приложение получает JWT-токен из URL-фрагмента и проверяет его. Если токен успешно проходит проверку, пользователь считается аутентифицированным, а это значит, что приложение может использовать сведения о пользователе из токена.

Для того чтобы проверить JWT-токен в статическом веб-приложении можно использовать модуль

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

При разработке клиент-серверных проектов, таких, как статические веб-ресурсы или нативные приложения, важно обеспечить то, чтобы токен был бы подписан с использованием RSA-SHA256 (в заголовке токена alg должно быть записано RS256).

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

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

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

Какие механизмы аутентификации пользователей применяете вы?

Как это работает

Общий механизм такой:

Клиент

Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «

» у которого клиент запрашивает токен для доступа).

Недостатки регистрации через соцсети

Конечно, они тоже есть:

Область (scope)

Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес

в составе

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

Scopes бывают двух видов:

1. Identity scopes — это запрос информации о пользователе. Его имя, профиль, пол, фотография, адрес электронной почты и т. д.
2. Resource scopes — имена внешних ресурсо (Web APIs), к которым клиент хочет получить доступ.

Плагины, виджеты, модули

Варианты, отлично подходящие для решений, созданных на CMS / no-code платформах. Функция авторизации и регистрации необходима как для сайтов, так и для приложений — неважно web или mobile — поэтому даже на непопулярных платформах можно найти множество вариантов, особенно если ваше комьюнити достаточно активно.

Правила разработчиков

Какой бы вариант вы не выбрали, стоит придерживаться основных правил.

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

Процесс восстановления пароля

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

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

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

1. Регистрация (CREATE) – создание в системе вашей личной учётной записи

2. Авторизация (READ) – получение доступа к вашей личной учётной записи

3. Восстановление доступа к учётной записи (UPDATE) – если вы на пример забыли пароль – то его можно сменить, подтвердив свою личность.

4. Удаление (DELETE) – удаление вашей учётной записи из системы

Разбираемся детально ху из ху

В данный момент на слуху следующие протоколы:

1. OpenID — для проверки учетных данных пользователя (identification & authentication).
2. OAuth — про то, чтобы получать доступ к чему-то.
3. OpenID Connect — и про и то, и про другое одновременно.

С чего начать?

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

Для начала — хорошая новость. Она заключается в том, что все четыре вышеперечисленных провайдера (Auth0, Azure AD, Google Identity Platform, Okta), да и многие другие, используют одни и те же протоколы: OpenID Connect / OAuth 2.0. Это — современные стандартные протоколы, клиентские библиотеки для поддержки которых существуют практически для всех языков программирования и фреймворков.

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

1. Зарегистрируйте приложение у поставщика идентификационной информации. Вам, после регистрации, выдадут идентификатор (Application ID, Client ID) и секретный ключ (Secret Key, Client Secret).
2. Задайте разрешения, необходимые вашему приложению. В дополнение к тому, что приложению будет доступен профиль пользователя, вы, что зависит от выбранного провайдера, сможете получить доступ к гораздо большему объёму данных. Сюда может входить, например, доступ к сообщениям пользователей и доступ к их облачному хранилищу (например — через Office 365 или G Suite).
3. Интегрируйте клиентскую библиотеку сервиса аутентификации в свой проект.

Я не стану пытаться рассказать в подробностях о том, как именно работает механизм OpenID Connect. Но, в целом, работа с сервисами аутентификации выглядит так:

1. Приложение перенаправляет пользователя на страницу провайдера аутентификации.
2. Пользователь аутентифицируется и перенаправляется на страницу вашего приложения.
3. Приложение получает JWT-токен.

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

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

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

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

Самостоятельно

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

Сервис выдачи токенов

Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.

Основные функции:

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

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

Токен личности

Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.

Токен обновления

Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.

Более подробно о составе токенов в разделе «структура токена».

Упрощённое объяснение термина “сессия”

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

Для того что бы различать входы с различных устройств – каждой сессии присваивается свой уникальный для каждой авторизации номер (Токен), который хранится в Cookies. Это нужно для того, что бы при выходе (закрытии сессии) с одного из устройств вы не выходили из своей учёной записи во всех остальных устройствах.

Формат

Чем больше пользователей — тем безопаснее решение

Большинство поставщиков идентификационной информации предлагаю дополнительные возможности, касающиеся безопасности. Такие, как поддержка многофакторной аутентификации (MFA, multi-factor authentication), поддержка сертификатов безопасности или ключей (в том числе — U2F, FIDO2,

и прочее подобное).

Не стоит недооценивать важность этих технологий. В соответствии с отчётом Microsoft, включение MFA позволяет предотвратить до 99,9% атак на учётные записи.

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

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

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

Через специальные сервисы

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

Заключение

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

Надеюсь вам было полезно, и хоть немного интересно.

Заключение первой части

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

Stay tuned.

public void Configuration(IAppBuilder app)
{
    var factory = new IdentityServerServiceFactory();
    factory.UseInMemoryClients(Clients.Get())
           .UseInMemoryScopes(Scopes.Get())
           .UseInMemoryUsers(Users.Get());

    var options = new IdentityServerOptions
    {
        SiteName = Constants.IdentityServerName,
        SigningCertificate = Certificate.Get(),
        Factory = factory,
    };

    app.UseIdentityServer(options);
}

public void Configuration(IAppBuilder app)
{
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = "Cookies"
    });

    app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
    {
        ClientId = Constants.ClientName,
        Authority = Constants.IdentityServerAddress,
        RedirectUri = Constants.ClientReturnUrl,
        ResponseType = "id_token",
        Scope = "openid email",
        SignInAsAuthenticationType = "Cookies",
    });
}

public void Configuration(IAppBuilder app)
{
    app.UseIdentityServerBearerTokenAuthentication(
        new IdentityServerBearerTokenAuthenticationOptions
        {
            Authority = Constants.IdentityServerAddress,
            RequiredScopes = new[] { "write" },
            ValidationMode = ValidationMode.Local,

            // credentials for the introspection endpoint
            ClientId = "write",
            ClientSecret = "secret"
        });

    app.UseWebApi(WebApiConfig.Register());
}