Способ аутентификации логин пароль

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

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

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

Начало

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

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

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

Учётная запись — это хранимый в системе набор данных о пользователе. К учётной записи как правило имеет доступ лишь один пользователь — её владелец.

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

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

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

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

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

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

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

Варианты фиксирования уникального имени пользователя (логин)

Есть несколько возможных способов проверки подлинности при предоставлении доступа к данным учётной записи в какой-либо системе. Логином могут выступать следующие пункты:

Номер телефона (+996 777 777 777)

Уникальное имя (username)

Учётная запись в стороннем сервисе (Google, Facebook, Apple… и так далее)

При аутентификации в сервисе А через сторонние сервисы Б — вам не нужно проходить процесс подтверждения личности в сервисе Б, а лишь нужно подтвердить свою личность в сервисе А. (На пример зайти в учётную запись Google, и при помощи её зайти в учётную запись Figma). Могут использоваться проверки в виде сообщения на почту со ссылкой для подтверждения регистрации/авторизации.

Варианты подтверждения логина (пароль)

Логин — это ещё не полный доступ к учётной записи, ему всегда сопутствует секретный ключ (пароль), который работает только в связке Логин-Пароль (или что-то из списка ниже).

SMS код (9379992SMS)

Код в электронном сообщении (9379992MAIL)

PIN код (9379992)

Ключи доступа / Токены (как пример ssh key)

Сканеры внешности (лицо, отпечаток пальца)

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

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

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

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

Комбинации ввода логина и пароля

Описанные выше варианты логинов и паролей могут комбинироваться между собой для проверки подлинности пользователя. На пример:

Email

Номер телефона

Уникальное имя

Код в Email сообщении

В таблице каждая колонка — это варианты логина, а строки — это доступные варианты паролей.

Механизм проверки соответствия логина и пароля

Процесс проверки соответствия логина и пароля проходит в несколько этапов.

Отправляем данные на проверку

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

Система отправляет результат проверки пользователю.

Получаем результат проверки

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

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

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

Упрощённая схема двух факторной аутентификации

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

Ошибки аутентификации

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

Логин введён неверно

Пароль введён неверно

Нет соединения с сервером

Ошибка проверки данных сервером

Превышен лимит ошибочных попыток аутентификации

Пользователь ввёл верно свои денные, но он не зарегистрирован

Учётная запись пользователя заблокирована администратором

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

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

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

Подтвердить свою личность (на пример пройти по ссылке в электронном письме от сервиса восстановления пароля или ввести код из СМС)

Ввести новый пароль

Повторить ввод нового пароля

Сохранить новый пароль

После прохождения данных этапов пользователь для входа в систему может использовать свой логин и новый пароль.

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

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

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

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

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

Cookies

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

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

Заключение

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

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

Источник

Аутентификация и авторизация в микросервисных приложениях

Автор: Вячеслав Михайлов, Solutions Architect

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

Мы разберемся с процессом аутентификации пользователя, работой технологии единого входа (Single sign-on/SSO), дадим общее представлении о технологии OAuth2 и принципах ее работы, не углубляясь в особенности конкретной технической реализации. В следующей статье в качестве примера удачной реализации мы рассмотрим библиотеку Thinktecture Identity Server v3, подробнее остановимся на ее функциональных возможностях, поговорим, как собрать минимальный набор компонент, необходимый для работы в микросервисной архитектуре и достойный использования в боевой системе. В третьей части мы покажем, как расширять эту библиотеку, подстраиваясь под нужды вашей системы, а завершит цикл статей разбор различных сценариев, встречавшихся в жизни многих разработчиков с рекомендациями для каждого случая.

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

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

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

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

Способы аутентификации

При использовании HTTP-протокола простейший способ аутентификации — Basic access authentication. В принципе этот протокол устарел и уже редко используется в интернете, особенно в незащищенных соединениях, но еще сохраняется во внутрикорпоративных системах, просто потому что некоторые из них созданы достаточно давно. Стоит разобраться, как он работает.

