Извините .... Я хочу полностью перефразировать этот вопрос :, и я задал тот же вопрос по информационной безопасности сейчас
Система, над которой я работаю, будет иметь мобильное приложение, веб-портал и API на основе HTTP.
Вопрос, на который я не могу найти ответа:
Нужно ли мне реализовать конечные точки токенов openid connect и / или oauth и сгенерировать токены для доступа клиента? мой API? Или мне «каким-то образом» разрешить клиенту (-ам) получить доступ к API с помощью токенов, выпущенных поставщиком open-ID пользователя?
Дополнительная информация:
Я хочу, чтобы пользователи могли регистрироваться и входить в систему, используя свои идентификаторы Google / Facebook.
В API я храню пользовательскую таблицу с некоторыми атрибутами, минимальными, потому что мне не нужно больше этого, но по сути:
Таблица пользователей:
- uid
- настоящее имя
- Контактный телефон
- адрес электронной почты
- is_active
- have_admin_rights
Я бы также создал таблицу для открытых идентификаторов пользователей, например:
Таблица open_ids:
- uid
- user_id (Ссылки на пользователей (uid)
- open_id
(чтобы пользователь мог использовать любой из своих Open-ID, который он хочет связать со своей учетной записью)
В другом месте я ссылаюсь на идентификатор пользователя, например:
Таблица foo:
- uid
- бар
- бла
- last_modified_by_user_id (Ссылки пользователей (uid))
В настоящее время в моей тестовой настройке у меня есть таблица "паролей", например:
Табличные пароли:
- uid
- user_id (Ссылки пользователей (uid))
- password_hash
(Примечание: идея состоит в том, чтобы как можно скорее избавиться от этой таблицы и использовать вместо нее open_id. Но то, какие библиотеки я выберу, во многом зависит от того, какие функции я реализую и что использую из внешних источников)
Я понимаю, что мне нужно хранить токены доступа, поскольку я бы предпочел не дублировать данные пользователей, которые уже есть в их профилях социальных служб, и время от времени мне нужно получать доступ к этим службам для каждого пользователя. Но как мне получить токен доступа от Клиента (где пользователь зарегистрировался) к API (который является общим ресурсом между различными клиентами)
Проблема на самом деле не столько в отправке токена от клиента к API - я могу просто иметь функцию в API для «регистрации» пользователя и некоторых других конечных точек, когда пользователь проходит аутентификацию. Проблема в том, что токен доступа предназначен только для одного конкретного клиента.
Предполагая, что я НЕ реализую сервер авторизации и каким-то образом могу использовать службы Google и т. Д.: На сайтах разработчиков, например, для google, facebook, я могу зарегистрировать своего клиента и получить секретный идентификатор клиента / идентификатор клиента, но затем я использую одинаковые учетные данные клиента как от клиента, так и от API?
Или, может быть, учетные данные клиента хранятся только в API, а интерфейсная служба зависит от API в качестве промежуточного шага при регистрации пользователя? Это кажется ужасно опасным для незащищенности. Так является ли API еще одним отдельным клиентом в глазах провайдера OpenID?
Предполагая, что мне действительно нужно реализовать сервер авторизации, нужно ли мне также быть поставщиком open-id? Кажется, в этом случае это должно быть openid-connect, потому что мне нужно иметь как аутентификацию, так и авторизацию. Но в этом случае я действительно не понимаю, как выполнить регистрацию нового пользователя, и предыдущие вопросы не исчезают. Казалось бы, я должен позволить клиенту подключиться и получить токены аутентификации / доступа и идентификатора из Open IdP, а затем «зарегистрировать» пользователя с помощью API.