oauth2によるRESTful API認証の混乱
RESTful API認証について調査を行いました。ほとんどの人がRESTful API認証のためにOAuth2を指しています。私はいくつかのリソース、特にこのリンク https://developers.google.com/accounts/docs/OAuth2 を調べました。
Oauth2はサードパーティのアプリがgoogle/facebook（または他のデータプロバイダー）のユーザーのデータにアクセスするためのものです。
私たちの問題は、データを所有していること、クライアントのサードパーティのデータにアクセスする必要がなく、クライアントがサードパーティのデータにアクセスする必要がないことです。なんらかの認証でAPIを保護したいと考えています。
私たちの場合、安らかなAPI認証のための便利なテクノロジーは何ですか？このようにAPIを公開します
https://ourdomain.com/api/<endpoint>
クライアントは最初にWebサイトにアクセスして登録 https://ourdomain.com を行うことができ、APIにアクセスするためにWebサイトからclientIdおよびclientKeyを取得できるはずです。私たちのクライアントはある種の認証を通じて消費できるはずです
私が正しく理解していれば、OAuthと同じように必要ですが、サードパーティのアプリにユーザーのリソースへのアクセスを許可することとまったく同じです。
OAuthには、アプリの認証情報+ユーザーの認証情報をチェックし、認証トークンを提供することで認証と承認を管理する中央システムがあります。これらの認証トークンを受け入れるエンドポイントは複数あります。
トークンは基本的に暗号化された文字列で、ユーザーの資格情報に関する情報と、アプリで必要になる可能性のあるその他の情報が含まれています。
必要なのは（私は信じています）、クライアントがその資格情報でヒットしてトークンを取得する同様の認証エンドポイントです。
そう、
i）クライアントが登録して資格情報を取得できる登録フォーム/コンソールを作成します。 this をご覧ください。
ii）ユーザーが資格情報をアクセストークン+更新トークンと交換するHTTPエンドポイントを定義します。
iii）クライアントは、アクセストークンでリソースエンドポイントにアクセスして、任意のエンドポイントに対して認証された呼び出しを行うことができます。
iv）バックエンドでは、トークンを検証して情報を抽出する共通サービスが必要です。
PS-これは単なる最小限のシステムです。不正なアプリがクライアントのアクセストークンにアクセスした場合など、セキュリティに関する多くの考慮事項があります。
CSRF攻撃、noonces、タイムスタンプ、およびセキュリティ上の懸念を軽減するその他の方法に関する多くの情報を見つけることができます。
oAuth 2.0では、いくつかのタイプの許可タイプがあります。許可タイプは、ある種の資格情報をアクセストークンと交換するための単なる方法です。通常oAuth承認コード付与によるサードパーティの使用法を指します。これは、認証のためにユーザーをリソース所有者のWebサイトにリダイレクトし、承認コードを返すことを意味します。
これはファーストパーティにとって明らかに意味がありませんoAuth使用します。あなたはリソースオーナーであるためです。oAuth 2.0はこれを考慮し、リソースオーナーのパスワード認証情報を含めましたこの目的のために付与します。この場合、ユーザー名とパスワードをファーストパーティレベルのアクセストークンと交換できます。
詳細は http://tools.ietf.org/html/rfc6749#section-4. を参照してください。
元の質問で明確にするために：
OAuth2には少なくともクライアントとサーバーが必要です
OPは、REST APIをセキュリティで保護する方法、そしてなぜ誰もがサードパーティの認証プロバイダー（Google、Facebookなど）について話しているのか）を考えていました
ここには2つの異なるニーズがあります。
1-個人用API（ourdomain.com）を保護できる
Client Server
Consumers <----> Your API
2-パブリックAPIを利用できる（たとえば、ユーザーのGoogle連絡先リストを取得する）
Client Server
You <----> Google APIs
OPは実際には1番目が必要です。独自のAPIの前にOAuth2サーバーを実装します。
Githubのすべての言語/フレームワークに多くの既存の実装があります
最後に、これが Nice Oauth2の技術的な説明の1つ であり、ここでそのスキーマの1つを恥ずかしがらずに取り上げています。
いいえ、私はGoogleで働いていません。単にGoogleをパブリックAPIサプライヤーの例として取り上げています。