О чем эта статья: статья посвящена схемам регистрации, аутентификации, авторизации пользователей в веб приложениях, смене паролей, отзыве токенов, и т. п. Мы также рассмотрим, как организовать хранение данных, обсудим, что такое JWT, коротко поговорим о «сервисе для отправки email»

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

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

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

Термины

• Идентификация — процесс получения идентификатора пользователя: логин/e-mail/id

• Аутентификация — подтверждение личности пользователя подтверждение личности пользователя (с помощью пароля, отпечатка пальца, и т.п.)

• Авторизация — предоставление прав пользователю, выдача токена

• Валидация — процесс проверки «куска» информации на соответствие требованиям программы, или просто на совпадение с копией, хранимой в базе данных.

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

• JWT (Json Web Token) — ключ аутентификации пользователя

• Code — код подтверждения. Высылается на почту пользователя для подтверждения регистрации или сброса пароля.

• Credentials — учетные данные пользователя: логин, пароль, google id, и т.п.

• Эндпоинт — url адрес конкретного метода API или Auth сервиса

• Метод — в рамках данной статьи = эндпоинт

• Методы API — методы, реализующие задачи приложения (то, для чего мы его написали)

• Методы Auth сервиса — методы, напрямую не относящиеся к задачам приложения (в рамках этой статьи противопоставляются «методам API»)

• БД — база данных

• Email-client — почтовый сервис, например: gmail, yandex mail, и т. п.

• TTL (Time to live) — время жизни записи в БД (например: Redis)

• Redis — сервер баз данных типа ключ-значение. Очень быстрый, идеально подходит для хранения кеша и токенов (документация тут)

• Клиент — уровень представления данных (см клиент-серверная архитектура). Имеет графический интерфейс для взаимодействия с пользователем. пример: веб-сайт в интернете.

• Сервер — уровень получения и обработки данных (см клиент-серверная архитектура). Не имеет графического интерфейса, общается со многими киентами через API.

Auth service

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

1. регистрация пользователя с логином и паролем (схема)

2. отправка кода подтверждения на e-mail пользователя (схема)

3. подтверждение регистрации с помощью кода, полученного на email (схема)

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

5. аутентификация и авторизация пользователя с логином и паролем (схема)

6. аутентификация и авторизация пользователя через посредника (схема)

7. выход из аккаунта, отзыв токенов (схема)

8. сброс пароля (пользователь еще не авторизован) (схема)

9. обновление пароля (пользователь авторизован) (схема)

10. выдача токенов после успешной авторизации (схема)

11. обновление истекших токенов (схема)

12. поддержание блэк-листа токенов (схема)

13. контроль версий учетных данных (схема)

Разумеется, это список можно расширить. Сюда можно было бы добавить еще:

• определение ролей пользователей

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

• двухфакторную аутентификацию

• удаление учетной записи

• и т.п.

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

Структура данных

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

1. разделение ответственнности: только методы Auth сервиса должны иметь доступ к учетным данным пользователя, остальным сервисам эти данные не нужны. Меньше точек доступа => выше защищенность приложения.

2. расширяемость: это позволяет использовать несколько типов авторизации в одном приложении и добавлять новые методы авторизации по мере необходимости

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

Вопрос: а что делать с email пользователя, который часто используется в качестве логина, но так же нужен нам для отправки писем с подтверждением регистрации и кодов для сброса пароля?

Ответ: email используется, как логин только по одной причине — уникальность. На мой взгляд, правильным будет его продублировать в таблицах «users» и «credentials», поскольку здесь он выполняет 2 не связанные между собой функции: логина и email.

Для примера, пусть в нашем приложении будет:

1. авторизация по паролю

2. авторизация через гугл

3. авторизация через facebook

JWT

Json Web Token — ключ аутентификации пользователя. Используется для запросов к защищенным методам API.

Я уже описывал нюансы работы с Jwt в статье «Подробно про JWT», поэтому не будем останавливаться на этом. Если приведенные ниже схемы вызовут у вас вопросы, ознакомьтесь с разделами стати про JWT:

• Валидация токенов

• Black-list токенов

• Контроль версий

Коротко про почтовый сервис

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

Реализовать такой сервис не сложно, большинство сред разработки имеют готовые библиотеки для этого, но есть нюанс: в современном мире уже нельзя просто отправить письмо со случайного IP из кода приложения. Такие письма будут развернуты email-клиентом (gmail, yandex mail, и т.п.), как подозрительные. Они не просто упаут в спам, они вернутся с ошибкой доступа (!)

Чтобы письма доходили до адресата нужно подключать сертифицированный сервис-посредник, удостоверяющий подлинность домена и самого письма, например: aws.amazon.com. Процедура не сложная, но муторная, а если вы планируете большой объем рассылки (>200 писем в день), то еще и платная.

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

Эндпоинты

Итак, для реализации Auth сервиса нам понадобятся следующие эндпоинты:

• POST ~/auth/sign-up — зарегистрировать пользователя с логином и паролем (схема)

