2

そのため、OAuth2 でプロバイダーを実装しています。

クライアントが client_id と client_secret を申請する部分を取得します。これにより、プロバイダに対して一意に識別されます。

それで、彼らはそれを手に入れ、SSL を使用するようになったのに、なぜ認証トークンが必要なのですか? そして、その後、なぜ認証コードが必要なのですか？

また、なぜリフレッシュトークンなのですか?

client_id と client_secret だけを使用できないのはなぜですか? エンド ユーザーの承認に基づいて保護されているリソースについては、追加の承認が必要であることがわかりました。それはとても理にかなっています。しかし、なぜ認証トークンとコードなのですか?

最後に、エンドユーザーが保護されていないリソースにこれらすべてが必要ですか?

だから、それは私が理解するのを助けるために5つの異なる質問だと思います:

  1. 認証トークンを使用する理由
  2. 認証コードを使用する理由
  3. リフレッシュ トークンを使用する理由
  4. 保護されていないリソースにクライアント資格情報を使用しないのはなぜですか (または使用できますか)?
  5. 認証トークンとコードの両方を使用するのはなぜですか? （これは1と2の両方で答えられると思います）。
4

1 に答える 1

4

ネクロポストで申し訳ありませんが、これが将来の参考のために誰かに役立つことを願っています.

最初に and と呼ばAuthorization CodeれAccess Tokenます。

  1. Access Tokenリソースにアクセスする権利を表す文字列です
  2. Authorization Codeリソース所有者がクライアントに与える承認を表します。ほとんどの場合、リソース所有者は、サーバー上のリソースを所有する最終的なユーザーです。クライアントはそれらのリソースにアクセスしたいので、ユーザーからの承認が必要です。
  3. Refresh Token期限切れの更新に使用されAccess Tokensます。通常、アクセス トークンの有効期間は数分ですが、更新の有効期限は数か月、数年などです。アクセスのものを使用します。それらが古くなったら、更新トークンを使用して新しいアクセス トークンを取得します。OAuth1 では、何ヶ月も持続するトークンの種類は 1 つだけだったことに注意してください。プロトコルのセキュリティを向上させるために、短命のトークンが導入されました。
  4. わからなかったと思います。リソースが保護されていない場合は、OAuth を使用しないでください。とにかく、クライアントがリソース所有者であると考えられる場合に使用するクライアント資格付与があります (ここでは例を示します .
  5. 1. と 2. を参照してください。それらは異なり、2 つの異なるチャネルを介して送信することもできます (ただし、異なるチャネルの使用法はまだ見つかりません)。

要するに、クライアントが認証コードを持っている場合、クライアントは認証サーバー (AS) に次のように言います。そして AS はクライアントにアクセス トークンを与えます。クライアントはトークンを取得したので、リソース サーバーに移動します。

4 つのフローがあり、それぞれが異なるタイプの Authorization Grantを使用し、そのうちの 1 つだけが Authorization Codeであることに注意してください。それはすべて言葉についてです。メカニズムについては、まずこの (少し古い) 紹介を読み、次にRFC 6749をもう一度読み、これらのことを念頭に置いてください。

より明確なアイデアが得られることを願っています。

于 2013-01-29T01:03:19.983 に答える