様々なライブラリや IDaaS のおかげで、ユーザー認証を簡単に組み込むことができるようになり、一定のセキュリティレベルを持ったアプリケーションを簡単に作れるようになりました。
特に、Amplify + AWS Cognitoコンビに助けられているアプリケーションも多いと思います。（ちなみに私自身は安易にAmplifyで作りこまないで欲しい派です。これは別記事にまとめたい。）
本記事では、ユーザー認証を組み込んだ後の話、認証情報のチェックはどこで行うべきかという点にフォーカスしていきます。
何のための認証チェック？
そもそも、ユーザー認証はなぜ必要なのでしょうか？
それはそのユーザーに紐づくデータを守る必要があるからという点に尽きます。
もし Browser Storage に保存するデータのみで完結する アプリケーションなら、当然認証は必要ありません。
認証チェックはどこに置く？
1.Backen(BE)
上述したとおり、データを守るための認証処理なので、まず第一にデータ層から近いところにチェックを設ける必要があります。
一般的には、BE の API や Api Gateway に仕込むと思います。Asp.Netなどの Framework でそういったチェックを行う機構が提供されているものもありますね。
そしてここで重要なのが、認証エラーであることを明示して、エラーを返してあげることです。ここをサボって、他のエラーと混同など絶対にしないでください。
HTTP Status Code にも401:Unauthorizedエラーが用意されているように区別して返してあげることがポイントです。
2.Frontend(FE)
BE に認証エラーハンドリングを整備したら、次に考えるのが FE です。
ちなみにAmplifyなどのライブラリでは、FE で完結するような認証チェック機能を提供しているものもあります。
そのため、FE 単体で認証チェックを考えてしまいそうになりますが、FE 単体だとどうしてもユーザーアクションベースで認証チェックを考えてしまい、チェックポイントが発散してしまいます。
何より FE にどれだけ完璧な認証チェックを置いたとしても、BE が公開されている限り、直接アクセスされてしまえば全く意味が無くなるので、とにかく BE から認証チェックを考えると良いですね。
BE リクエスト時
BE リクエスト時に認証エラーをハンドリングする処理を置けば、認証チェックは 99.99%くらい完成です。
上述したように、BE からは認証エラーが明示的に返されるので、それをユーザービリティを第一にハンドリングしてあげてください。
Token ベースであれば、Refresh Tokenを用いて、Access Tokenを再取得し、リトライする機構が必要ですし、Cookie Session ベースなら無条件にサインイン画面に引き戻すことでユーザーが次のアクションを起こしやすくなりますね。
ページ遷移時（Nice To Have）
実際、FE に関しては BE リクエスト時のハンドリングでほぼほぼ完成ですが、よりセンシティブにチェックするのであれば、アプリケーションへのアクセス時含むページ遷移のタイミングでチェックしても良いでしょう。
ちなみに、私が関わったプロジェクトの一つでは、ユーザーアクション全てに対して、認証チェックを行ったものもありました。この辺もユーザービリティとセキュリティのトレードオフなので要件次第というところですね。
最後に
実を言う私も、FE 側の認証チェックに憑りつかれ、チェックポイント難民になりかけた経験があります...特に、FE と BE でチームが分かれている場合だとそういったことが置きやすいかもしれません。
認証の領域は技術負債になりがちなので、なるべく早く返済もしくは、借金を少なくする意思決定に本記事が役立てば幸いです！
Discussion