• POST ~/auth/send-code — отправить email с кодом повторно (схема)

• POST ~/auth/confirm-email — подтверждение регистрации пользователя (схема)

• POST ~/auth/sign-in — авторизоваться в системе (схема)

• POST ~/auth/logout — выход из аккаунта (схема)

• POST ~/auth/reset-password — сброс пароля (схема)

• POST ~/auth/confirm-reset — подтверждение сброса пароля (схема)

• PATCH ~/auth/update-password — обновить пароль (схема)

• POST ~/auth/refresh-tokens — получить свежую пару токенов (схема)

Регистрация пользователя

Что тут происходит:

1. ввод данных пользователя, проверка уникальности email

2. шифрование пароля, сохранение данных пользователя в БД

3. генерация кода подтверждения, сохранение кода в Redis БД

4. получение кода подтверждения на почту пользователя

5. запрос на подтверждение регистрации пользователя, сохранение пометки в БД

6. генерация JWT токенов, передача на клиент

Вопрос: для чего нужно «подтверждение регистрации пользователя»?

Ответ: по сути, это проверка валидности email, который понадобится для сброса пароля.

Отправка кода подтверждения повторно

регистрация пользователя через google Что тут происходит:

1. клик по кнопке «выслать код повторно», проверка email, подтверждение email

2. генерация кода подтверждения, сохранение кода в Redis БД

3. получение кода подтверждения на почту пользователя

Вопрос: для чего нужно повторно отправлять код?

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

Регистрация пользователя через google

Что тут происходит:

1. запрос авторизации через google, перенаправление на страницу авторизации, ввод credentials

2. сохранение данных пользователя в БД.

3. генерация JWT токенов, передача на клиент

Вопрос: как сервер отличит запрос на авторизацию c логином и паролем от регистрации через google аккаунт, если url один и тот же?

Ответ: я передаю тип регистрации в теле запроса. Параметр «providerType», может принимать значения: local, google, facebook, и т.п.

Авторизация пользователя

Что тут происходит:

1. ввод пользователем логина и пароля, проверка логина и пароля сервером

2. генерация JWT токенов, передача на клиент

Авторизация пользователя через google

Что тут происходит:

1. запрос авторизации через google, перенаправление на страницу авторизации, ввод credentials

2. получение данных пользователя из БД.

3. генерация JWT токенов, передача на клиент

Вопрос: как сервер отличит запрос на авторизацию c логином и паролем от регистрации через google аккаунт, если url один и тот же?

Ответ: я передю тип авторизации в теле запроса. Параметр «providerType», может принимать значения: local, google, facebook, и т.п.

Выход из аккаунта

Что тут происходит:

1. Пользователь нажимает «Выход», приложение передает в Auth сервис токены

2. Сервис добавляет токены в black-list, чтобы по ним нельзя было войти в приложение

3. Пользователь перенаправляется на страницу авторизации

Сброс пароля

Что тут происходит:

1. Пользователь нажимает «Сбросить пароль», переадрес на страницу ввода email

2. Пользователь вводит email для получения ссылки, серевер проверяет валидность email

3. Auth серевер создает код для сброса пароля, отправляет на почту пользователя

4. Пользователь получает код

5. Пользователь вводит новый пароль и код подтверждения, Auth серевер валидирует код, хеширует пароль, сохраняет хеш пароля в БД

6. Auth серевер генерирует новую пару токенов, отдает на клиент.

Обновление пароля

Что тут происходит:

1. Пользователь переходит в раздел "Профиль пользователя" в приложении, вводит старый пароль, новый пароль.

2. Извлекаем uuid пользователя из токена, получаем хеш текущего пароля из БД, валидируем пароль

3. Шифруем новый пароль, сохраняем в БД хеш нового пароля, хеш старого пароля, увеличиваем версию учетных данных на +1 (см статью «Подробно про JWT»)

4. Заносим токены в black-list, чтобы по ним больше нельзя было войти в приложение

5. Генерируем новую пару токенов, отправляем на клиент

Обновление JWT

Что тут происходит:

1. запрос данных с access токеном

2. валидация access токена не прошла, возврат ошибки #401

3. запрос обновления токенов с refresh токеном,

4. проверка, не внесен ли токен в black-list

5. получение версии учетных данных из БД

6. валидация токена, проверка версии токена

7. генерация новой пары токенов, отправка на клиент

В заключение

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

Для тех, кто пишет на TypeScript + Nest.js могу написать статью с примером реализации. Если вам это будет интересно, пишите.

Еще по теме

• Role-Based Access Control (RBAC) — роли пользователей

• OAuth 2.0 — протокол, для организации Auth сервиса в виде отдельного сервера. Берет на себя выдачу JWT и упрощает определение прав доступа пользователям.

• OpenID — механизм аутентификации на множестве не связанных друг с другом ресурсов основанный на OAuth 2.0

• PXCE — дополнительный уровень защиты для мобильных приложений