それでは、なぜOAuthで更新トークンが必要なのでしょうか?

確かに、OAuth 2.0を使用するすべてのプログラマーは疑問に思っていました。なぜ更新トークンが必要なのでしょうか。アクセストークンでは十分ではないのでしょうか。 64 KB-誰もが十分だ!



このトピックは非常に活発に議論されています。Stackoverflowに疑問ありHabréでも議論されています 。 実際、私が話すようになったのは、Habréに関する議論でした。



コメンテーターと著者によって提案されたすべての意見は、2タックアプローチのセキュリティに関連しています。 もちろん、セキュリティは許可/認証フレームワークの主なものであるため、これは当然のことです。 しかし、私たちは率直になります-多くの場合、2つのトークンを使用するアプローチは、1つのトークンを使用する単純で愚かなアプローチと比較して、セキュリティを向上させません。 または、これはすぐに表示されません...



「リフレッシュトークンはより安全に保存できます!」 -可能性があり、必要ですが、ほとんど誰もそれを行いません。

「アクセストークンはネットワークを介してより頻繁に送信されます-そして、その漏洩の可能性はより大きくなります」 -完全性、私たちは常にTLSを使用していますよね?

「Assessトークンのリークは、Refreshトークンのリークと同じくらい怖い」 -はい、これも事実です。これが、トークンがRefreshブラウザに発行されない理由です...



多くのニュアンスがあり、異なるトークンの使用が有用になる多くの使用シナリオがありますが、それらはすぐには見えません!



しかし、何らかの理由で私が会ったことがないというもう1つの議論があります-私の意見では、リフレッシュトークンが必要な理由と、アクセストークンなしで行うことは絶対に不可能である理由を完全に説明しています。



パフォーマンス。



そして、これは百万から千万人のユーザーがいるサイトやアプリケーションに関するものではありません!



Google、Facebook、TwitterサービスがOAuth認証でどのように機能するかを考えてみましょう。



このBig Access Token Serviceのバックエンドを入手しました。 有効性を確認する方法は?

さて、データベースで検索できます。 これは大文字のサービスであるため、データベースは大文字で大きく強力になります。



はい、このベースに問題があるようです。 inMemoryに入れて、複製されたコピーを追加しましょう...処理できますか? 私は推測する...



それとも、何を知っていますか? トークンに関するすべての情報を保持しましょう! 自己完結型トークンと呼ばれます。 もちろん、作成時に暗号化して署名し、受信時に署名を復号化して検証します。 そして、ユーザー名、彼の権利、トークンの有効期限など、必要なものをすべて抽出します。



はい、このアプローチは実際に機能するようです! 途方もなく高速で信頼できるトークンデータベースは必要ありません! 私たちのサーバーのどれか(そして私たちにはたくさんのサーバーがあります!)トークンの有効性を簡単かつ簡単にチェックし、トークンから権利とアクセスに関する必要な情報を抽出します。



ユーザーがパスワードを変更した場合はどうしますか? すべての古いトークンを無効にする必要がありますか? 管理者がユーザーをブロックしたり、権限を変更した場合はどうしますか?



はい、データベースなしではできません! さて、ユーザーの権利を常にチェックするのはやめましょう-時には、ある程度の合理的な間隔で。 さて、トークンの更新時、つまり1時間に1回としましょう。



はい、そうです。 認証サーバー側にOAuthを実装するプログラマーには、アクセストークンを受信するたびにトークン所有者の権限を確認するという選択肢があります。また、トークンの新しいペアを作成する場合にのみこれを行うことができます。

両方のアプローチの長所と短所は明らかであり(ビッグサービスには選択肢がありません)、自己完結型トークンスキームに従って動作します。



ここで判明したのは、この複雑な別の利点ですが、このような柔軟なフレームワーク-oAuth 2.0です!



All Articles