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

Введение

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

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

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

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

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

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

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

• : (пользовательский ID на MyCalApp )
• :  (то есть этот токен предназначен только для API MyCalApp)
• : 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 может запросить множество различных областей, например:

• …etc.

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

Файл-ключ

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

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

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

Совет

Не стоит использовать большие файлы в качестве файла-ключа – это бессмысленно.

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

Совет

Маскируйте файлы-ключи под обычные файлы.

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

Как можно подтвердить свою личность?

Большинство приложений и сервисов предлагают пользователю на выбор такие варианты двойной аутентификации:

• Ввести код, который пользователь получает в SMS или email, после того, как он ввел логин и пароль. Это самый распространенный и простой способ, но у него есть свои недостатки: например, SMS с паролем могут перехватить через уязвимость в протоколе , через который они передаются.
• Ввести код, который генерируется в отдельном приложении-аутентификаторе. Специалисты называют этот способ более надежным , к тому же он остается доступен пользователю, даже если у него нет мобильной связи. Чтобы им воспользоваться, нужно сначала установить одно из таких приложений (например, Google Authenticator, Twilio Authy, Duo Mobile, «Яндекс.Ключ»), а потом выбрать в меню нужного сервиса (например, Facebook) вариант двойной аутентификации через приложение. На экране появится QR-код, который нужно будет отсканировать через это приложение — и им сразу можно пользоваться.
• Многие сервисы (например, Facebook и «ВКонтакте») также генерируют для пользователя некоторое количество резервных кодов, которые он может использовать в случае, если у него не будет мобильной связи или он потеряет телефон. Для этого нужно заранее распечатать или сохранить эти коды в надежном месте.

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

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

Гарантирует ли двухфакторная аутентификация абсолютную безопасность?

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

Что, если второе устройство потеряли?

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

I know, I have, I am

Комментируя приведенную таблицу, Ирина Гуськова, начальник отдела сетевых услуг Orange Business Services, выделяет три основных фактора аутентификации.

1. То, что мы знаем (I know), — как правило, это пароль, ключевое слово, PIN-код банковской или SIM-карты. Аутентификацию по этому фактору легко внедрить, но и легко взломать — украденная запись или файл.

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

3. То, чем мы являемся (I am), – биометрика. Наши физические особенности: отпечатки пальцев, форма и объем рук, лица, тембр голоса, рисунок сетчатки глаза и т.д. Самый развивающийся на данный момент способ аутентификации, начиная с дактилоскопических сканеров на телефоне и заканчивая спектроанализаторами голоса.

Как правило, первые два фактора сами по себе, так или иначе, могут быть скомпрометированы, а внедрение третьего фактора (I am) — весьма дорогостоящая процедура, которая не всегда уместна: ставить дактилоскоп для покупки пачки сигарет — мера избыточная. Поэтому выбор стратегии аутентификации напрямую зависит от критичности систем и операций, для которых требуется аутентификация.

Для систем, не критичных для бизнеса (справочно-информационные порталы, персонализированные порталы новостных агрегаторов и т.д.), достаточно использовать один фактор, при этом фактора «I know» вполне достаточно, а использование фактора «I have» — дополнительная гарантия безопасности для конечного пользователя.

Для систем, взлом которых может оказать существенное влияние на бизнес компании или его клиента, использования фактора «I know» уже недостаточно, нужен как минимум более стойкий фактор «I have». Но лучше и надежнее — сочетание двух факторов. Двухфакторная аутентификация внедряется сейчас повсеместно — начиная от публичных почтовых сервисов (такую услугу предлагают Google, Yahoo, Yandex и другие) и заканчивая крупными компаниями, организующими доступ удаленных сотрудников в корпоративную сеть.

Наиболее перспективными факторами сейчас считаются биометрическая, многофакторная облачная аутентификация, а также строгая форма аутентификации. Что касается биометрии, «Банковское обозрение» 10 февраля 2017 года проводит конференцию «Удаленная идентификация и биометрия в финансовой отрасли: регулирование, технологии, решения», где будет подробно рассмотрено все, что имеет отношение к биометрии. Сейчас же коротко остановимся на двух оставшихся перспективных направлениях.

Аутентификация с использованием телефона (двухэтапная аутентификация)

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

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

