認証と承認-フロントエンドとバックエンドのジレンマ
集中認証と承認のAPIシステムに取り組んでいて、フロントエンドとバックエンドのジレンマに悩まされています。
フロントエンドの担当者は、JWT、ユーザーロール、ユーザーデータを含むレスポンスバックと同時にユーザーを認証および承認するために、そのAPIへのリクエストを1つだけにする必要があることを伝えています。
バックエンド担当者は、フロントエンドは2つの呼び出しを持つ必要があると主張しています。最初にJWT応答でのみユーザー（ログインプロセス）を認証し、次にユーザーのアクセス許可、ロール、ユーザーデータの取得を承認します。
どちらのアプローチが正しいですか？個人的には、最初の提案の方がより論理的だと思いますが、バックエンドの人が「承認のためにAPIに2番目の呼び出しを追加することはできます」と言わないようにする良い例は見つかりません。
バックエンド担当者が有効な正当化を省略した可能性があります
バックエンド担当者は、フロントエンドは2つの呼び出しを持つ必要があると主張しています。最初にJWT応答でのみユーザー（ログインプロセス）を認証し、次にユーザーのアクセス許可、ロール、ユーザーデータの取得を承認します。
額面通り、1つのワークロードを2つのネットワーク呼び出しに分割する理由はほとんどありません。 2番目の呼び出しのオーバーヘッドコストは、ワークロードを解決するための時間に追加されるだけです。
しかし、私はあなたのバックエンド開発者が有効なポイントを持っているかもしれないが、それを完全に表現していないと思います。
ログインアクションが認証情報も返すことは理にかなっていますが、承認のみの呼び出し、つまりユーザーロールとユーザーデータの取得なしログインが必要な場合も同様に役立ちます。データの一部がクライアント側で破損する可能性は常にあります（例：役割/アクセス許可データ）。JWTがまだ有効であるにもかかわらず、ユーザーに再度ログインするように強制するのではなく、認証データをサイレントに再フェッチすることをお勧めします。
一般的に紛争に対処する方法
どちらのアプローチが正しいですか？
客観的に正しいアプローチが1つあると誰が言ったのでしょうか。
ここで重要なのは、BE/FEの議論の核心にドリルダウンしていないということです。あなたは両方の当事者が何を望んでいるかを知っていますが、実際には把握していません[〜＃〜] why [〜＃〜]彼らはそれを望んでおり、それは最も重要な情報です。
あなたの質問が明らかにするように、あなたは伝えられてきたことを理解していますが、どちらのアプローチの賛否両論を実際に比較することはできません。引数にドリルダウンすると、詳細が表示されます。誰かが「私たちはXをする必要がある」と言うときはいつでも、即時の応答は「なぜ？」であるべきです。
基本的な例として：
[〜＃〜] be [〜＃〜]呼び出しを分離する必要があります。
あなたなぜですか？
[〜＃〜] be [〜＃〜]ログインアクションは非常に負荷が高く、認証情報の取得のみに関心のあるリクエストはすべて処理できなくなるためです。[〜＃〜] fe [〜＃〜]これらの呼び出しをマージする必要があります。
あなたなぜですか？
[〜＃〜] fe [〜＃〜] 2番目の呼び出しは本質的に追加の処理時間、つまり2番目の呼び出しのオーバーヘッドコストが発生するためです。
これで、オプションを比較検討できるようになります。ここには明らかな矛盾があり、どちらもパフォーマンスに関連しています。しかし、少なくとも今、両方の問題を解決する方法を見つけるか、2つのオプションを比較検討して、2つの悪の小さい方を選ぶことができます。
あなたは両方の当事者に彼らが望むものを与えることができます
そうは言っても、両方の開発者が望むものを与えることによって問題を解決する簡単な方法があります。 login、getAuthorizationInfo、およびloginAndGetAuthorizationInfoの3つのAPI呼び出しを追加するだけです。
それはすべての問題を解決します：消費者が両方のことを一緒に行う必要があるとき、彼らは間接費を節約するために結合された方法を呼び出します。消費者が1つのことだけを行い、他のことを行う必要がない場合、不要なタスクが実行されないようにすることでパフォーマンスを節約します。
実装コストはほとんどありません（結合されたメソッドは実際には他の2つのメソッドを呼び出すだけです）。これにより、両方のパーティに必要なものが正確に提供されます。
Note：大量の複製が発生するため、発生するすべての競合に対して「 両方ではないのですか 」というアプローチを盲目的に行わないように注意してください。考案されたコードベース。この特定のケースでは、両方の引数が有効であることがわかった場合（そして、どちらかが悪い場合でもどちらの悪も選択するつもりはありません）、tiny「両方」のアプローチのフットプリント。それはBE/FE競合の合理的な解決策です。
余談として
フロントエンドの担当者は、JWT、ユーザーロール、ユーザーデータを含むレスポンスバックと同時にユーザーを認証および承認するために、そのAPIへのリクエストを1つだけにする必要があることを伝えています。
このケースでは同意しますが、消費者がとにかく認証情報を要求する可能性が高いため、ログインアクションでも認証情報が返されることは理にかなっています。 FEがBEが何をすべきかを指示しようとしていることに私は不機嫌です。私自身はBE開発者として偏っているかもしれませんが、APIはBE開発者の管理下にあり、彼らはここで決定を下します（とはいえ、他のユーザーのフィードバックを考慮に入れることは明らかに良いことです）。
これは余談ですが、中間点に到達できないBE/FEの利益相反にこれを一般化する場合、各当事者はドメインについて最終的な発言権を持つ必要があります。
下のコメントから追加
少々揮発性の点です。理想的には、APIの定義はテクニカルアナリストに任せるのが理想的です。しかし、純粋にBE/FEが自分のためにそれを理解することに専念している場合、針はBEに向かってエラーになるはずです。彼らは、BEがどのように構築され、それが合理的に処理できるものと処理できないものを知っています。
私が言ったように、それはFEからのフィードバックが完全に無視されるべきであるという意味ではありませんが、FEもBEの決定を完全に上書きすることはできません。相互の合意が明らかに好ましいですが、それが達成できない場合、最終的な発言はBEにあるべきです（私の専門家の意見）。
コメントで@Adrianoが述べたように、2つのサービスが異なるエンドポイントにある場合は理にかなっており、もちろんそのような設計がたくさん見つかります。しかし、たった1つの要求については、それはあなたのビジネスに基づいていると思います。
1つまたは2つの呼び出しで2つの関数が必要であるとしましょう。
- ユーザーが誰であるかを知る
- ユーザーができることを知っている
only 1番目または2番目の関数が必要なシナリオがある場合は、それらを分離するのが妥当です。
近い将来、認証と承認が2つのサービスになるという明確な計画がある場合は、それらを分離するだけです。
それ以外の場合は、バックエンド開発者と連携して、ビジネスコンテキストから2つの呼び出しが必要な理由を確認する必要があると思います。