2016-04-01 5 views
0

私はAPIとしてOauth2を理解しようとしています。最初に考慮すべき重要な点は、クライアントがoauth2を使用してAPIに直接認証しないことです。クライアントは公開鍵/秘密鍵のペアで認証されますが、クライアントはエンド・ユーザー向けのサービスで、oauth2を使用して認証できます。oauthユーザーと内部ユーザーを一致させるための承認コードフローまたは暗黙?

私は認証コードフローを使用しています。認証コードフローは、コード、一意のIDおよびoauth2プロバイダを含む一時テーブルを作成するリダイレクトuriでバックエンドを呼び出します。すべて正常に動作します。

考え方は、クライアントがoauth2の詳細からユーザーを作成するようにAPIに要求することです。クライアントのapiキーをその特定のユーザーに一致させるために必要です。問題は、認証コードフローでは、クライアント自体にトークンや一意のIDやコードに関する知識がないことです。私はここで間違った木を吠えると間違ったアプローチを使用していますか?

代わりに、暗黙的なフローを持つトークンが必要な場合は、そのトークンをそのトークンでリクエストして必要なデータを取得するAPIに渡します。

は、リソースサーバの後に利用できるように

答えて

0

は、認証サーバは、クライアントにトークンを発行するエンティティ、すなわちトークンに関連付けられているデータのデータでclient_idを含めることができますありがとうございましたトークン検証。

関連する問題