Нужен ли мне собственный провайдер oauth и / или openid

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

Система, над которой я работаю, будет иметь мобильное приложение, веб-портал и 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, который он хочет связать со своей учетной записью)

В другом месте я ссылаюсь на идентификатор пользователя, например:
Таблица фу:
- 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.