アクセストークンに対する、ID/Passwordを毎回含めたリクエストのデメリットについて

Question

認証が必要なAPIサーバを開発する際の主流は以下の流れだと思います。

1. クライアントからID/Passwordを含めたログインリクエストを送る
2. サーバ側でID/Passwordを検査して、正しければアクセストークンを発行、返却する
3. クライアント側でアクセストークンをlocalStorage等に保存して、認証が必要なリクエスト時に付与する

このとき、アクセストークンの代わりにID/PasswordをlocalStorageに保存して、
毎回リクエストに含めてサーバ側で毎回認証させる場合のデメリットはどのようなことが考えられるでしょうか。

自分なりに考えた点は以下の通りですが、ご指摘いただけると幸いです。

・外部に認証APIを公開するためにトークン化が必要

・毎回、認証処理が必要となりアクセストークンの妥当性確認よりもコストが重くなる

・通信時にID/Passwordが漏洩するリスクが高くなる
(ログイン時には漏洩するリスクがあり、そこまで意味はない気がします)

・localStorageからID/Passwordが漏洩する
(アクセストークンが漏洩した場合も問題ですが、ブラックリスト等により対策が容易?)

よろしくお願いいたします。

Answer 1

名前のIDとパスワードをクライアント側で保存する方式は、率直に言ってデメリットのみ目立ち、メリットがない気がします。

・通信時にID/Passwordが漏洩するリスクが高くなる

(ログイン時には漏洩するリスクがあり、そこまで意味はない気がします)

これは、HTTPSを前提とすると、その通りですね。
ログインの際のみHTTPSとして、その後はHTTPで運用する昔ながらの方法はとれなくなりますが、今どきそんな方法は使わない、ということでよいですか?

・localStorageからID/Passwordが漏洩する

(アクセストークンが漏洩した場合も問題ですが、ブラックリスト等により対策が容易?)

これは重大な問題です。localStorageにパスワードを保存すると、クロスサイト・スクリプティングにより簡単に漏洩してしまいます。クロスサイト・スクリプティングがあると成りすましはできるわけですが、その場合でもパスワードまでは漏洩しないので、通常はパスワードを必要とする処理（決済の前とか、パスワード変更とか…）は悪用できません。これに対して、パスワードが漏洩したら、それこそ「何でもあり」になってしまいます。
また、気にするかどうかは意見の分かれるところでしょうが、その方のブラウザを操作しただけでパスワードがばれてしまうことも問題です。

これらのデメリットを上回るメリットもなさそうですので、生のパスワードをブラウザのストレージに保存する方式は避けるべきかと思います。