メモリ、トークンに格納されています
サービスコードの最適化を継続する当社の承認。今、認可サービス、トークンストレージがメモリに格納され、我々はInMemoryTokenStoreを使用します。
tokenStore方法の図は、見てのストレージトークンの様々なサポートしています。
InMemoryTokenStore：このバージョンは、デフォルトの実装が使用され、それは単一のサーバー上で完璧に動作します（つまり、圧力は同時アクセスの量でない場合、あり、そしてそれは、障害時にバックアップされません）、プロジェクトのほとんどあなたはそれをディスクに保存されないので、あなたは、管理するために開発時に使用することができ、達成しようとするこのバージョンを使用することができ、それはデバッグが容易です。
JwtTokenStore：このバージョンでは、トークン、データが符号化されているに関連付けることができますJSONウェブトークン（JWT）、（バックエンドサービスのために、それを保存する必要はありませんので、それは大きな利点となります）の略で、それが持っています通常、トークンの短いライフサイクルに対処し、トークンの撤退（refresh_token）をリフレッシュするために使用されるようにトークンを取り消すことを許可された一つの欠点は、非常に困難になります。別の欠点は、あなたがより多くのユーザーの資格情報を結合する場合は、トークンの占有スペースは、比較的大きくなるということです。JwtTokenStoreは、任意のデータを保存しませんが、それは同じで演奏尊重DefaultTokenServicesの役割を持つトークン値と認証情報を変換します。
JdbcTokenStore：これは、リレーショナル・データベースに保存されますJDBCベースのトークンの実装です。この実装を使用する場合は、トークンは、あなたが注意してください使用して、異なるサーバ間で情報を共有できる「春-JDBCは、」これはあなたのクラスパスに加えて、それらに依存しているとき。
RedisTokenStore：これはRedisのベースのセキュリティ・トークンの実現であるがRedisのキャッシュです。この実装を使用する場合は、あなたが異なるサーバ間で情報を共有できるトークンは、あなたのクラスパスに追加し、それらの時間依存のRedisの使用を注意してください。違いであると注意を必要とする何のRedisデータベースのストレージおよびデータについては、それはここでは説明しません。
InMemoryTokenStoreが格納されているデフォルトでは、照会、削除、我々が見て、最初のBeanとしてInMemoryTokenStoreを設定することができます。
そして、とき豆の設定を呼び出します。
私たちは、トークンの動作するInMemoryTokenStoreクラスを見て：
メソッドの名前からわかるように、操作の検索トークンを変更するには、追加や削除は基本的に完了し、我々は照会およびトークンを削除するために、2つのメソッドを記述する必要があります。
以前のプロセスに従って、トークンとトークンのクエリには適用され、InMemoryTokenStore以前に定義された豆、次のテストを見て、メモリのトークンで動作する唯一の方法の範疇に注入されています。
その後、トークンのテストを削除します。
そして、トークンクエリの下で保護されたリソースにはアクセスできなく見つけることができます。
基本的な機能は、テスト環境に加えて、中であるが、欠点上述したように、上記単一サーバーでのみの作業で、デフォルトの実装トークンを共有することはできませんが、また良い選択であるメモリストレージを使用してメモリを使用します。
Redisのストレージトークン
メモリに記憶することができるトークンに加えても問題はそれほど単一サーバのデータの同期を解決することができないが、そのようなRedisのような公共の場所に格納することができます。最初に保存されているがRedisの依存関係を導入します：
次に、データソースを設定します。
そして、認証の設定クラス、ストレージRedisのBeanの設定を変更します。
そのようなRedisのストレージトークンの基本設定が完了し、その後、前のメモリ記憶動作は、次の照会のための2つのインターフェースを記述し、トークンにRedisのを削除します。
あなたは私たちが得るトークンを格納する見ることができ、前のトークン手続き、保護されたリソースへのアクセス、そしてビューのRedisに従って取得したプロジェクトを、開始します。
ビューのクエリトークン界面効果：
トークンインタフェースを削除する効果を見てください：
削除した後、トークンのRedisも削除：
3つだけは、キーを更新します。
JDBC保存されたトークン
動作クラスがJdbcTokenStoreで、私たちはこのクラスを見て、また、トークンシェアを行うことができます。jdbcストレージトークンの方法を使用します。
構造oauth_access_tokenテーブルを見て、oauth_access_tokenとoauth_refresh_token（クライアントがgrant_typeのrefresh_tokenをサポートしていない場合、テーブルが使用されていません）：クラス2つのテーブルの合計を含む、SQL文の多くのデフォルトのアクションを定義します。
token_id：このフィールドの値は、MD5暗号化されたストレージにより、access_tokenはの値であり、
トークン：バイナリデータOAuth2AccessToken.javaオブジェクトシリアライゼーション格納は、実際のデータ値であるAccessToken
authentication_id：このフィールドは、現在のユーザ名（もしあれば）に基づいており、範囲は、MD5によって生成CLIENT_IDその値がDefaultAuthenticationKeyGenerator.javaクラスを参照の具現、ユニークです。
USER_NAME：ログインユーザ名、ユーザ名、クライアントが（例えばgrant_type =「client_credentials」）していない場合、値はCLIENT_IDに等しいです
CLIENT_ID：あなたが知っています
認証：バイナリデータオブジェクトシリアライゼーションを格納した後OAuth2Authentication.java
refresh_token：このフィールドの値は、MD5によって保存されたrefresh_token値であります
oauth_refresh_tokenテーブルのフィールド構造を見て：
token_id：このフィールドの値は、後にMD5暗号化されたストレージでrefresh_token値です。
トークン：OAuth2RefreshToken.javaオブジェクト直列化バイナリデータを格納します。
認証：バイナリデータオブジェクトシリアライゼーションを格納した後OAuth2Authentication.java
データベースで2つのテーブルを作成します。
その後、コンフィギュレーション・ファイル・ソース内のPOM JDBC依存構成データ、ここではありませんデモに導入されます。次の権限の設定クラスを変更します。
最後にフロントをモデルに、2つのクエリを記述し、トークンインタフェースを削除します。
トークン格納するデータベース、および以前の二つの方法よりも多くの操作方法、JdbcTokenStoreカテゴリを見て：
デフォルトのオーバーライドを設定しても、書かれたSQL文を含むマルチCRUDいくつかの方法を動作に加えて。まずは前の手順でトークントークン合わせを取得し、データベースを照会し、テストしてみましょう：
あなたは、クエリのトークン・インターフェースを見て、二つ以上のトークンデータベースのデータを見ることができます：
インタフェースを削除します。
送信元インターフェイスの呼び出しを削除する方法を見てください：
ただ、トークンを削除し、トークンの更新記録も保持しました。
コード住所：https://gitee.com/blueses/spring-boot-security 23 24
ブログ記事複数のプラットフォームからこの記事OpenWriteリリース！