2

OAuth2.0 に関するこのチュートリアルに従ってい ます https://developers.google.com/youtube/v3/guides/authentication

OAuth2.0 がどのように機能するかは明らかです。しかし、アクセストークンの部分で少し混乱しています。

ユーザーのアクセス トークンを取得すると、アプリケーションはそのトークンを使用して、そのユーザーに代わって承認済みの API 要求を送信できます。API は、アクセス トークンを指定する 2 つの方法をサポートしています。 アクセス トークンを access_token クエリ パラメータの値として指定します。

www.googleapis.com/youtube/v3/videos?access_token=ACCESS_TOKEN

URL転送中に誰かがこのアクセストークンを取得した場合、この保護されたリソースにアクセスできますか?

最初にアクセス トークンを要求したクライアントからの要求であるかどうかをサーバーが認識する方法は?

更新: この投稿を読んだ後HTTPS ヘッダーは暗号化されていますか? 私の混乱は解消されました。ネットワークでの送信中にクエリ文字列が暗号化されていないと思いました。

4

2 に答える 2

1

一般的に、OAuth 2.0 はサーバー側のテクノロジーであり、ベアラー トークンは可能な限り安全に保つ必要があるため、すべてのアクセス トークンと通信は SSL を使用して送信する必要があるというのがコンセンサスだと思います。

于 2013-05-06T21:11:44.833 に答える
0

また、OAuth 2.0 には 2 種類のフローがあることも知っておく必要があります。
i) Implicit grant フロー- これは、ユーザーがサービス プロバイダーにログインし、ブラウザがアクセス トークンを取得するフローです。X.com を持っていて、Facebook 経由でログインしているとします。ユーザーが自分の FB 資格情報を入力すると、アクセス トークンがユーザーのブラウザーに送信されます。

ii)認証コード フロー- このフロー (上記の状況をもう一度考えてください) では、facebook は認証コードをユーザーのブラウザーに渡します。誰かが何らかの方法で認証コードを傍受した場合、彼にできることは何もありません。認証コードは、有効なクライアント資格情報とともに渡されると、アクセスと交換できます。そのため、ユーザーがログインすると、ブラウザは X.com のサーバーに渡される認証コードを取得します。そこから、FB が提供するコード トークン交換エンドポイントにアクセスし、サーバーに返されたアクセス トークンを取得します。

認証コード フローは、アクセス トークンがクライアント + サーバーにのみ表示され、ユーザー エージェントには表示されない、別のセキュリティ レイヤーを追加します。ご想像のとおり、トークンは HTTPS 経由で渡されます。

于 2013-05-07T04:30:48.157 に答える