【図解で解説】トークン ベースの認証について

トークンベースの認証とは

ユーザーがユーザー名やパスワードなどで自分が誰であるかの確認を行い、その見返りとしてアクセストークンを受け取ることができます。
ユーザーはトークンの有効期間中であればそのWebサービスのリソースにアクセスすることができます。

参考：トークンベースの認証とは何ですか?

認証の流れ

① まず、ユーザー名とパスワードによってログイン処理行います。

② 次に、サーバー側で入力されたユーザー名とパスワードでどのユーザーであるか特定をし、そのユーザーにリソースにアクセスする権限があるか確認します。

③ もしアクセスする権限があるのであればアクセストークンを発行します。

④ そのアクセストークンはクライアント側に返されるので、そのアクセストークンをCookieなどに保存しておきます。

⑤ クライアント側でサーバー側にリソースの取得などのリクエストを行う場合は、アクセストークンをリクエストに含めておきます。

⑥ アクセストークンを検証し、改竄がされておらず有効期限などに問題がないことを確認したら、リソースをクライアント側に返します。

参考：Why is JWT popular?

メリット

① トークンのサイズが小さいのであれば、クライアントとサーバー間で非常に迅速にトークンを渡すことができます。

② ユーザーがアクセスできるリソース、その権限の有効期間、ログオン中にユーザーが実行できる操作を指定できます。

③ セッションベースの認証ではセッションIDをサーバー側のデータベースなどで保存しておく必要があったが、トークンベースの認証であればサーバー側でトークンの情報を保存しておく必要はない。

デメリット

① サイズが大きいトークンをクライアントとサーバー間で送受信すると、パフォーマンスの影響を与える可能性があります。

② 一度発行したトークンは、サーバーで無効化する方法が基本的にはありません。
例えば、ユーザーがログアウトしたり、権限を変更した場合でも、有効期限内のトークンは有効です。
この回避策としては、トークンに短い有効期限を設定し、定期的に新しいトークンを発行します。

③ トークンが盗まれた場合、そのトークンを持つ者は有効期限が切れるまで正規ユーザーとして振る舞うことができます。
この回避策としては、HTTPSを使用して通信を暗号化し、トークンの情報が読み取れないようにしておくことです。

④ クライアント側に保存したトークンがXSS攻撃によって盗まれる可能性があります。
その回避策としては、トークンをCookieのHttpOnly属性と共に保存することで、JavaScriptからトークンの情報にアクセスできないようにしておくことです。

⑤ 短い有効期限のアクセストークンと、長期有効なリフレッシュトークンの組み合わせを採用すると、実装が煩雑になります。
不正を防ぐため、リフレッシュトークンをセキュアに保存・管理する必要があります。