Этот метод требует только того, чтобы пользователь ответил на Push-уведомление, которое приходит прямо на его мобильное устройство. Из подобных решений можно отметить Secret Double Octopus.

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

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

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

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

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

Таблица с кодами

Таблица с кодами – способ дополнительной защиты, когда вам выдается таблица с нумерованными кодами. При авторизации запрашивается какой-либо код из таблицы.

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

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

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

Что такое Идентификация

Это еще одна из встроенных функций для входа на сервис либо в приложение.

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

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

В целом процедура идентификации и процедура аутентификации напрямую зависят друга от друга. Успешное завершение этих операций подразумевает доступ к запрашиваемой системе — авторизация.

Регистрируясь на каком-либо сайте либо в приложении вы получаете номер либо имя – логин – который и является идентификатором.

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

• Серия и номер паспорта.
• Номер мобильного телефона.
• Адрес электронной почты.
• Номер аккаунта в социальной сети.
• Номер банковской карточки.
• Номер машины.
• IMEI телефона.
• Другое.

Какие могут быть Ошибки

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

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

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

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

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

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

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

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

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

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

Однако также мы можем сказать, что они не могут существовать друг без друга.

Использование двухфакторной аутентификации для защиты вашей учетной записи Google

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

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

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

1. Перейдите в “Настройки” > “Google” > “Аккаунт Google”
2. Найдите вкладку “Безопасность”
3. Выберите пункт “Двухфакторная аутентификация” и войдите в аккаунт
4. Укажите свой номер телефона и/или адрес электронной почты на тот случай, если вам потребуется восстановить аккаунт

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

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

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

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

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

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

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

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

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

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

Новая учётная запись Apple ID

Новая учётка Apple ID несёт в себе массу проблем, так что не рекомендую её заводить

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

Однако создание нового аккаунта чревато рядом серьёзных неудобств, которые вам придётся понести:

• Весь купленный софт останется на старом аккаунте;
• Все подписки, которые у вас оформлены, придётся оформлять заново по новым ценам;
• Придётся переносить все свои пароли из iCloud;
• Придётся переносить все данные из облака iCloud;
• Изменятся контакты для связи по iMessage и FaceTime;
• Придётся перепривязать все свои устройства к новому Apple ID.

Как видите, неудобств довольно много. И ради чего всё это? Ради того, чтобы не вводить 6 цифр после ввода основного пароля, которые только для того и нужны, чтобы уберечь вас от взлома? На мой взгляд, сомнительная перспектива. Да, возможно, двухфакторная аутентификация не очень удобна, и её можно было улучшить или по крайней мере как-нибудь упростить. Например, не запрашивать код, если вы входите с доверенного устройства.

2017: Google отказывается от SMS при двухфакторной авторизации

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

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

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

Пользовательский UserDetailsService

Итак, первый способ. Реализуем метод loadUserByUsername():

@Service
public class CustomUserDetailsService implements UserDetailsService {
    @Autowired
    private MyUserRepository dao;
    @Override
    public UserDetails loadUserByUsername(String userName) throws UsernameNotFoundException {
        MyUser myUser= dao.findByLogin(userName);
        if (myUser == null) {
            throw new UsernameNotFoundException("Unknown user: "+userName);
        }
        UserDetails user = User.builder()
                .username(myUser.getLogin())
                .password(myUser.getPassword())
                .roles(myUser.getRole())
                .build();
        return user;
    }
}

Если пользователь не найден, необходимо выбросить UsernameNotFoundException – Spring Security его ожидает.

И настроим AuthenticationManager:

@EnableWebSecurity(debug = true)
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Autowired
    private CustomUserDetailsService userDetailsService;

    ...

    @Override
    public void configure(AuthenticationManagerBuilder auth) throws Exception {
      auth.userDetailsService(userDetailsService);
    }
}

Все, теперь пример работает как предыдущий, но данные берутся из базы.

Что происходит под капотом

В фильтре UsernamePasswordAuthenticationFilter происходит аутентификация. В метод:

Authentication authenticate(Authentication token)

передается токен с именем и пароля (пришедшими с формы). Далее Spring Security вызывает реализованный выше loadUserByUsername(String userName), чтобы получить реального пользователя из базы и сравнить его с переданным токеном. Если аутентификация удалась, возвращается новый объект Authentication (как описано тут); если нет – выбрасывается исключение.

Теперь реализуем альтернативный подход. В нем последний абзац исполним вручную.