Oauth の概要

1.0 質問の概要

1. トークンの送信に jwttoken を使用すると、リソースサーバーはトークンをローカルでどのように検証しますか?

1.1 oauthの基本内容

1.1.1 認証とは何ですか

1.1.2 Oauth の役割

1.1.3 oauth 認証プロセス

1.1.4 4 つの Oauth モード

1.2 oauth2.0を使用する理由

1. 単一アーキテクチャを導入し、session を使用してセッション情報を保存する

2. フロントエンドとバックエンドの分離プロジェクト、メソッドの呼び出し

セッションアーキテクチャはフロントエンドとバックエンドの分離プロジェクトには適していません

3. 解決策、oauth2.0 への誘導

1.3 検証対象

構成ファイルはポートとコンテキストパスを構成します

アクセス時: http://localhost:8090/auth/lgoin /auth のレベルが設定されていない場合は、

http://localhost:8090/lgoin

2ケース構造

2.1 親プロジェクトのビルド

2.2 認証センターサービスの構築

2.2.1 認証センターのセキュリティと認証構成

1. 認証センターの構成

2. セキュリティ設定

3. エンドポイントにアクセスする

いわゆるアクセスエンドポイントは、アクセスを提供する URL インターフェイスアドレスです。

4. 4 つの検証モードの検証をテストします。

5. パスワードモードを構成ファイルに追加する必要があります：authenticationManager(xxxx) インスタンス

6. クライアントモード

2.2.2 リフレッシュトークン

一定期間使用した後、トークンの有効期限が切れたら、新しいトークンを取得し、パラメータと必要な設定を引き継ぐ必要があります。

2.2.3 Redis管理トークン

コンテナに追加する

2.2.4 jdbc管理トークン

2.2.5 jdbc管理認可コード

2.2.6 クライアント情報の保存

2.2.8 認証情報エンドポイントの検証

2.2.9 RBAC に基づくクエリデータベース認証

2.3 リソースマネージャーサービスの構築

2.3.1 原理の概要

リソースサービスサーバーは、実際には、注文サービス、製品サービス、会員サービスなど、呼び出されるさまざまなマイクロサービスです。マイクロサービスアーキテクチャでは、各マイクロサービスはリソースであり、ユーザーがマイクロサービスリソースを要求すると、まず認証サーバーによって認証と認可が行われ、その後、対応するリソースにアクセスできるようになります。

2.3.2 リソースサービスプロジェクトの構築

2.3.3 リソースサーバーテストのリクエスト

1. トークンなしの直接アクセス

2. アクセス用のトークンを持ち歩く

2.3.4 リソース要求スコープの設定

セッションを無効にする

2.4 認証と認可に jwtToken を使用する

2.4.1 jwt を使用する理由

リソースサービスにアクセスするたびにトークンの有効性を検証する必要があり、リモート呼び出し認証サービスでもトークンの有効性を検証する必要があります。アクセス量が多いとシステムのパフォーマンスに影響を与えます。解決策は jwt を使用することです。jwt にはユーザーの基本情報が含まれています。クライアントはリソースにアクセスするために jwt を運びます。リソースサーバーは事前に合意されたアルゴリズムを通じて jwt を解析し、jwt トークンを検証します。毎回リモートで認証サーバーを要求します。

2.4.2 認証サービスの設定 jwt 対称キー

以下に示すように:

各アクセスリソースサーバーは、このメソッドを実行してトークンの正当性を検証する必要があります。これにより認証サーバーに過大な負荷がかかるため、この状況を解決するメカニズムが必要です。jwt を使用すると、検証のために認証センターサービスの接続を呼び出すことなく、リソースサーバーで直接自身を検証できます。