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