LINUX.ORG.RU

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

 , , ,


1

1

Есть endpoint’ы и entrypoint’ы. Есть мобильное приложение. Нужно сделать централизованную аутентификацию(по типу mama-cas) + мобильное приложение в firebase. Как это всё по логической цепочке делается?

Мобильное приложение авторизуется в firebase, потом обращается к микросервису auth, на котором mama-cas, все эндпоинты и энтрипоинты привязываются к сервису auth, и когда от мобильного приложения поступает запрос к API, в теле запроса должен быть token, который отдал auth мобильному приложению? При этом в auth еще нужно создать юзера с правами(и где его создавать или в auth или в endpoint-data, где лежит профиль юзера?), чтобы потом можно было рулить пермишенами

  1. схема авторизации. Вообще, как лучше ее делать? Сейчас предполагается использования только номера мобильного телефона. Но, скорей всего username делать именем телефона нельзя, т.к сегодня это номер телефона, а завтра авторизация через социалки. Что брать за основу username при регистрации? Стандартный метод username:password тут не получится использовать. В качестве username может использовать какой-то hardware-id телефона?

  2. Может ну ёё, эту django-cas-ng\mama-cas? На DRF сделать регу юзера и авторизацию с выдачей токена. А все endpoint’ы ? entrypoint’ы будут стучаться на auth по какому-то апи и чекать на наличие токена?

★★★★

Последнее исправление: bryak (всего исправлений: 8)

Для аутентификации и авторизации используешь keycloak.org, где есть OpenID, OAuth2 и SAML (выбираешь по своему вкусу), к keycloak-у цепляешь базу с пользователями (LDAP, RDBMS, …), а в django прописываешь middleware или https://django-keycloak.readthedocs.io/en/latest/

ma1uta ★★★
()
Последнее исправление: ma1uta (всего исправлений: 2)

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

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

Как именно это работает в джанго не знаю но подозреваю что не сложно сделать.

loz ★★★★★
()

Что брать за основу username при регистрации?

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

А для авторизации в таблицу юзеров добавить пару колонок - id способа авторизации (ну там phone, google, facebook, vk и т. д.) и уже специфичный для способа авторизации id пользователя (как с ним работать будет решать конкретная реализация механизма авторизации, выбранная по id способа авторизации).

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

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

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 3)
Ответ на: комментарий от bryak

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

loz ★★★★★
()
Последнее исправление: loz (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.