HTTP Basic Authentication

Первым, что при обращении к защищенному ресурсу сервер выдаст пользователю, не имеющему доступа, будет ошибка 401 Unauthorized. При этом ответ также содержит информацию о типе аутентификации (в нашем случае – Basic), который он может принимать, и контекст, в рамках которого эта аутентификация действует (Realm). Пользователь вводит логин и пароль, они упаковываются в Base64 и отправляются на сервер для проверки. Здесь существуют различные опасности. Самая распространенная — угроза man-in-the-middle attack, или атаки посредника, в ходе которой при использовании незащищенного соединения учетные данные могут перехватить злоумышленники в момент передачи от клиента к серверу или обратно.

HTTP Digest Authentication

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

Forms Authentication

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

Token Authentication

Следующее поколение способов аутентификации представляет Token Based Authentication, который обычно применяется при построении систем Single sign-on (SSO). При его использовании запрашиваемый сервис делегирует функцию проверки достоверности сведений о пользователе другому сервису. Т. е. провайдер услуг доверяет выдачу необходимых для доступа токенов собственно токен-провайдеру (Identity provider). Это то, что мы видим, например, входя в приложения через аккаунты в социальных сетях. Вне IT самой простой аналогией этого процесса можно назвать использование общегражданского паспорта. Официальный документ как раз является выданным вам токеном — все государственные службы по умолчанию доверяет отделу полиции, который его вручил, и считает паспорт достаточным для вашей аутентификации на протяжении всего срока действии при сохранении его целостности.

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

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

OAuth2 & Open ID Connect

Дальнейшее усовершенствование процесса понадобилось ввиду того, что токен-аутентификация требует присутствия пользователя в момент получения доступа к защищенному ресурсу. Потому что Identity provider при передаче ему управления будет с пользователем взаимодействовать, запрашивая, например, логин и пароль.

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

В 2006 году в ходе работы над реализацией протокола Open ID для Twitter обнаружилась потребность в новом открытом протоколе авторизации. В 2007 инженеры Google и AOL начали совместную работу над ним, а в 2009 Twitter предложил своим пользователям решение, делегировавшее сторонним сервисам доступ к аккаунтам и основанное на протоколе OAuth. Три года спустя была опубликована новая версия — OAuth 2, упростившая разработку клиентских приложений и получившая целый ряд новых возможностей, среди которых оказалось и обновление токена без участия пользователя. Многие сервисы начали использовать этот протокол еще до его официального утверждения.

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

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

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

Все три протокола позволяют пользователю не разглашать свои секретные логин и пароль недоверенным приложениям. OpenID & OAuth разрабатывались параллельно вплоть до 2014 года и объединились в итоге в OpenID connect.

OpenID 1.0 (2006) & OpenID 2.0 (2007) позволяли приложению(арб) запрашивать у доверенного сервера (authority) проверку пользователя(user). Отличия между версиями для нас несущественны.

• User –> App: Привет, это Миша.
• App –> Authority: Вот «это» Миша?
• Authority и User общаются тет-а-тет.
• Authority –> App: Да, это Миша.

OpenID Attribute Exchange 1.0 (2007) расширяет OpenID 2.0 разрешая получать и хранить профиль пользователя.

• User –> App: Привет, это Миша.
• App –> Authority: Вот «это» Миша? И если это Миша, то пришлите мне его email.
• Authority и User общаются тет-а-тет.
• Authority –> App: Да, это Миша. И его email xxx@xxx.xxx.

OAuth 1.0 (2010) позволяет пользователю разрешать приложению получать ограниченный доступ на третьесторонних серверах(third-party server), доверяющих удостоверяющему центру.

• App –> User: Mы бы хотели получить ваши картинки с другого сервера.
• Authority и User общаются тет-а-тет.
• Authority –> App: Вот вам билет (access token) на 15 минут.
• App –> Third-party server: Нам тут по билету можно получить фотографии для этого пользователя.

