web-dev-qa-db-ja.com

リソース所有者の資格情報はOAuth2にどのように保存されますか

私は最近、oauth2を調査していて、実装計画を起草しようとしています。しかし、私は何かが足りないようです、または何かがまだ完全にクリックされていません。

私はAPIを作成し、特定のエンドポイントを保護し、認証を要求することを計画しています。このAPIは、javascript/vuejsを使用するファーストパーティWebアプリケーションを介してアクセスされます。

これを実現するには、「リソース所有者のパスワードフロー」が、リソース所有者がAPIの一部にアクセスするための認証を許可するための最良の選択のようです。私がoauth2に使用することを選択した特定の実装は、laravelの「パスポート」です。パスワードフローのサンプルコードと、この実装が使用するテーブルレイアウトを以下に示します。

$response = $http->post('http://your-app.com/oauth/token', [
    'form_params' => [
        'grant_type' => 'password',
        'client_id' => 'client-id',
        'client_secret' => 'client-secret',
        'username' => '[email protected]',
        'password' => 'my-password',
        'scope' => '',
    ],
]);


+-------------------------+
|oauth_clients            |
+-------------------------+
|id                       |
|user_id                  |
|name                     |
|secret                   |
|redirect                 |
|personal_access_client   |
|revoked                  |
|updated_at               |
|created_at               |
+-------------------------+

+-------------------------+
|oauth_auth_codes         |
+-------------------------+
|id                       |
|user_id                  |
|client_id                |
|scopes                   |
|revoked                  |
|expires_at               |
+-------------------------+

+-------------------------+
|oauth_access_tokens      |
+-------------------------+
|id                       |
|user_id                  |
|client_id                |
|name                     |
|scopes                   |
|revoked                  |
|created_at               |
|updated_at               |
|expires_at               |
+-------------------------+

+-------------------------+
|oauth_refresh_tokens     |
+-------------------------+
|id                       |
|access_token_id          |
|revoked                  |
|expires_at               |
+-------------------------+

+------------------------------+
|oauth_personal_access_clients |
+------------------------------+
|id                            |
|client_id                     |
|updated_at                    |
|created_at                    |
+------------------------------+

上記のリクエスト例では、client_idとclient_secretがusernameとpasswordとともに必要です。リソース所有者のusernameとpasswordを格納するテーブルがないため、提供されたパラメーターを使用してhttp://your-app.com/oauth/tokenを呼び出すと、リソース所有者が認証できる方法がわかりません。

誰かがここで何が起こっているのか、またはパズルのどの部分が欠けているのか説明してくれませんか？ OAuth2承認サーバーは、承認サーバーがユーザー名とパスワードに基づいてユーザーを認証できるようにするために、API（リソースサーバー）に関連付ける必要がありますか？...

authenticationoauth2
1
nullReference

OAuth2承認サーバーは、承認サーバーがユーザー名とパスワードに基づいてユーザーを認証できるようにするために、API（リソースサーバー）に関連付ける必要がありますか？...

それはニーズに依存しますが、はい、それはかなり一般的な実装です。ただし、OAuth2も認証プロトコルであると多くの人が信じるようになりました。そうでないとき。

トピックの追加の交絡因子として、OAuthプロセスは通常、そのプロセスにいくつかの種類の認証を含みます。リソース所有者は、承認ステップで承認サーバーに対して認証し、クライアントトークンエンドポイントの承認サーバーに対して認証を行いますが、他にも存在する可能性があります。OAuthプロトコル内のこれらの認証イベントの存在は、OAuthプロトコル自体が認証を確実に伝達できる。

-oauth.net-

OAuth2の目標は、資格情報を共有しなくてもアプリケーションが相互運用できるようにすることです。ユーザーを気にする必要はありません。 OAuth2は、ユーザーの識別方法を考慮しません。それは、さらなる検証のためにトークンとトークンの発行者のみを期待します。

リソース所有者のusernameとpasswordを格納するテーブルがないため、提供されたパラメーターを使用してhttp://your-app.com/oauth/tokenを呼び出すと、リソース所有者が認証できる方法がわかりません。

これは、資格情報の検証（認証）を他のユーザーに委任する必要があるためです。

この他の誰かは、あなた自身のアプリケーション（例えば、ログインエンドポイント）または外部のアプリケーションのどちらかです。たとえば、Facebook、Google、Githubなど。

MyApp.comという名前のWebアプリケーションがあるとします。私たちは、信頼できる他のいくつかのアプリケーションからデータを取得することにより、新規ユーザーが迅速に登録および認証されることを許可したいと考えています。たとえば、Facebookアカウントから。

もちろん、Facebookの資格情報をユーザーに要求することはできません。代わりに、面倒な作業をFacebookに委任します。認証プロセスはFacebookのOAuthにリダイレクトされます。

ユーザーはFacebookにログインし、プロフィールデータへのアクセスを許可します。

Facebookは、a）ユーザーIDとb）ユーザーアカウントに対する特権の証明としてトークンを生成します。このトークンはIDトークンとして知られています。

IDトークンは毎回Facebookに送り返されますMyapp.com Facebookと相互運用する必要があります。

IDトークンを取得したら、最初にFacebookユーザープロファイルを要求します。 IDトークンをリクエストで送信します。 Facebookがトークンを受け入れると、登録/ログインが完了し、ユーザーの通過が許可されます。

一方、MyApp.comにも独自のレジストリとログインがあります。ユーザーがMyApp.com資格情報を送信する場合、誰がIDプロバイダーになると思いますか？あなたは正しいと思います。 MyApp.com自体。ご覧のとおり、認証と承認は別物です。

リソース所有者の資格情報はOAuth2にどのように保存されますか？

上記のオプションによると、認証情報は独自のアプリケーション、中心的で共有されたIDプロバイダー（別名フェデレーテッドIDプロバイダー）に保存するか、ドメイン内のどこにも保存できません（Facebook、 Googleなど）。

考慮事項

アプリケーションが承認の唯一のコンシューマーである場合は、認証モデルをより単純なもの（JWTなど）に変更することを検討し、サービスをアプリケーション内に統合することも検討してください。最終的にはアプリケーションの認証サービスです。

2
Laiv

OAuth2 は、ユーザー/サービスに代わってサードパーティのリソースへの制限付きアクセスを許可するトークン交換のメカニズムを示しています。その中心には、 ベアラートークン の概念があります。その無記名トークンは、サーバーへの別のラウンドトリップなしで検証されるように設計されています。ベアラートークンの一般的で有用な実装は JSON Web Tokens（JWT） です。

OAuthにJWTを使用することは必須ではありませんが、多くの問題を解決します。

  • JWTは署名セクションを使用して検証できます
  • 作業を行うためのユーザーに関する十分なメタデータが含まれています
  • ユーザーロールのコレクションなど、アプリケーション固有のデータを含めることができます
  • 有効期限が切れて、自動的に再交渉することもできます

トークンに一連の許可（つまりユーザーロール）を含めることで、ベアラーのトークンが機能することを許可されているかどうかを確認するために、Webサービスが別のWebサービスを呼び出す必要がなくなります。

ここでAuthenticationについて話していないことにお気づきでしょう。これは、認証がOAuthの役割ではないためです。トークンサービスの役割です。たとえば、古いトークンを使用してアプリケーションを使用しようとした場合、そのアプリケーションがFacebookを使用して認証すると、ユーザーにはログインページby Facebookが表示されます。認証サービスは、ユーザーが本人claimであることを確認すると、トークンを発行できます。その後のすべてのサービス相互作用無記名トークンのみを使用。

0
Berin Loritsch