Авторизация bearer что это
Аутентификация OAuth2 в проектах Laravel
Время от времени возникает вопрос, как разрешить пользователям входить в отдельные (дочерние) приложения, используя одну учетную запись главного приложения.
Таким образом, пользователи смогут логиниться в дочерние приложения, не создавая новую отдельную учетную запись.
Если вы еще не знакомы с протоколом OAuth2, то ниже я о нём расскажу.
Что такое OAuth2?
Прежде, чем перейти к Laravel Passport, важно понять протокол OAuth, который он реализует.
OAuth — это открытый стандарт, разработанный для обеспечения делегированного доступа к API. Например, стороннее приложения Twitter, которое может от вашего имени твитнуть в соц.сеть. Я упоминаю Twitter, поскольку разработка этого стандарта (помимо прочего) велась его ведущим разработчиком Блан Куком. Твиттер нуждался во внешней авторизации.
После первоначального релиза версии 1.0 в 2010 году протокол дозревал два года, после чего была выпущена версия 2.0. Улучшенный протокол предлагает поддержку токенов Bearer и обеспечивает «методы (называемых потоками (flows)) для авторизации веб-приложений, настольных клиентов и мобильных клиентов» (Википедия)
Давайте посмотрим, что подразумевается под терминами «токен Bearer» и «потоки авторизации».
Токены Bearer
Слово «Bearer (Предъявитель)» означает, что у вас есть определенный токен (доступ). Предъявителем является стороннее приложение, которому его выдал провайдер идентификации. Этот токен обеспечивает немедленный доступ к ресурсу, не требуя имени пользователя и пароля. С этим токеном связана вся необходимая информация, включая данные пользователя и объем возможных действий, которые может предпринять третье лицо от имени этого пользователя.
Поток авторизации
Теперь, когда мы знаем, что такое токен доступа Bearer …как его получить?
Сначала давайте посмотрим на формальные роли в OAuth2:
Протокол OAuth 2.0 выполняет стандартный обмен данными между Клиентом и Ресурсным Сервером, где каждый шаг и заданные/требуемые параметры определяются заранее. В конечном итоге Клиент получает токен доступа Bearer от Сервера. Этот процесс показан на рисунке ниже. Примечание: предполагается, что Клиент (стороннее приложение) зарегистрирован на Ресурсном Сервере.
После этого маленького «танца» у Клиента есть токен доступа, который может быть либо долгоживущим, либо короткоживущим (но более безопасным). Если токен доступа является короткоживущим, то Ресурсный сервер также предоставляет токен обновления (refresh token), который можно использовать, в сочетании с секретным кодом, для получения нового токена доступа способом, аналогичным шагу 3 на диаграмме выше. Примечание: Параметр «состояние» (state) используется для предотвращения CSRF атак, проверяя, не является ли запрос поддельным.
Теперь давайте посмотрим, как Laravel Passport реализует этот протокол.
Laravel Passport
В нашем примере мы хотим, чтобы провайдер идентификации ( example.com ) использовал Laravel Passport.
Laravel Passport — это сервер OAuth2, построенный на сервере League OAuth2. Он обеспечивает простую реализацию для существующих приложений Laravel, требуя пакет composer.
Настройка Ресурсного севера
Создание нового Клиента в Laravel Passport
Laravel Passport позаботится о диалоге авторизации, предоставит код авторизации, подтвердит секретный код клиента в сочетании с кодом авторизации, и, наконец, предоставит объект User и (по умолчанию) долгоживущий токен доступа. Срок службы токенов доступа и обновления настраивается.
Пример Клиента с ID и секретным кодом
Laravel Socialite
Когда мы настроили Ресурсный Сервер (провайдер идентификации), нам нужно позаботиться о стороне Клиента.
Помимо Passport, Laravel предлагает пакет под названием Laravel Socialite, который позаботится о клиентской стороне при аутентификации через OAuth2.
Из коробки он позволяет аутентификацию через Facebook, Twitter, LinkedIn, Google, GitHub, GitLab и Bitbucket.
Социальные провайдеры
Однако существует ряд дополнительных провайдеров, среди которых есть адаптер, поддерживающий Laravel Passport.
Настройка Клиента
Для создания общей системы логина для нескольких приложений Laravel предлагаемое мной решение включает в себя использование провайдера Socialite для Laravel Passport.
Судя по инструкции для установки Socialite, нужно пройти несколько шагов, чтобы клиентское приложение могло идентифицировать пользователей через провайдера идентификации Laravel Passport.
Теперь, похоже, придется повторять кучу шагов для каждого клиентского приложения, которое у нас уже есть, и которое мы хотим подключиться к нашему Ресурсному Серверу. Вот почему я создал пакет (см. GitHub-репозиторий), который объединяет Laravel Socialite с драйвером Passport и может быть настроен гораздо более эффективно.
Пакет Socialite-Passport
В приложении Клиента, которое вы хотите подключить к Ресурсному Серверу Passport, сначала установите пакет socialite-passport:
Опубликуйте файл конфигурации:
Помните, что LARAVELPASSPORT_CLIENT_ID и LARAVELPASSPORT_CLIENT_SECRET идут с Ресурсного Сервера Laravel Passport, где сначала необходимо создать Клиента.
Пакет обеспечит соответствие маршрута, который вы задаете в переменной LARAVELPASSPORT_REDIRECT_URI и проксирует запрос через соответствующий метод и контроллер, настроенные в конфигурационном файле.
Заключение
Это все, что нужно для реализации базового функционала общей системы логина.
Надеюсь, что эта статья помогла пролить свет на протокол OAuth2 и на то, как его можно использовать с вышеупомянутыми инструментами для создания общей системы аутентификации среди различных проектов на Laravel.
Было бы неплохо также хранить токен доступа (и токен ресурса) в пользовательской модели, чтобы иметь возможность обновлять информацию всякий раз, когда пользователь изменяет свой профиль на Ресурсном Сервере. Или собирать другие данные пользователя.
Резюме
Laravel Passport реализует полнофункциональный сервер OAuth2 (Ресурсный Сервер)
Laravel Socialite реализует аутентификацию на сервере OAuth2 (Клиент)
Провайдер Socialite для Laravel Passport реализует аутентификацию через Laravel Passport
Клиенты могут быть подготовлены с помощью этого пакета, объединяющего Socialite с адаптером Passport.
Наш 
Телеграм-канал — следите за новостями о Laravel.
Задать вопросы по урокам можно на нашем форуме.
Что такое OAuth 2.0 Bearer Token?
Маркер безопасности с тем свойством, что любая сторона, владеющая токеном («носитель»), может использовать токен любым способом, которым может воспользоваться любая другая сторона, обладающая этим токеном.
Для меня это определение расплывчато, и я не могу найти какую-либо спецификацию.
Спасибо за любой указатель.
Токен на предъявителя Токен
безопасности с тем свойством, что любая сторона, владеющая токеном («носитель»), может использовать токен любым способом, которым может владеть любая другая сторона, обладающая этим токеном. Использование токена на предъявителя не требует, чтобы носитель доказывал владение материалом криптографического ключа (доказательство владения).
Токен на предъявителя создается для вас сервером аутентификации. Когда пользователь аутентифицирует ваше приложение (клиент), сервер аутентификации отправляется и генерирует для вас токен. Токены на предъявителя являются преобладающим типом токена доступа, используемого в OAuth 2.0. Токен на предъявителя в основном гласит: «Дай носителю доступ к этому токену».
Токен на предъявителя обычно представляет собой некое непрозрачное значение, создаваемое сервером аутентификации. Это не случайно; он создается на основе того, что пользователь предоставляет вам доступ, а клиент получает доступ к вашему приложению.
Например, для доступа к API вам необходимо использовать токен доступа. Жетоны доступа недолговечны (около часа). Вы используете токен на предъявителя, чтобы получить новый токен доступа. Чтобы получить токен доступа, вы отправляете серверу аутентификации этот токен на предъявителя вместе с идентификатором вашего клиента. Таким образом, сервер узнает, что приложение, использующее токен переноса, является тем же приложением, для которого был создан токен переноса. Пример: я не могу просто взять токен на предъявителя, созданный для вашего приложения, и использовать его с моим приложением, он не будет работать, потому что он не был сгенерирован для меня.
Маркер Google Refresh выглядит примерно так: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM
скопировано из комментария: я не думаю, что есть какие-либо ограничения на токены на предъявителя, которые вы предоставляете. Единственное, о чем я могу думать, это то, что приятно допускать более одного. Например, пользователь может аутентифицировать приложение до 30 раз, и старые токены носителя будут работать. о, и если он не использовался, скажем, 6 месяцев, я бы удалил его из вашей системы. Это ваш сервер аутентификации, который должен будет генерировать их и проверять их, так как отформатировать это зависит от вас.
Обновить:
Маркер-носитель устанавливается в заголовке авторизации каждого HTTP-запроса встроенного действия. Например:
При использовании токенов канала-носителя убедитесь, что запрос поступает с сервера аутентификации и предназначен для домена отправителя. Если токен не подтвержден, служба должна ответить на запрос с кодом ответа HTTP 401 (неавторизовано).
Токены на предъявителя являются частью стандарта OAuth V2 и широко используются многими API.
Web API авторизация Bearer с поддержкой cookies
Сайтостроение | создано: 27.10.2016 | опубликовано: 27.10.2016 | обновлено: 19.12.2021 | просмотров: 19416
В статье описывается как для Web API использовать OAuth 2.0 аутентификацию и авторизацию на основе access_token (Bearer), и как этот токен хранить в cookie чтобы не приходилось при каждом новом открытии сайта вводить данные для получения этого токена.
Описание
Если вы захотите использовать OAuth 2.0 аутентификацию (и авторизацию) на основе access_token (например, Bearer), то вам придется в в заголовке каждого запроса передавать этот самый токен. Тут, как говорится, ничего нового, всё уже придумали за нас. Но если это так, то встает резонный вопрос: где его брать, чтобы его передавать? Об этом и о многом другом пойдет речь в этой статье.
Задача
Когда у меня созрела идея написания этой статьи, передо мной стояла задача запустить одностраничный сайт (Single Page Application) без использования ASP.NET MVC, но с возможностью использования Web API. Задача решена. Давайте ее разложим по пунктам. Итак, для решения задачи требуется решить следующие задачи:
Мелкие нюансы типа «поднять токен сервис» или «запросить у пользователя логин, если токен не обнаружен в cookie» опущены, хотя и обязательны.
Используемые инструменты и технологии
Я буду использовать Visual Studio 2015. При создания проекта я не использовал ASP.NET MVC 5, а создал пустой solution.
После этого я установил нужные nuget-пакеты, чтобы у меня получился проект с одной HTML-страницей (Single Page Application) и подключенным Web API. Для полноты картины приведу весь список установленных пакетов.
Обратите внимания, что у меня нет пакетов ASP.NET MVC в списке установленных.
Если вы скопировали файл packages.config из другого источника или создали его вручную без установки каждого из пакетов, то в Package Managment Console достаточно ввести следующую команду, чтоб все пакеты установились автоматически.
Далее подключим OWIN для сайта. Для этого создаем файл Startup.cs:
Теперь приведу его полное содержимое и после чего, как уже принято приведу пояснения к коду.
Так как этот файл, и в частности метод Configuration использует классы, которые буду показаны позже, проект не может быть собран и запущен. Поэтому не пытайтесь это сделать. Теперь, прокомментирую код по порядку следования строк, создавая недостающие классы и настройки.
Startup: Строки 6-7
Используется OWIN как основная спецификация взаимодействия между компонентами. ASP.NET MVC при этом не используется.
Startup: Строка 10
Стандартный для OWIN атрибут указывающий на то что при старте приложения класс c настройками для запуска является Startup.cs.
Startup: Строка 25
Создаем конфигурацию Web API и настраиваем основные параметры.
Важные строки выделены цветом. Здесь отключаем стандартную аутентификацию на сайте и регистрируем свой собственный AuthorizationBearerFilter, который выглядит следующим образом.
Комментарии по этому коду: в строке 11 проверяем наличие Authorization в Header; в строке 19 распаковываем (расшифровка) ticket и проделываем нужные нам манипуляции для проверки пользователя; в 27 строке устанавливаем IPrincipal для текущего запроса. Именно в 27 строке вы можете указать нужные параметры для пользователя: роли, права, настройки и т.д., которые, кстати, можно получить из БД или из другого сервиса.
Возвращаемся к Startup, следующая строка, требующая внимания, это строка номер 26, где происходит инициализация DependencyContainer. Я также приведу его полностью, закомментировав неважные строки:
Вы можете и вовсе не использовать DI-контейнер, или использовать другой на своё усмотрение. На самом деле, нам интересна выделенная 33 строка. В этой строке в DI-контейнере регистрируется, пожалуй самый главный класс, который отвечает за авторизацию и аутентификацию. Приведу его полностью, и как водится с комментариями после:
ApplicationOAuthProvider: Строка 13
Требуется создать свою реализацию OAuthAuthorizationServerProvider, поэтому наш класс унаследован от этого класса.
ApplicationOAuthProvider: Строка 19
Указываем тип аутентификации.
ApplicationOAuthProvider: Строка 24
Я использую врутренний ViewModel для проброса данных в сервис аутентификации в строке 29.
ApplicationOAuthProvider: Строка 31
Возращает отрицательный ответ о том, что аутентификация не увенчалась успехом с указанием причин.
ApplicationOAuthProvider: Строка 41
Возращает зашифрованный AutenticationTicket, как результат успешной аутентификации.
Теперь снова вернемся к Startup классу.
Startup: Строка 36 и 42
В 36 как и 42 строке используется расширение AppBuilder.
В строке 14 по сути происходит запуск сайта. Так как я не использую ASP.NET MVC, то всё-таки хоть что-то должно как-то выводиться в браузер. Именно этот класс SinglePageWithWebApi и читает файл из папки Views и рендерит его в поток вызова без изменений HTML.
В строке 22 подключается класс BearerOnCookieAuthentication (middleware), ради которого и затевалась эта статья. Именно этот представленный ниже класс проделывает основную работу по обеспечению чтению Cookie и записи его наличия в свойство Authorization в коллекцию Header:
Теперь весь код собран воедино, следовательно можно откомпилировать проект. После успешного построения я запустил проект, и оказалось, что я случайно закомментировал лишную строку с регистрацией IAccountManager в DependencyContainer. Чтобы запуск состоялся, вам потребуется разкомментировать строчку с IAccountManager, а также вам потребуется файл index.html в папке Views.
Для удобства, тоже приведу полное содержание файла index.html:
Заключение
Авторизация настроена, хотя это и не видно. Единственное, что вам придется сделать самостоятельно, так это реализовать JavaScript функционал, который будет обращаться к ApiController, который вы тоже должны будете создать самостоятельно. ApiController теперь может быть помечен атрибутом Autorize. Авторизация и аутентификация будет осуществляться через access_token.
Ссылки
В заключении ссылка на вновь созданный проект, который выложен на GitHub.
Как ты реализуешь аутентификацию, приятель?
Все знают о стандартной аутентификации пользователя в приложении. Это олдскульная процедура регистрации — пользователь вводит адрес почты, пароль и т. д., — а затем при входе мы сравниваем почту и/или пароль с сохранёнными данными. Если совпадает, даём доступ. Но времена изменились, и сегодня появилось много других методов аутентификации. Если хотите оставаться востребованным программистом/разработчиком в этом меняющемся, словно калейдоскоп, мире разработки ПО, то вы должны знать обо всех этих новых методах.
Нельзя отрицать, что в любых приложениях и ОС «аутентификация» — крайне важный элемент обеспечения сохранности пользовательских данных и регулирования доступа к информации. Чтобы понять, какой метод аутентификации для вас лучше, нужно разбираться в достоинствах и недостатках всех методов, а также неплохо представлять, как же они работают.
Здесь я постараюсь рассказать о большинстве распространённых сегодня методов аутентификации. Это не подробное техническое руководство, а лишь способ познакомить вас с ними. Хотя методы описаны с учётом применения в вебе, эти идеи можно реализовать и в других условиях.
Будем считать, вы уже знаете о том, что большая часть веба/интернета построена на протоколе HTTP. Также вам нужно знать, как работают веб-приложения, что означает аутентификация пользователя в приложении и что такое клиент-серверная архитектура.
Аутентификация на основе сессий
Протокол HTTP не отслеживает состояния, и, если мы аутентифицируем пользователя с помощью имени и пароля, наше приложение не будет знать, тот ли это человек, что и в предыдущем запросе. Нам придётся аутентифицировать снова. При каждом запросе HTTP не знает ничего о том, что происходило до этого, он лишь передаёт запрос. Так что, если вам нужны личные данные, придётся снова логиниться, чтобы приложение знало, что это точно вы. Может сильно раздражать.
Чтобы избавиться от этого неудобства, придумали аутентификацию на основе сессий/кук, с помощью которых реализовали отслеживание состояний (stateful). Это означает, что аутентификационная запись или сессия должны храниться и на сервере, и на клиенте. Сервер должен отслеживать активные сессии в базе данных или памяти, а на фронтенде создаётся кука, в которой хранится идентификатор сессии. Это аутентификация на основе куки, самая распространённый и широко известный метод, используемый уже давно.
Процедура аутентификации на основе сессий:
У этого метода несколько недостатков.
Аутентификация на основе токенов
Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений, веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT). Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.
При аутентификации на основе токенов состояния не отслеживаются. Мы не будем хранить информацию о пользователе на сервере или в сессии и даже не будем хранить JWT, использованные для клиентов.
Процедура аутентификации на основе токенов:
У метода есть ряд преимуществ:
Благодаря всему этому аутентификация на основе токенов сегодня набирает популярность.
Беспарольная аутентификация
Первой реакцией на термин «беспарольная аутентификация» может быть «Как аутентифицировать кого-то без пароля? Разве такое возможно?»
В наши головы внедрено убеждение, что пароли — абсолютный источник защиты наших аккаунтов. Но если изучить вопрос глубже, то выяснится, что беспарольная аутентификация может быть не просто безопасной, но и безопаснее традиционного входа по имени и паролю. Возможно, вы даже слышали мнение, что пароли устарели.
Беспарольная аутентификация — это способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей. Идея такая:
Вместо ввода почты/имени и пароля пользователи вводят только свою почту. Ваше приложение отправляет на этот адрес одноразовую ссылку, пользователь по ней кликает и автоматически входит на ваш сайт / в приложение. При беспарольной аутентификации приложение считает, что в ваш ящик пришло письмо со ссылкой, если вы написали свой, а не чужой адрес.
Есть похожий метод, при котором вместо одноразовой ссылки по SMS отправляется код или одноразовый пароль. Но тогда придётся объединить ваше приложение с SMS-сервисом вроде twilio (и сервис не бесплатен). Код или одноразовый пароль тоже можно отправлять по почте.
И ещё один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев. Подробнее о технологии.
Если вы пользуетесь Slack, то уже могли столкнуться с беспарольной аутентификацией.
Medium предоставляет доступ к своему сайту только по почте. Я недавно обнаружил, что Auth0, или Facebook AccountKit, — это отличный вариант для реализации беспарольной системы для вашего приложения.
Что может пойти не так?
Если кто-то получит доступ к пользовательским почтам, он получит и доступ к приложениям и сайтам. Но это не ваша головная боль — беспокоиться о безопасности почтовых аккаунтов пользователей. Кроме того, если кто-то получит доступ к чужой почте, то сможет перехватить аккаунты в приложениях с беспарольной аутентификацией, воспользовавшись функцией восстановления пароля. Но мы ничего не можем поделать с почтой наших пользователей. Пойдём дальше.
В чём преимущества?
Как часто вы пользуетесь ссылкой «забыли пароль» для сброса чёртового пароля, который так и не смогли вспомнить после нескольких неудачных попыток входа на сайт / в приложение? Все мы бываем в такой ситуации. Все пароли не упомнишь, особенно если вы заботитесь о безопасности и для каждого сайта делаете отдельный пароль (соблюдая все эти «должен состоять не менее чем из восьми символов, содержать хотя бы одну цифру, строчную букву и специальный символ»). От всего этого вас избавит беспарольная аутентификация. Знаю, вы думаете сейчас: «Я использую менеджер паролей, идиот». Уважаю. Но не забывайте, что подавляющее большинство пользователей не такие техногики, как вы. Это нужно учитывать.
Беспарольная аутентификация хороша не только для пользователей, но и для вас как разработчика. Вам не нужно реализовывать механизм восстановления паролей. Все в выигрыше.
Если вы думаете, что какие-то пользователи предпочтут старомодные логин/пароль, то предоставьте им оба варианта, чтобы они могли выбирать.
Сегодня беспарольная аутентификация быстро набирает популярность.
Единая точка входа (Single Sign On, SSO)
Обращали внимание, что, когда логинишься в браузере в каком-нибудь Google-сервисе, например Gmail, а потом идёшь на Youtube или иной Google-сервис, там не приходится логиниться? Ты автомагически получаешь доступ ко всем сервисам компании. Впечатляет, верно? Ведь хотя Gmail и Youtube — это сервисы Google, но всё же раздельные продукты. Как они аутентифицируют пользователя во всех продуктах после единственного входа?
Этот метод называется единой точкой входа (Single Sign On, SSO).
Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts. Когда пользователь логинится, Google Accounts создаёт куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:
Очень простое описание единой точки входа: пользователь входит один раз и получает доступ ко всем системам без необходимости входить в каждую из них. В этой процедуре используется три сущности, доверяющие другу прямо и косвенно. Пользователь вводит пароль (или аутентифицируется иначе) у поставщика идентификационной информации (identity provider, IDP), чтобы получить доступ к поставщику услуги (service provider (SP). Пользователь доверяет IDP, и SP доверяет IDP, так что SP может доверять пользователю.
Выглядит очень просто, но конкретные реализации бывают очень сложными. Подробнее об этом методе аутентификации.
Аутентификация в соцсетях
Уверен, эта картинка знакома всем:
Это часто называют аутентификацией в соцсетях (Social sign-in) или социальным логином (Social Login). Вы можете аутентифицировать пользователей по их аккаунтам в соцсетях. Тогда пользователям не придётся регистрироваться отдельно в вашем приложении.
Формально социальный логин — это не отдельный метод аутентификации. Это разновидность единой точки входа с упрощением процесса регистрации/входа пользователя в ваше приложение.
Лучшее из двух миров
Пользователи могут войти в ваше приложение одним кликом, если у них есть аккаунт в одной из соцсетей. Им не нужно помнить логины и пароли. Это сильно улучшает опыт использования вашего приложения. Вам как разработчику не нужно волноваться о безопасности пользовательских данных и думать о проверке адресов почты — они уже проверены соцсетями. Кроме того, в соцсетях уже есть механизмы восстановления пароля.
Как использовать
Как разработчик вы должны разбираться в работе этого метода аутентификации. Большинство соцсетей в качестве механизма аутентификации используют авторизацию через OAuth2 (некоторые используют OAuth1, например Twitter). Разберёмся, что такое OAuth. Соцсеть — это сервер ресурсов, ваше приложение — клиент, а пытающийся войти в ваше приложение пользователь — владелец ресурса. Ресурсом называется пользовательский профиль / информация для аутентификации. Когда пользователь хочет войти в ваше приложение, оно перенаправляет пользователя в соцсеть для аутентификации (обычно это всплывающее окно с URL’ом соцсети). После успешной аутентификации пользователь должен дать вашему приложению разрешение на доступ к своему профилю из соцсети. Затем соцсеть возвращает пользователя обратно в ваше приложение, но уже с токеном доступа. В следующий раз приложение возьмёт этот токен и запросит у соцсети информацию из пользовательского профиля. Так работает OAuth (ради простоты я опустил технические подробности).
Для реализации такого механизма вам может понадобиться зарегистрировать своё приложение в разных соцсетях. Вам дадут app_id и другие ключи для конфигурирования подключения к соцсетям. Также есть несколько популярных библиотек/пакетов (вроде Passport, Laravel Socialite и т. д.), которые помогут упростить процедуру и избавят от излишней возни.
Двухфакторная аутентификация (2FA)
Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счёт использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации. Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдёт вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.
Другой знакомый пример — двухфакторная аутентификация Mail.Ru, Google, Facebook и т. д. Если включён этот метод входа, то сначала вам нужно ввести логин и пароль, а затем одноразовый пароль (код проверки), отправляемый по SMS. Если ваш обычный пароль был скомпрометирован, аккаунт останется защищённым, потому что на втором шаге входа злоумышленник не сможет ввести нужный код проверки.
Вместо одноразового пароля в качестве второго фактора могут использоваться отпечатки пальцев или снимок сетчатки.
При двухфакторной аутентификации пользователь должен предоставить два из трёх:
Большинство хакеров охотятся за паролями и PIN-кодами. Гораздо труднее получить доступ к генератору токенов или биологическим свойствам, поэтому сегодня двухфакторка обеспечивает высокую безопасность аккаунтов.
То есть это универсальное решение? Возможно, нет.
И всё же двухфакторка поможет усилить безопасность аутентификации в вашем приложении. Как реализовать? Возможно, стоит не велосипедить, а воспользоваться существующими решениями вроде Auth0 или Duo.
Аутентификация или авторизация?
Некоторые путают термины «аутентификация» и «авторизация». Это разные вещи.
Поздравляю, вы успешно дочитали длинную, нудную и скучную статью.