OAuth 2.0 (2012) делает тоже самое, что и OAuth 1.0, но только протокол существенно поменялся и стал проще.

OpenID Connect (2014) объединяет возможности OpenID 2.0, OpenID Attribute Exchange 1.0, и OAuth 2.0 в один общий протокол. Он позволяет приложениям использовать удостоверяющий центр для:

• Проверять учетные данные пользователя.
• Получать профиль пользователя (или его части).

Важно понимать, что OpenID Connect не дает доступ к внешним ресурсам. Он использует OAuth 2.0 для того, чтобы представить параметры профиля как будто это такие ресурсы.

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

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

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

В качестве реализации мы рассматриваем протокол OAuth2. В принципе, существуют и другие, например, Kerberos, успешно взаимодействующий с Windows, но в случае гетерогенной сети, в которой существуют компьютеры, использующие и Windows-, и Mac-, и UNIX-системы, использовать проприетарные протоколы зачастую неудобно. Тем более, это касается случаев, когда доступ к вашим сервисам осуществляется через веб — здесь OAuth2 оказывается лучшим кандидатом.

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

Как мы знаем из раздела «разбираемся детально ху из ху», OpenID Сonnect нужен, чтобы получить у пользователя его учетные данные и проверить их. OAuth 2.0 нужен, чтобы получать токены доступа и с ними обращаться к ресурсам.

Терминология OAuth2 & OpenID Connect

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

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

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

• Аутентифицировать пользователей, используя внутреннее хранилище пользователей или внешний источник (например, Active Directory).
• Управлять клиентами (хранить) и аутентифицировать их.
• Предоставлять управление сессией и возможность реализации Single sing-on.
• Выдавать identity-токены и access-токены клиентам.
• Проверять ранее выданные токены.

Клиент

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

Пользователь

User — собственно конечный пользователь — человек.

Область (scope)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При обращении пользователя к клиенту, тот перенаправляет пользователя на Open ID Connect Provider, который запрашивает у пользователя логин и пароль. В случае успешного прохождения проверки параметров аутентификации он возвращает назад identity token и access token, с которыми пользователь может обращаться к защищенному ресурсу.

Структура токена

Формат

В реализации OAuth2 используется так называемый jwt-токен, который состоит из трех частей. Допустим, при обращении к Identity provider вы отправляете логин/пароль и в ответ получаете токен. Он будет включать в себя: Header (заголовок), Payload (контент) и Signature (подпись). На сайте jwt.io его можно декодировать и посмотреть содержимое формате JSON. На этом сайте вы также найдете описание правил формирования jwt-токенов.

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

Кроме identity tokens, есть еще и аccess tokens, которые содержат информацию о выданных пользователю клеймах. Срок действия access token достаточно короткий, потому что его хищение может обеспечить несанкционированный доступ к ресурсу. Т. е. злоумышленник, если ему удастся заполучить токен этого типа, доступ получит на очень непродолжительное время. Для получения нового access token используется refresh token, который обычно не фигурирует в незащищенных средах, в частности в режиме доступа из браузера он вообще не используется. Какие именно токены будут возвращены клиенту в процессе аутентификации, разберемся в следующей части.

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

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

• iss — адрес или имя удостоверяющего центра.
• sub — идентификатор пользователя. Уникальный в рамках удостоверяющего центра, как минимум.
• aud — имя клиента для которого токен выпущен.
• exp — срок действия токена.
• nbf — время, начиная с которого может быть использован (не раньше чем).
• iat — время выдачи токена.
• jti — уникальный идентификатор токен (нужен, чтобы нельзя был «выпустить» токен второй раз).

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

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

Минимальная реализация интеграция Identity Server в ваше приложение выглядит так:

Минимальная реализация интеграции веб-клиента с Identity Server:

Минимальная реализация интеграции веб-API с Identity Server:

Источник