SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。
いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！
この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。

前提

想定しているAPIは、

ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ
GETのAPIにはDBを更新するなどの操作がない

とし、そのためログイン外ではCSRFを考慮しなくてよい、
という前提で話を進めます。

また、XSSに関しては常に対策は必要なのですが（フレームワーク側が自動的にしてくれる部分もある）、認証周りに関係すること以外はあまり記載していません。

Cookieについて

httpOnly属性: trueだと、JSからCookieを参照できなくなる。
secure属性: trueだと、httpsのときしかCookieを送信しない。
sameSite属性: クロスオリジンの際にCookieを送付するかどうかを3段階（strict/lax/none）で調整できる

XSSの際、悪意あるJSにCookieを抜き取られないようにするため、基本的にhttpOnly:trueにする。
また、http通信時にCookieが送信されてしまうと、通信内容を傍受されてしまった際にJWTが流出してしまう。
それを防ぐために基本的にはすべての通信をhttpsにして、secure:trueにする。
sameSite属性は場合による。(参考：https://numb86-tech.hatenablog.com/entry/2020/01/26/112607 )

早見表

方法	おすすめ度	コメント
JWTを用い、localStorageに保存	△〜✖	XSSでJWTが盗まれうる
JWTを用い、localStorageに保存 + refreshトークン	△〜✖	XSSでJWTが盗まれうる。refreshトークンをCookieに保存する方法を他で聞いたことがないので不安。。
JWTを用い、Cookieに保存 + CSRFトークンを利用	○
JWTを用い、Cookieに保存 + CSRF対策にプリフライトリクエストを利用	△	Access-Control-Max-Ageの期間内だとCSRFがおきうる？
JWTを用い、Cookieに保存、JWT送信時はカスタムヘッダに付与して送信	△〜✖	httpOnly:trueを外さざるを得ないのでXSSでJWTが盗まれうる
JWTを用い、SameSiteCookieに保存	○	SPAとAPIが同一オリジンである必要がある
Sessionを用いる + CSRFトークンを利用	○	SPAでないアプリのAJAXでよくあるやつ
Sessionを用いる + CSRF対策にプリフライトリクエストを利用	△	Access-Control-Max-Ageの期間内だとCSRFがおきうる？
Sessionを用い、SessionのCookieはSameSiteCookie	○	SPAとAPIが同一オリジンである必要がある

JWTを用い、localStorageに保存

概要

認証（mail + passwordなど）
↓
JWTが返却される（レスポンスヘッダやレスポンスボディなどで返却。ここではCookieでの返却は考えない。）
↓
JWTをlocalStorageに保存
↓
リクエスト時はJWTを一緒に送信（リクエストヘッダやリクエストボディ）
ログイン有効時間をユーザーが最後に操作してから○○分以内という風にする場合は、リクエストの度にJWTを更新する必要がある。
そうでない場合はログイン時に設定した有効期限が来るとユーザー操作中でも強制ログアウト。

XSSについて

localStorageはOriginごとに独立しているため、別のOriginからJSでJWTを盗まれることはない。
しかしながらXSSが起きると、
同一Originの状況で悪意あるJSによってJWTが漏れてしまう。
たとえばnpmで導入した外部ライブラリの中に、JWTを抜き取るための悪意あるコードがないかどうかすべて確認するのは現実的ではないだろう。XSSは起きうるという前提で考えると、localStorageにJWTを保存するのは基本的にはよくない。
【参考】https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851

CSRFについて

「不正なサイトから当該サイトにリクエストを投げたときに自動でcookieが付与される」という典型的なパターンの事象が起きないので考慮不要。

総括

JWTをlocalStorageに保存するだけの方法では、XSSによりJWTが抜き取られ、第三者によるリクエストが可能になる。特にJWTの有効期限が長い場合、被害が大きくなりうる。

有効期限が長く、リクエストの度にJWTを更新する場合

おすすめ度：✖
XSSでJWT流出の危険性

有効期限が長く、一度JWTを発行したらそのJWTを使い続ける場合（操作中でも有効期限がきたらログアウトさせる）

おすすめ度：✖
XSSでJWT流出の危険性

有効期限が十分に短い

おすすめ度：△
XSSでJWTが流出した場合の危険性をある程度抑えれれている。

JWTを用い、localStorageに保存 + refreshトークン

概要

例えば、JWTの有効期限を30分に設定するものの、refreshトークンの有効期限は1ヶ月、のような設定にする。
JWTの有効期限が切れてもrefreshトークンの有効期限内であれば自動的にrefresh、またrefreshする際にrefreshトークンの有効期限をその時点から1ヶ月になるように更新することで、1ヶ月に1度以上の頻度でユーザーが操作する限り、UX的には常にログインしているような状態を実現する。
refreshトークンがあるので、リクエストの度にJWTを更新することは考えない。
こうすれば、もしJWTが抜き取れれた場合もrefreshトークンが抜き取られなければ30分でJWTが使えなくなりある程度の安全性を確保できる。

認証（mail + passwordなど）
↓
JWT（レスポンスヘッダやレスポンスボディなどで返却。ここではCookieでの返却は考えない。）
と
refreshトークン（Set-Cookie, httpOnly:true, secure:true）
を返却
↓
JWTをlocalStorageに保存
↓
リクエスト時は
JWT（リクエストヘッダやリクエストボディ）
と
refreshトークン（リクエストヘッダに自動的にCookieが付与される）
を一緒に送信
JWTの有効期限が切れていたらJWTとrefreshトークンで両者をrefresh

XSSについて

XSSによりJWTが抜き取られうる。refreshトークンはCookie(httpOnly: true)なので抜き取られない。

CSRFについて

JWTがCookieでないので基本的には考慮不要。

refreshトークンがCookieに存在するため、JWTが抜き取られた状態だとCSRFによって一応refreshすることができてしまう。
しかしながらCSRFでrefreshしてもCORS制限によりブラウザはレスポンスを読み取れず有効なJWTを利用することができないため問題ないと考えられる。

refreshトークンについて

JWTにはユーザー情報と、refreshトークンを第三者が復号できない方式で暗号化したもの、が含まれている。JWTの中身自体は第三者でも復号して確認できるので、refreshトークンの情報は、第三者が復号できない方法で暗号化したものを入れる必要があると考えた。
refresh時はサーバーサイドではJWTを検証してユーザー情報と暗号化されたrefreshトークンを取得し、
暗号化されたrefreshトークンを復号して（←サーバーでだけ復号できる）refreshトークンと一致しているかどうかを確認する。
確認が取れれば、JWTとrefreshトークンをrefreshする。

総括

JWTをlocalStorageに保存する方法では、XSSによりJWTが抜き取られ、第三者によるリクエストが可能になる。特にJWTの有効期限が長い場合、被害が大きくなりうる。
また、refreshトークンがcookieに存在するのでリクエストのたびに毎回送信されているのがすこし怖い気がする。
(2020.04.26 追記)↑に対して

cookie の path 属性を使って refresh 時にのみ送信する

という方法をコメントにて教えていただきました！ご指摘ありがとうございます！

JWTの有効期限が長い場合

おすすめ度：✖
XSSでJWT流出の危険性

JWTの有効期限が十分に短い

おすすめ度：△
XSSでJWTが流出した場合の危険性をある程度抑えれれている。
ただ、refreshトークンをCookieに保存する方法を他で聞いたことがない。この方法の危険性などありましたら是非指摘をお願いいたします！

JWTを用い、Cookieに保存 + CSRFトークンを利用

概要

認証（mail + passwordなど）
↓
JWT（Set-Cookie, httpOnly:true, secure:true）
と
CSRFトークン（レスポンスヘッダやレスポンスボディなどで返却。Set-Cookieでの返却だとCSRF対策にならない。）
を返却
↓
リクエスト時は、
JWT（リクエストヘッダに自動的にCookieが付与される）
と
CSRFトークン（リクエストヘッダやリクエストボディ）←POST/PUT/DELETEの場合に限定しても良いかもしれない
を送信
また、リロードした際にCSRFトークンが消えるのでJWTの有効期限が切れていない場合に再取得できる仕組みが必要。
さらに、ログイン有効時間をユーザーが最後に操作してから○○分以内という風にするにはリクエストの度にJWTを更新しなければならない。
そうでない場合はログイン時に設定した有効期限が来るとユーザー操作中でも強制ログアウト。

XSSについて

XSSが起きた場合でもhttpOnly:trueによりJWTが流出しない。
また、CSRFトークンもJSのグローバルから参照できない変数に保持していれば流出しない。

CSRFについて

悪意のあるサイトから当該サイトにリクエストを投げたとき、JWTはCookieとして自動で送信されるが、CSRFトークンは送信できず、サーバーサイド側で不正なリクエストと判断することができる。

※もしCSRF対策しなかった場合も、CORSの制約によりブラウザがレスポンスを読み取らせてくれず、ブラウザ側ではきちんとエラーがでる。ではなぜ対策が必要なのかと言うと、「レスポンスが読み取れないものの、サーバーサイドとしてはリクエストが正常に完了している」と言う点が問題だからである。
例えば、DBのレコード追加をするための通信の場合、レスポンスは読み取れないもののレコードの追加は完了してしまっている。

上記で記載した「POST/PUT/DELETEに限定する」というのは、リソースの更新を伴う機能にはGETを用いないという前提のもと、CSRFでアクセスされたとしてもリソースの更新はなく、CORS制約によりレスポンスが読み取られないため実害があまりないということによるものである。

※リロード時にCSRFトークン再取得をする機能があるので、悪意のあるサイトからCSRF的にCSRFトークン再取得を行ったとしてもレスポンスを読み取れないため問題なし。

CSRFトークンについて

このJWTにはユーザー情報と、CSRFトークンを第三者が復号できない方式で暗号化したもの、が含まれている。（JWTの中身自体は第三者でも復号して確認できるので、CSRFトークンの情報はさらに別の、復号できない方法で暗号化したものを入れる必要があると考えた）
サーバーサイドではJWTを検証してユーザー情報と暗号化されたCSRFトークンを取得し、
暗号化されたCSRFトークンを復号して（←サーバーでだけ復号できる）CSRFトークンと一致しているかどうかを確認する

総括

JWTをlocalStorageでなくCookieに保存するためXSSでJWTを奪われない。一方でCookieであるがゆえにCSRF対策が必要であり、CSRFトークンを用いている。

リクエストの度にJWTを更新する（ログイン有効時間をユーザーが最後に操作してから○○分以内とする）場合

おすすめ度：○

一度JWTを発行したらそのJWTを使い続ける場合（操作中でも有効期限がきたらログアウトさせる）場合

おすすめ度：○

類似実装

CSRFトークンをlocalStorageに保存する方法が下記で紹介されていた。
https://fujiten3.hatenablog.com/entry/2019/07/13/130459

こちらだとサーバーサイドでのトークンの管理をgemに一任し、フロント側ではCSRFトークンをlocalStorageで管理しているようだ。
こうなるとCSRFトークンがXSSで盗まれうるのだが、JWTの有効期限が短ければ頻繁にCSRFトークンがアップデートされるので危険性が低いと言えるかもしれない。また、Redisなども必要になるようだ。

JWTを用い、Cookieに保存 + CSRF対策にプリフライトリクエストを利用

概要

認証（mail + passwordなど）
↓
JWT（Set-Cookie, httpOnly:true, secure:true）を返却
↓
リクエスト時は、JWT（リクエストヘッダに自動的にCookieが付与される）とカスタムヘッダを送信

XSSについて

XSSが起きた場合でもhttpOnly:trueによりJWTが流出しない。

CSRFについて

Cookieを用いているため、CSRF対策が必要。
そこで、CORSによるプリフライトリクエストを利用してCSRFを防ぐ

プリフライトリクエストが起きるようにするための方法はいくつかあるが、カスタムヘッダを用いる方法がある。カスタムヘッダがあると、必ずプリフライトリクエストが起きる。サーバー側でどのOriginからのリクエストを許容するかをきちんと設定していれば、プリフライトリクエストで不正なリクエストが弾かれることになる。

また、カスタムヘッダがなければプリフライトリクエストが起こらないことがあるが、カスタムヘッダがないものはサーバー側で不正なリクエストとして扱えば良い。
参考：https://qiita.com/uryyyyyyy/items/9a8276f7241b650f1c15#%E3%83%96%E3%83%A9%E3%82%A6%E3%82%B6%E3%81%AEpre-flight%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B

総括

JWTだとCSRF対策が不要なイメージがあるが、Cookieを使っているせいでこの方式では対策が必要である。
そこでプリフライトリクエストを用いて対策している。

リクエストの度にJWTを更新する（ログイン有効期限をユーザーが最後に操作してから○○分以内とする）場合

おすすめ度：△
Access-Control-Max-Ageの期間内だとCSRFがおきうる？

一度JWTを発行したらそのJWTを使い続ける場合（操作中でも有効期限がきたらログアウトさせる）場合

おすすめ度：△
Access-Control-Max-Ageの期間内だとCSRFがおきうる？

JWTを用い、Cookieに保存、　JWT送信時はカスタムヘッダに付与して送信

概要

認証（mail + passwordなど）
↓
JWT（Set-Cookie, httpOnly: false, secure:true）を返却
↓
リクエスト時は、JWT（リクエストヘッダのカスタムヘッダ）を送信
JWTはCookieで保存するものの手動でカスタムヘッダにセットリクエストを送信し、サーバーサイドではカスタムヘッダの方のJWTを検証することとする。

XSSについて

Cookieに保存しているJWTをJSで取得してカスタムヘッダに付け替える操作が必要であるため、httpOnly:trueを設定できない。
そのため、XSSでJWTが流出しうる。

CSRFについて

CookieのJWTを検証するわけではないのでCSRFは考慮しなくてよい。

総括

結局XSSでJWTが流出するのでlocalStorageに保存している場合と同じである。
有効期限を短くして、refreshトークンをhttpOnly:trueのCookieに設定するのであれば有用と思われる。

おすすめ度：△〜✖
理由に関しては、JWTをlocalStorageに入れるケースの説明を参照

JWTを用い、SameSiteCookieに保存

概要

SPAとAPIを同一Originにできる場合限定

認証（mail + passwordなど）
↓
JWT（Set-Cookie, httpOnly:true, secure:true, SameSite: Strict）を返却
↓
リクエスト時は、JWT（リクエストヘッダに自動的にCookieが付与される）を送信

XSSについて

XSSが起きた場合でもhttpOnly:trueによりJWTが流出しない。

CSRFについて

SameSiteCookieを用いているため、クロスオリジンだとCookieが送信されずCSRF対策は不要。

総括

すごくシンプルな実装でSPAとAPIが同一ドメインの場合はこれだけでいいかと思いました。
おすすめ度：○

Sessionを用いる + CSRFトークンを利用

概要

認証（mail + passwordなど）
↓
SessionのCookie（Set-Cookie, httpOnly:true, secure:true）
と
CSRFトークン（レスポンスヘッダやレスポンスボディなどで返却。Set-Cookieでの返却だとCSRF対策にならない。）
を返却
↓
リクエスト時は、
SessionのCookie（リクエストヘッダに自動的にCookieが付与される）
と
CSRFトークン（リクエストヘッダやリクエストボディ）←POST/PUT/DELETEの場合に限定しても良いかもしれない
を送信
また、リロードした際にCSRFトークンが消えるのでJWTの有効期限が切れていない場合に再取得できる仕組みが必要。

XSSについて

XSSが起きた場合でもhttpOnly:trueによりCookieが流出しない。
また、CSRFトークンもJSのグローバルから参照できない変数に保持していれば流出しない。

CSRFについて

悪意のあるサイトから当該サイトにリクエストを投げたとき、Cookieは自動で送信されるが、CSRFトークンは送信できず、サーバーサイド側で不正なリクエストと判断することができる。

※リロード時にCSRFトークン再取得をする機能が必要であるが、悪意のあるサイトからCSRF的にCSRFトークン再取得を行ったとしてもレスポンスを読み取れないため問題なし。

総括

SPAでないアプリケーションでAJAXするときのよくあるパターンのように、セッションを用いつつ、CSRFトークンで対策する
おすすめ度：○

Sessionを用いる + CSRF対策にプリフライトリクエストを利用

概要

認証（mail + passwordなど）
↓
SessionのCookie（Set-Cookie, httpOnly:true, secure:true）を返却
↓
リクエスト時は、
SessionのCookie（リクエストヘッダに自動的にCookieが付与される）とカスタムヘッダを送信

XSSについて

XSSが起きた場合でもhttpOnly:trueによりCookieが流出しない。

CSRFについて

プリフライトリクエストで対策する。
カスタムヘッダがあると、必ずプリフライトリクエストが起きる。サーバー側でどのOriginからのリクエストを許容するかをきちんと設定していれば、プリフライトリクエストで不正なリクエストが弾かれることになる。

また、カスタムヘッダがなければプリフライトリクエストが起こらないことがあるが、カスタムヘッダがないものはサーバー側で不正なリクエストとして扱えば良い。

総括

おすすめ度：△
Access-Control-Max-Ageの期間内だとCSRFがおきうる？

Sessionを用い、SessionのCookieはSameSiteCookie

概要

JWT in SameSiteCookieのSessionバージョン。
SPAとAPIを同一Originにできる場合限定

認証（mail + passwordなど）
↓
SessionのCookie（Set-Cookie, httpOnly:true, secure:true, SameSite: Strict）を返却
↓
リクエスト時は、SessionのCookie（リクエストヘッダに自動的にCookieが付与される）を送信

CSRFについて

SameSiteCookieを用いているため、クロスオリジンだとCookieが送信されずCSRF対策は不要。

XSSについて

XSSが起きた場合でもhttpOnly:trueによりCookieが流出しない。

総括

JWTのときと同様、すごくシンプルな実装でSPAとAPIが同一ドメインの場合はこれだけでいいかと思いました。
おすすめ度：○

今後の課題（自分用メモを兼ねる）

IDaas(Cognitoなど)が使いやすそうか今後検証（参考：https://tech.hicustomer.jp/posts/modern-authentication-in-hosting-spa/ )
Contents Security Policyについて調べる
Fetch Metadata Request Headersについて調べる
DNS Rebindingをされても大丈夫かどうか、それぞれの方法で考える（参考：https://blog.tokumaru.org/2007/11/dns-rebinding.html ）
リクエストメソッドの「Trace」メソッドによる脆弱性を検証
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/704.html を理解し対策を考える
セキュリティ関係諸々調べる

まとめ

認可のための情報はJSでアクセスできるところにおいてはいけない

JWTをWebStorageやhttpOnly:falseのCookieに置かない。SessionのCookieにはhttpOnlyをつける。

CSRF対策は、CSRFトークンを用いる or プリフライトリクエストを用いる or SameSiteCookie

CSRF対策で、本来改ざんできないはずのOriginを確認する方法があるようだが、場合によっては改ざん可能らしいので完璧ではないかもしれない。（参考：https://insert-script.blogspot.com/2018/05/adobe-reader-pdf-client-side-request.html ）
また、プリフライトリクエストを用いる方法に疑問視の声もある（参考：http://blog.a-way-out.net/blog/2015/03/23/stateless-csrf-protection/ ）。
(2020.4.27追記)
プリフライトリクエストに関しては、Access-Control-Max-Ageの期限内だとCSRFが起きうる気がしてきました！

最後に Access-Control-Max-Age は、プリフライトリクエストを再び送らなくてもいいように、プリフライトのレスポンスをキャッシュしてよい時間を秒数で与えます。この例では86400秒、つまり24時間です。なお、ブラウザーは個々に内部の上限値を持っており、 Access-Control-Max-Age が上回った場合に制限を掛けます。

↑引用元（https://developer.mozilla.org/ja/docs/Web/HTTP/CORS）

SameSiteCookieについては実装例があまり多くなさそうな気がするが妥当性はどうだろうか。

前提

Cookieについて

早見表

JWTを用い、localStorageに保存

概要

XSSについて

CSRFについて

総括

有効期限が長く、リクエストの度にJWTを更新する場合

有効期限が長く、一度JWTを発行したらそのJWTを使い続ける場合（操作中でも有効期限がきたらログアウトさせる）

有効期限が十分に短い

JWTを用い、localStorageに保存 + refreshトークン

概要

XSSについて

CSRFについて

refreshトークンについて

総括

JWTの有効期限が長い場合

JWTの有効期限が十分に短い

JWTを用い、Cookieに保存 + CSRFトークンを利用

概要

XSSについて

CSRFについて

CSRFトークンについて

総括

リクエストの度にJWTを更新する（ログイン有効時間をユーザーが最後に操作してから○○分以内とする）場合

一度JWTを発行したらそのJWTを使い続ける場合（操作中でも有効期限がきたらログアウトさせる）場合

類似実装

JWTを用い、Cookieに保存 + CSRF対策にプリフライトリクエストを利用

概要

XSSについて

CSRFについて

総括

リクエストの度にJWTを更新する（ログイン有効期限をユーザーが最後に操作してから○○分以内とする）場合

一度JWTを発行したらそのJWTを使い続ける場合（操作中でも有効期限がきたらログアウトさせる）場合

JWTを用い、Cookieに保存、 JWT送信時はカスタムヘッダに付与して送信

概要

XSSについて

CSRFについて

総括

JWTを用い、SameSiteCookieに保存

概要

XSSについて

CSRFについて

総括

Sessionを用いる + CSRFトークンを利用

概要

XSSについて

CSRFについて

総括

Sessionを用いる + CSRF対策にプリフライトリクエストを利用

概要

XSSについて

CSRFについて

総括

Sessionを用い、SessionのCookieはSameSiteCookie

概要

CSRFについて

XSSについて

総括

今後の課題（自分用メモを兼ねる）

まとめ

認可のための情報はJSでアクセスできるところにおいてはいけない

CSRF対策は、CSRFトークンを用いる or プリフライトリクエストを用いる or SameSiteCookie

JWTを用い、Cookieに保存、　JWT送信時はカスタムヘッダに付与して送信