API Gatewayの背後にあるマイクロサービスはアクセストークンを検証する必要がありますか？

APIゲートウェイ経由でのみ外部からアクセスできるマイクロサービスがたくさんあります。

API GatewayはOAuthリソースとして設定され、1つ以上のマイクロサービスにダウンストリームのリクエストを渡す前にトークンを検証します（署名の確認など）。

私のマイクロサービスはスコープとクレームを検証するためにトークンを必要としますが、このサービスがトークンを検証する必要もあるでしょうか？

少しやりすぎのようですが、このシナリオについてオンラインでアドバイスを見つけることはできません。

APIゲートウェイでのトークンの検証は十分ですか？または、後でもう一度検証するのがベストプラクティスですか？

microservices

— fml
ソース

内部でゲートウェイをバイパスするときにこれらの同じサービスにアクセスできますか？

— グレッグバー

I cannot find any advice online about this scenario.それはプロジェクトごとに異なるいくつかの要因に依存するためです。おそらく、MSアーキテクチャであると主張しているほとんどの開発では、彼らはそれを必要としません。さらに、そのようなアーキテクチャー内では、サービスの代わりに（もちろんゲートウェイの代わりに）これを行う認証サーバーが必要です。リクエストの通過を許可する認証サーバーです。

— Laivは

内部呼び出しがゲートウェイをバイパスできる場合は、すべてのマイクロサービスでトークンを検証するか、すべての呼び出し（内部および外部）を強制的にゲートウェイを通過させます。

個人的には、内線も信用しません。ファイアウォールルールを介してトラフィックを制限するところまで、ゲートウェイを通過させます。誰が誰と話しているのか、そしてその理由を知る。これは、誰かがあなたのネットワークに違反した場合に、攻撃の表面を制限するのに役立ちます。

これは単一障害点をもたらしますが、このリスクは、サーバーのロードバランシングと、致命的な問題が発生した場合にフェイルオーバーサーバーを用意することで軽減できます。

一方、すべてのサービスがトークンを検証し、検証プロセスに関する変更があった場合、N + 1サービスを更新する必要があります。

— グレッグバーガード
ソース

「内部のトラフィックも信用できない」という議論を聞いたことがあります。しかし、アプリケーションをイントラネット上の（比較的）少数のユーザーに公開することは、同じアプリケーションをパブリックインターネットに公開することとはかけ離れています。それは本質的にスピーカーの磁石とサイクロトロンの違いと同じです。

— ロバートハーヴェイ

@RobertHarvey：私が聞いた「内部トラフィックを信頼しない」という正当化は、侵入が発生した場合にネットワークを壁で囲んでいるため、正当なトラフィックではありません。特に、システムがPII、健康、財務、または機密情報を処理する場合。誰かが侵入した場合、他に何を話すことができるかが制限されます。

— Greg Burghardt

誰かがあなたのシステムに侵入した場合、トークン検証はあなたの問題のより少ないでしょう。信頼できるネットワーク内でトークンを検証する必要があるかどうか（外部からはアクセスできないかどうか）は、Googleが行う検証の種類と、検証を再度実行していないかどうかによって異なります。たとえば、パフォーマンス。あなたの推論に戻ります。プライベートネットワークにTLSを実装しますか？互いに隣接して実行されている2つのコンポーネント間の通信を暗号化しますか？おそらく答えは異なります。

— Laivは