SergeySkripov: Новая страница: «Для того, чтобы пользователи приложения получали данные которые предназначаются только для них и не могли получить доступ к чужим данным и тем более изменить их нужно удостоверится, что пользователь, который прислал запрос не выдает себя за другого. ''...»

2024-10-18T17:33:21Z

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

Новая страница

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

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

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

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

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

Пример работы таких "сессий" можно увидеть в мессенджерах, соцсетях или банковских приложениях - они показывают с какого устройства кто и когда заходил и позволяют прервать это соединение.
[[Файл:Appmaster Auth UserSession.png|центр|безрамки|1000x1000пкс]]

В AppMaster есть готовые БП которые помогают зарегистрировать пользователя и аутентифицировать.

'''Регистрация'''

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

На выходе БП мы получаем профиль зарегистрированного пользователя (User) и токен сессии который нужно сохранить на клиентской стороне и использовать для дальнейших запросов.
[[Файл:Appmaster BP User Sign-up.png|центр|безрамки|1000x1000пкс]]

'''Аутентификация'''

Очень похожа на регистрацию выше, но не создает нового пользователя, а проверяет есть ли существующий с таким логином и паролем и если есть то возвращает профиль (User) и токен сессии.
[[Файл:Appmaster BP User Sign In.png|центр|безрамки|1000x1000пкс]]

'''Выход'''

Когда пользователь заканчивает работу в приложении или хочет войти под другим пользователем он должен прервать текущую сессию. Для это также есть отдельный БП. Он проверяет, какой пользователь вызвал этот БП, получает текущую сессию и завершает ее.
[[Файл:Appmaster BP User Logout.png|центр|безрамки|1000x1000пкс]]

По умолчанию вышеописанные БП уже привязаны к своим эндпоинтам и можно их сразу использовать.
[[Файл:Appmaster Endpoints User Auth.png|центр|безрамки|1000x1000пкс]]

Для тестирования можно использовать Swagger консоль в которой можно видеть какие запросы к серверу отправляются.
[[Категория:Appmaster]]

Appmaster Авторизация и аутентификация - История изменений