ユーザー認証は、ユーザー・アクセス・サービスは、ステートレスHTTPに制限されたユーザーのID、特性を確認する際に参照する、アプリケーション開発者は、独自のユーザー認証関連の機能を実装する必要があります。
通常は、ユーザログは、クライアントに渡す生成されたサーバは、クライアントが要求を運ぶ次渡し、その後、サーバーは、チェックユーザー認証を通過します。
ユーザ認証が失敗した場合に特定のビジネスが何であれ、その後、後続のすべての操作を行うことができない、ユーザ認証が失敗したクライアント側に返す必要があり、HTTPステータスコードに対応しては401です。
この論文では、マイクロサービスアーキテクチャ、変更のユーザ認証機能の実装にスタンドアロンアプリケーションからの流量及び成長の規模、サービス開発プロセスとして。
スタンドアローンアプリケーション
この段階では、アプリケーションのセッションは、このマシンのメモリ/ディスクに保持した後、クライアントを伝えることができ、セッションIDを生成します、唯一のサーバです。多くが内蔵されているボックスの外に実装されたWebフレームワークは、簡単なユーザー認証の存在に気づくための時間を持っていませんでした。
アプリケーションサーバは、多くの場合、十分ではありませんが、いくつかの理由があります。一つは、あまりにも多くのトラフィックを運ぶことができなかった、サービスの可用性にリンクされているマシンが低すぎるハング...
ロードバランシング
ユーザーが1台のマシン、別のマシンにはおそらく次回の訪問にログインした後ので、複数のサーバーなので、それは単にセッションではありませんし、その後マシン上で維持しました。
- オプションA：認証トークン
あなたは、ユーザーに文字列にエンコードされた情報の一部にログインすると、クライアントに返され、クライアントは、その後の操作でサービス側の検証文字列をこの文字列操作を運び、文字列は正当で、文字列から認定されていますユーザーのID情報を読み取ります。
これは、再びセッション情報サーバー側を格納する必要がなくなり、簡単に複数のサーバをサポートしています。そして、これは単なる軍事クリアランストークンのように、我々は、認証トークンを呼び出し、文字列を認証するために使用されます。
認証トークンの形式は、使用するURLを置くことができるように、耐タンパ性をするために、有効期間をできるようにするには、慎重な設計を必要とするだけでなく、その上の延長、およびすることができます。使用するJWTあまりにも難しい場合はもちろん、再設計が可能であり、また、JWTと呼ばれる規格を形成し、優れたトークン形式を設計されています直接使用することができます。
ここではJWTのある簡単な紹介。
この方式の認証トークンの欠点は、クラウド管理ログイン状態を達成することは困難です。通常、トークンの生成後、それだけの期限が切れるのを待つ、または有効にするには、ユーザーID情報の変更をエンコードするそのうちのいくつかは時にすることができます。ゴードンのように戻って、ユーザの失敗した場合に、ユーザーのオンライン・デバイスの管理、ユーザーのログイン状態の制御および他の機能は、達成するための方法はありません。
- プログラムB：分散セッション
そこセッションが分散セッションを形成し、別のを維持するために、アプリケーションサーバから来るプログラムもあるので、各アプリケーションサーバは、利用可能なアクセスすることができます。
達成するために具体的なので、上のセッションRedisのは、MySQLとを配布することができます。しかし、関係なく、それに依存しているどのようなストレージ・システム、強力なユーザー認証サービスの可用性の種類、サーバーがストレージ・ソリューションと比較して認証トークンを必要としません、可用性は確かに比較的低くなっています。
- スキームA + B
認証トークン2が正当化スキームとなっ組み合わせるためのセッションの可用性の相対的な不足を分散機能の喪失は、そこにあります。
認証セッションIDとトークン、通常のサービス、ユーザ認証は、セッションを分散している場合確認し、セッションに依存する分散型ストレージシステムは時折失敗した場合、サービスの低下、唯一の代わりに認証トークンを確認します。このような可用性が保証され、機能が完了です。
あなたがサービスにログインする必要がある場合は、分散セッションはあなたにもセッションのタイプとトークン内部の非セッションを区別するためにフィールドを追加することができ、非常に入手可能です。
マイクロサービス
事業の大規模化、より多くのチームの数。一緒にますます困難に保守サービス、サービスを必要としているスプリットが、どんなに削除して、ユーザー認証は、各エンドユーザー向けのサービスが必要とされています。
ユーザー認証は、限り、関連するすべてのコードのコピーを取るためにスプリットタイムとして、その後、個々のサービスは、ユーザー情報や分散セッションに依存する必要があり、必要とされます。
維持するが、ユーザーの認証関連の機能を分割し、別々のユーザ認証サービスを形成するので、あまりにも難しいです。このサービスはインターネット企業のほぼすべての大きなポイントは、同じ名前、パスポートと呼ばれるいくつかの、およびいくつかのと呼ばれるアカウント、およびいくつかのと呼ばれるユーザーを持っていないが、関数は常に同じです。
このようにして、ログイン、登録、ユーザ認証関連コード、データ、オンライン展開、完全に独立し、ユーザ認証サービスを形成します。ビジネスが成長するにつれ次に、サービスはますますを分割していきます。サービスのエンドユーザがユーザ認証サービスに依存している、特にためにほとんどのサービスは、サービス間の依存関係があるかもしれません。
彼らは、より多くの、繰り返しのドッキングは、多くの時間を必要とし、ユーザの要求で他には、多くの場合、個々のマイクロドッキングサービスの利用者認証の場合には、複数のマイクロ・サービスを必要とするユーザ認証サービスの独立したマイクロサービスになります依存します複数のユーザ認証、複製要求、資源の浪費になります。
APIゲートウェイ
APIゲートウェイの外部ネットワーク、署名とユーザ認証は、すべての外部インターフェイスは、一緒に収集します。APIゲートウェイは、ユーザーの認証トークンを受信した後、ユーザーID、ユーザIDと引き換えにユーザ認証サービスに移動し、他のマイクロサービスにアクセスするために使用します。このようなサービスは、各マイクロユーザーのUIDサービスに応じて提供され、もはや唯一のAPIゲートウェイを突き合わせする必要があるエンドユーザーの認証、およびユーザ認証サービスを心配する必要がある、彼らの作業負荷が大幅に軽減されません。
参照
https://www.slideshare.net/opencredo/authentication-in-microservice-systems-david-borsos