Voximplantでは、最近SDKの承認を改善しました。 結果を見ると、シンプルでわかりやすいトークンの代わりに、アクセストークンとリフレッシュトークンの2つがあったことに少し悲しみました。 定期的に更新する必要があるだけでなく、 トレーニング資料で文書化して説明します。 OAuthでは、主にそれらが使用されるサービスが異なるために2つのトークンが必要であることを思い出してください（ stackoverflowに質問がある場合でも）。そのようなサービスが1つあるので、私は少し気が狂って2階に行き、開発者から魂を揺さぶりました。 答えは予想外でした。 stackoverflowではありません。 しかし、彼はその下にいます。
なぜトークンが必要なのですか
サーバーと通信するアプリケーションを開発する場合、通常、次の手順が実行されます。
- アプリケーションは1人の開発者によって開発され、識別も認証も承認もありません（ちなみに、このトピックについてはDataArtから素晴らしい協力をお勧めします ）。リクエストはサーバーエンドポイントに直接送られ、開発者は満足しています。
- 2番目の開発者、またはテスター、または顧客が表示されます。 サーバーが要求を正確に送信するユーザーを知ることが重要になります。 識別ステップが追加されます。アプリケーションが起動する前に「自己紹介」する単純なウィンドウが表示され、「誰が再び3つの下に行ってすべてを壊したのか！
- チームが「誰が3ユニットでログインしたか」に少しうんざりすると、ログインパスワードを含む登録フォームがバックエンドで撮影され、一意のログインをチェックします。 このフォームでは、製品は最初のベータ版まで開発されます。
- 最初のベータ版では、パスワードをデバイスにプレーンテキストで保存することは、どういうわけか非常に安全ではないことがわかりました。 真空状態の球状のユーザーは、ほとんどのサービスから1つのパスワードを取得します。ユーザーのメール、vkontaktik、その他すべてがハッキングされた最後のパスワードになりたくありません。 ソリューションの検索「パスワードが明示的に保存されないようにするために行われること」が開始されます。 そしてしばらくして、チームは「認証トークン」の1つまたは別のバージョンにアクセスします。
最初のトークンが必要な理由
多くの異なるトークンがあります。 共通の暗号化、「アクセスキー」、「セッショントークン」、受信、使用、および失効のためのさまざまなスキーム。 同時に、重要なアイデアの1つは、誰かが悪い人が他のトークンを受け取った場合、起こる最も不愉快なことは、泥棒がトークンを盗まれたサービスにアクセスすることです。 パスワードは、すべてのサービスに使用されるパスワードであり、泥棒は受け取りません。 そして、ユーザーは、自分に加えて他の誰かがサービスにアクセスできることに気付いた場合、トークンを取り消すことができます。 次に、ユーザー名とパスワードを使用して新しいものを取得します。
なぜ2番目のトークンが必要なのですか
OAuth 2およびその他の承認スキーム（たとえば、 ours ）には、1つではなく2つのトークンがあります。 最初のアクセストークンは、サーバーへのクエリ時（たとえば、ログイン時）に使用されます。 これには2つのプロパティがあります。再利用可能と短命です。 たとえば、私たちは48時間生きており、誰かが30分持っています。 時間は、サービスの使用方法に基づいて選択されます。 2番目の更新トークンは、アクセストークンと更新トークンのペアを更新するために使用されます。 また、最初のトークンに反する2つのプロパティがあります。それは、使い捨てで長寿命です。 非常に長寿命で、私たちは一ヶ月住んでいます。
トークンの使用パターンは次のとおりです。
- ユーザーはアプリケーションにログインし、ユーザー名とパスワードをサーバーに渡します。 デバイスには保存されず、サーバーは2つのトークンとその有効期間を返します
- アプリケーションはトークンを保存し、後続のリクエストにアクセストークンを使用します
- アクセストークンのライフタイムが終了すると（アプリケーション自体がライフタイムを確認するか、サーバーが次の使用中に「ああ、すべて」と応答するまで待機できます）、アプリケーションは 更新トークンを使用して両方のトークンを更新し、新しいアクセストークンの使用を継続します
このようなことはすべて、WikipediaのドキュメントのOAuthドキュメントで説明されています。 そして、そのような説明は質問nafigに答えませんか？！？ 1つのトークンでできるのに、なぜ2つのトークンが必要なのですか？ stackoverflowの質問では、レベルについてのいくつかの説明があります。「アクセストークンは、リフレッシュトークンより安全性が低く、外部のHTTPS接続を使用することを恐れないで保存できます。 たとえば、フロントエンドにアクセストークンを保存し、バックエンドのリフレッシュトークン「または」リフレッシュトークンを使用して、既知のセキュリティで保護されたサービスにアクセスすると、アクセストークンをあらゆる種類の疑わしい場所に突くことができます。 Facebook経由でログインし、後でHTTPSなしで使用するのが賢明かもしれません。 ただし、HTTPSはどこにでもあります！ また、1つのサービスもあります。 なぜ2番目のトークンが必要なのですか？
なぜ2番目のトークンが本当に必要なのか
すべてが思ったよりシンプルで複雑であることが判明しました。 あなたの手を見てください：
ケース1：ボブはアリスの両方のトークンを認識し、更新を使用しませんでした
この場合、ボブはアクセストークンの有効期間中、サービスにアクセスします 。 有効期限が切れ、Aliceが使用するアプリケーションが更新トークンを使用するとすぐに、サーバーはトークンの新しいペアを返し、ボブが学習したトークンはカボチャに変わります。
ケース2：ボブはアリスの両方のトークンを認識し、更新を使用しました
この場合、アリスの両方のトークンがカボチャに変わり、アプリケーションはユーザーにユーザー名とパスワードでログインするように要求し、サーバーはトークンの新しいペアを返し、ボブが認識したトークンは再びカボチャに変わりますその場合、リフレッシュトークンを次に使用すると、ボブのトークンが右側に表示されるものに変わります）。
したがって、更新+アクセストークンスキームは、攻撃者がサービスにアクセスする時間を制限します。 攻撃者が数週間使用できるトークンと比較すると、誰もそれを知ることができません。