Auth0再考、SPA & API構成のアプリケーションにおける認証について考える

Auth0最高って話じゃないです。

そもそもSPAとAPIの構成をもったアプリケーションでの認証とはどうあるべきなのか、どういうデザインパターンが存在するのかを全く知らずに作っちゃったのは良くないなと思った。

ということで何でもかんでもすぐ書いてみるのではなく、一旦手を止めて色々勉強してみたのでメモしておきたい。

何にもやもやしていたのか

前回の記事の内容でも動くには動いたんだけど、どうしてもそれが最適とは思えず、IDaaSを使うことによる恩恵がほぼないのでは、という印象があった。

例えばこういうこと。

• サーバサイドからAuth0のAPIを叩いてsignup/signinの管理をする方式が正しいのか
• クライアントでログイン状態を維持するために何の情報をどこに持てばいいのか

Auth0が提唱するSPA、API構成の認証方式

Auth0のドキュメント、部分的にしか読んでなくていまさらこのドキュメントの存在に気づいた。

• SPA + API

ExampleCoという100人程度の社員を持つコンサル企業がタイムシート管理アプリをSPA、API構成で作る上でどうしていくか、というシナリオでドキュメントが構成されている。

Auth0におけるAPIとApplication

Auth0にはApplicationという概念とAPIという概念がある。

APIには独自にPermissionを定義することができて、このドキュメントではタイムシート管理用の read:timesheets 、 create:timesheets などのPermissionを定義している。

Applicationはサインアップ、サインインの機能、UIを提供するためのもので、 Regular web app 、 SPA 、 Native App など利用元のプラットフォームを指定して使うことができる。

• Applications in Auth0

Applications Use this page to manage your applications. For every app of yours that you want to use Auth0, you should register an application here.

API上の実装

以下ドキュメントにSPA & API構成でのNode.jsでの参照実装がある。

• SPA + API: Node.js Implementation for the API

ユーザ情報の取得に関してはJWTをvalidateして取得している。

• Determine the User Identity

Tokenの有効期限

SPAの場合TokenがExpireした場合、サーバ上に送ってJWTのValidationが失敗して初めて発覚するので少し問題になり得る。

• Configure Silent Authentication

この問題は auth0.js の機能によって解決できる模様。

You can make a silent authentication request to get new tokens as long as the user still has a valid session at Auth0. The checkSession method from auth0.js uses a silent token request in combination with response_mode=web_message for SPAs so that the request happens in a hidden iframe.

不可視のiframeを配置してその中で checkSession() の実行 & 再発行をしてくれるのかな？

終わりに

認証周りは本当に難しくて魔窟感ある。

IDaaSは便利なんだろうけど、楽できるとか何も考えずに認証機構を作れるという意味では少し違うのかもしれないと思った。

もう少しドキュメントを読んだりExampleを見たりして、再度手を動かして納得のいく実装になるまで挑戦してみようかと思う。

参考にさせていただきました

• JWTを使った今どきのSPAの認証について

ものすごく丁寧かつ包括的にまとめられていて感動しました。この方くらい深く広い洞察力を持ちたい😵