【Flutter】Serverpodの認証の仕組みとセキュリティ向上のヒント

はじめに 

株式会社メンバーズCross Applicationカンパニーの柴田です。

本記事ではDartでAPIサーバを実装できるServerpodというフレームワークの認証処理の仕組みについて解説します。Google認証・パスワード認証等、認証の種類によらないServerpodのAPI認証部分に関するものになります。

フレームワークの使い方はメインテーマではないので本記事では詳しく扱いません。Serverpodの公式ドキュメントをご確認ください。公式ドキュメントには書かれていないFirebase AuthenticationでGoogle認証を行う方法については、こちらの記事で紹介していますので興味のある方はぜひご覧ください。

全体像

ログイン・認証後のAPIリクエストは、以下のシーケンス図のような動きになります。
一つずつ解説していきます。

ログイン

① Flutterアプリ側で、メールアドレス・パスワード/Google Apple等のソーシャルログイン等で認証処理を開始する

② サーバ側で、認証情報が正しければランダム文字列の「key」を生成し、その他の情報とともにserverpod_auth_keyテーブルにレコードを追加。
以下の様なデータが保存される。
userIdはserverpod_user_infoテーブルのid、hashは「<salt><key>」をUTF8でエンコードしてSHA256でハッシュ化したものを表す。

コードだとこの辺り。

③ レスポンスとしてFlutterアプリへidとkeyを返却

認証後のAPIリクエスト

① Flutterアプリ側から、APIリクエストごとにidとkeyを送信。
使用するプロトコルによって送信方法が異なる。

a) HTTP通信
Authorizationヘッダを通して送信
「Authorization: "XXX"」
XXXの部分は「<id>:<key>」をbase64エンコードしたもの

b) WebSocket通信
クエリパラメータとして送信
「ws://localhost:8080/websocket?auth=XXX」
XXXの部分は「<id>:<key>」をURLエンコードしたもの

② XXXをデコードしてidとkey取り出し、にserverpod_auth_keyテーブルからidに紐づくレコードを取得する
③ 「<salt><key>」をUTF8でエンコードしてSHA256でハッシュ化したものと②で取得したhashが一致するか比較する。一致すれば認証成功。
④ APIの処理を実行しレスポンスを返す

推奨事項

• Saltを設定する

  Saltを設定しておくとDBのデータが流出した場合でも、平文の認証情報の推定が困難になりセキュリティが高まるためです。ServerpodではデフォルトでONになっています。詳しくは ソルト (暗号) 等をご確認ください。

• Saltの値を変える

  レインボーテーブルによる攻撃を低減するために初期値から変更することを推奨します。Saltは [PROJECTNAME]_server/config/password.yamlのauthKeySaltにて変更可能です。
  CI/CDに組み込むときは、yq等を使ってYAMLにSaltを注入する形になります。Git管理はセキュリティ上しないようにしましょう。
  一般にSaltはパスワード毎に都度生成するプラクティスがありますが、ServerpodのAuthKeyに関してはパスワードがランダムな文字列のため不要になります。

懸念事項

• AuthKeyの有効期限がない

  必要であれば、FutureCallを使って初回認証時に指定時間後にレコードを消す処理を独自実装することが必要そうです。その場合はフロント側も、認証エラー時に再認証する等のエラーハンドリングが必要になります。
  特にWebSocket通信においては、クエリパラメータで認証情報を送っているので有効期限が設定されていないということは一定のリスクがあります。

補足

今後Serverpodの認証機能に変更が入りこの記事の方法は推奨されない、または、実行できなくなる可能性があります。2025年2月時点では、破壊的変更は加えず徐々に新しい書き方に移行を促すロードマップになっているようです。最新情報はこちらをご確認ください。

まとめ

本記事ではServerpodの認証処理のコードリーディングを行いわかったこと、考察したことを解説してきました。Serverpodでのアプリ開発において本記事の認証処理解説が参考になれば幸いです。