独自の OAuth および/または OpenID Connect プロバイダーが必要ですか?

独自の OAuth および/または OpenID Connect プロバイダーが必要ですか?

申し訳ありません...この質問を完全に言い換えたいと思います。同じ質問情報セキュリティについて

私が取り組んでいるシステムには、モバイル アプリケーション、Web ポータル、HTTP ベースの API が含まれます。

答えが見つからない質問:

OpenID ConnectやOAuthトークンエンドポイントを実装し、クライアントがアクセスするためのトークンを生成する必要がありますか?私のAPI ですか? それとも、ユーザーのオープン ID プロバイダーによって発行されたトークンを使用して、クライアントが API にアクセスできるように「何らかの方法で」するのでしょうか?

さらなる背景:

ユーザーが Google / Facebook ID を使用して登録およびログインできるようにしたいと考えています。

API 内には、いくつかの属性を持つユーザー テーブルを保存します。これ以上は必要ないので最小限ですが、基本的には次のようになります。
テーブル ユーザー:
- uid
- real_name
- contact_number
- email_address
- is_active
- have_admin_rights

次のように、ユーザーのオープン ID 用のテーブルも設定します。

テーブル open_ids:
- uid
- user_id (users(uid) を参照)
- open_id

(ユーザーは自分のアカウントに関連付けたい Open-ID をどれでも使用できるようになります)

他の場所ではユーザー ID を参照します。例:
テーブル foo:
- uid
- bar
- bla
- last_modified_by_user_id (users(uid) を参照)

現在、私のテスト設定には、「パスワード」テーブルがあります。例:
テーブル パスワード:
- uid
- user_id (users(uid) を参照)
- password_hash

(注: このテーブルをすぐに削除し、代わりに open_id を使用する予定です。ただし、どのライブラリを選択するかは、実装する機能と外部ソースから使用する機能によって大きく異なります)

ソーシャル サービス プロファイルに既に存在するユーザー データを複製したくないので、アクセス トークンを保存する必要があるようです。また、各ユーザーに対してこれらのサービスに随時アクセスする必要があります。しかし、クライアント (ユーザーがサインアップした場所) から API (さまざまなクライアント間で共有されるリソース) にアクセス トークンを取得するにはどうすればよいでしょうか。

問題は、クライアントから API にトークンを送信することではなく、ユーザーが認証されるときにユーザーとその他のエンドポイントを「登録」する関数を API に用意することです。問題は、アクセス トークンが特定のクライアントのみを対象としていることです。

認可サーバーを実装せず、Google などのサービスを何らかの方法で使用できると仮定します。Google、Facebook などの開発者サイトでクライアントを登録し、クライアント シークレット/クライアント ID を発行できますが、クライアントと API の両方から同じクライアント資格情報を使用するのでしょうか?

あるいは、クライアントの資格情報は API によってのみ保持され、フロントエンド サービスは、ユーザーが登録するときに中間ステップとして API に依存しているのでしょうか。これは、セキュリティが不十分であることの危険性が非常に高いと感じます。では、OpenID プロバイダーの視点から見ると、API は別のクライアントなのでしょうか。

承認サーバーを実装する必要があると仮定すると、Open ID プロバイダーでもある必要がありますか? この場合、認証と承認の両方が必要なので、Open ID Connect にする必要があるようです。しかし、この場合、新しいユーザー登録を実行する方法に関して本当に迷っています。以前の質問は実際には解決されません。クライアントが接続して、Open IdP からユーザー認証/アクセスおよび ID トークンを取得し、API を使用してユーザーを「登録」できるようにする必要があるようです。

関連情報