API Gatewayセキュリティ（マイクロサービスアーキテクチャ用）
最近はマイクロサービスから始めましたが、セキュリティ層の実装に問題があります。
アイデアは、リクエストがゲートウェイに届き、ゲートウェイが認証ヘッダーを調べ、ユーザーを検証し、JWTトークンを作成してから、ユーザーに関する情報を含むリクエストを別のマイクロサービスに内部的に送信するというものです。マイクロサービスは内部でのみ到達可能であるため、JWTトークンを信頼します。
最後のプロジェクトでは、ユーザーに関する基本情報をゲートウェイに入れました-登録、ログイン、パスワードのリセットなどができました.
しかし、問題は、コアマイクロサービスもユーザーを処理していたことです。つまり、検証する必要のあるフィールドがいくつかありましたが、ゲートウェイでは必ずしも必要ではありません。登録プロセスは最初にマイクロサービスで検証する必要があり、問題がなければ、ゲートウェイ（パスワード、電子メール）とマイクロサービス（電話番号、名前など）の両方に登録されました。
問題は、マイクロサービスの1つで失敗しても、もう1つのマイクロサービスがそれを認識していない場合です。次に、ゲートウェイに登録されますが、マイクロサービスには登録されません。基本的には、「マイクロサービス間のトランザクション」に注意する必要があることを意味します。これは、望まないことです（ステートレスマイクロサービスの使用が最適です）。
また、一部の要求（特に登録）は非常に具体的に処理する必要があり、コードベースとゲートウェイの複雑さが増します。
私たちは別の解決策について考えています：
1）ユーザーロジックがゲートウェイに配置されます。これは現在の状況と似ていますが、コアマイクロサービスの検証が行われないため、ステートレスになります。コアマイクロサービスは新しいユーザーをレイジーにロードします-JWTトークンを開いてそれが見つからない場合は作成します。
2）2つのマイクロサービスがあり、1つは登録とユーザー自体、もう1つはその他の機能です。承認ベアラが見つかった場合、ゲートウェイはユーザーサービスのマイクロサービスに詳細を要求し、問題がなければ、JWTトークンに情報をパックして送信します次。登録はユーザーサービスに渡されるだけです。コアマイクロサービスも遅延読み込みされます。
3）ユーザーサービス機能をコアマイクロサービス自体に組み込みます。これにより、「よりモノリシックな」アプローチが可能になりますが、コアマイクロサービスはユーザーに大きく依存しています。 （彼らはグループに登録し、製品を購入するなど）。ゲートウェイはケース2）と同様に機能し、コアマイクロサービスにユーザー情報を問い合わせ、JWTトークンをパックして次に送信します。
また、中小規模のプロジェクトを開発していることにも注意してください。プロジェクト全体では通常、ゼロから本番稼働まで1000〜4000工数を使用し、バックエンド自体は500〜1500工数かかります（通信しているサーバーを含むほとんどのモバイルアプリを開発しています）。
「リクエストはゲートウェイに届き、ゲートウェイは認証ヘッダーを調べ、ユーザーを検証し、JWTトークンを作成してから、ユーザーに関する情報を含むリクエストを内部で別のマイクロサービスに送信します。マイクロサービスは内部でのみ到達可能であるため、JWTを信頼しますトークン。"
これは間違っています。 JWTトークンはクライアントに認識され、すべてのリクエストで送信されます。すべてのサービスは、トークンを検証するだけでなく、トークンを信頼する必要があります。
APIゲートウェイにはロジックがありません。そのちょうどネットワークインフラストラクチャ