【ITニュース解説】Supabase Auth Schema Explained: Users, Identities, Sessions

Supabaseを使ってシステムを開発する際、ユーザーが安全にログインできるようにする認証機能は非常に重要だ。Supabaseでは、この認証に関するデータをauthという特別なスキーマに保存している。これは、私たちが普段アプリケーションのデータ（例えば、商品の情報やユーザーのプロフィールなど）を保存するpublicスキーマとは意図的に分けられている。なぜなら、認証情報は非常に機密性が高く、アプリケーションのデータとは異なる管理とセキュリティが求められるためだ。このauthスキーマは、Supabaseの認証サービス（GoTrueと呼ばれる）によって厳重に管理されており、開発者が直接その中のテーブルにデータを書き込むことは原則として推奨されない。読み取ることはできるが、書き込む際はSupabaseが提供する専用のクライアントライブラリや管理APIを使う必要がある。これにより、データの整合性が保たれ、セキュリティリスクを最小限に抑えることができる。

このauthスキーマの中には、主に4つの重要なテーブルがある。これらはauth.users、auth.identities、auth.sessions、そしてauth.refresh_tokensだ。

まず、auth.usersテーブルは、アプリケーションの各ユーザーを表す「中心」となるテーブルだ。アプリケーションに登録したユーザー一人ひとりに対して、このテーブルに1つの行（レコード）が作成される。ここには、ユーザーを一意に識別するためのID（UUIDという形式）、ログインに使われるメールアドレスや電話番号、そしてメールアドレスとパスワードでログインする場合にのみ、安全に暗号化されたパスワードのハッシュ値が保存される。さらに、ログインプロバイダに関する情報や、開発者がユーザーに紐付けて保存したい任意のメタデータ（付随情報）もここに格納できる。このテーブルは、どのユーザーがアプリケーションを利用しているかという基本的な情報を管理する役割を担っている。

次に、auth.identitiesテーブルは、ユーザーがどのような方法でログインしたか、その「身元」に関する情報を保存する。例えば、あるユーザーがメールアドレスとパスワードでログインし、さらにGitHubアカウントでもログインできるように設定した場合、そのユーザーに対してこのauth.identitiesテーブルには2つの行が作成される。一つはメールアドレスによるログイン方法、もう一つはGitHubによるログイン方法の情報を保持する。各行には、どのログインプロバイダ（メール、GitHub、Googleなど）を使ったか、そしてそのプロバイダがユーザーを識別するためのIDや、プロバイダから提供された名前やアバターなどのデータが格納される。このテーブルは、auth.usersテーブルのユーザーIDと関連付けられており、これにより「このユーザーは、これらの方法でログインできる」という関係がわかるようになっている。

3つ目のauth.sessionsテーブルは、ユーザーが実際にログインしている「セッション」に関する情報を持つ。ユーザーがパソコンのブラウザからログインしたり、スマートフォンのアプリからログインしたりすると、それぞれのログインに対して1つのセッションが作成される。このテーブルには、そのセッションがどこから行われたか（IPアドレス、利用しているデバイスやブラウザの種類を示すユーザーエージェント）、そのセッションのセキュリティレベル、そしていつまで有効かといった情報が記録される。多要素認証（TOTPなど）を有効にしている場合は、それに関する情報もここに関連付けられることがある。

そして最後に、auth.refresh_tokensテーブルは、auth.sessionsと密接に関連している。ユーザーがログインすると、アプリケーションは「アクセストークン」という短い有効期限の証明書と、「リフレッシュトークン」という長い有効期限の証明書を受け取る。アクセストークンは、APIへのリクエストを行う際に使われるが、有効期限が短いため、期限が切れると新しいアクセストークンが必要になる。この新しいアクセストークンを発行するために使われるのがリフレッシュトークンだ。auth.refresh_tokensテーブルは、このリフレッシュトークンそのものや、それが取り消されたかどうか、再利用の検出に使う情報などを保存している。一つのセッション（auth.sessionsの行）は、一つのリフレッシュトークンによって裏付けられている関係にある。

これらの4つのテーブルは、互いに密接に連携している。auth.usersテーブルのIDをキーとして、auth.identitiesやauth.sessionsのデータが紐付けられている。また、auth.sessionsのIDをキーとして、auth.refresh_tokensのデータが紐付けられている。このような関係性は、データベースでは「外部キー」という仕組みを使って定義されており、これによってデータの一貫性が保たれている。例えば、「どのユーザーが、どのログイン方法で、現在どのセッションでログインしているか」を知りたい場合は、これらのテーブルを外部キーを使って結合することで、必要な情報を効率的に取得できる。

システム開発者は、これらのauthスキーマ内のテーブルを直接変更するのではなく、Supabaseが提供する認証クライアントライブラリやAdmin APIを使うべきだ。直接データベースに書き込んでしまうと、パスワードが暗号化されなかったり、関連するテーブル間でデータの不整合が生じたりする可能性があるため、絶対に行ってはならない。また、アプリケーション固有のデータが保存されているpublicスキーマのテーブルと、authスキーマのテーブルは、クエリを通じて結合することが可能だ。例えば、ユーザーのプロフィール情報をpublic.profilesテーブルに保存している場合、public.profilesテーブルのuser_idカラムとauth.usersテーブルのidカラムを結合することで、特定のユーザーのプロフィールと認証情報をまとめて参照できる。これは、認証データとアプリケーションデータを関連付けて利用する上で非常に重要なポイントとなる。

注意すべき点として、もしユーザーが存在するのにauth.identitiesの行が全くない場合は、何らかの問題が発生している可能性がある。通常、すべての正規ユーザーは少なくとも1つのログイン方法（identity）を持っているはずだ。また、ユーザーが様々なデバイスやブラウザからログインを繰り返すと、auth.sessionsテーブルには多くのセッション情報が蓄積されるが、これは通常問題ではなく、それぞれのログイン履歴やデバイスを示すものだと理解しておこう。

authスキーマには、これら4つの主要なテーブル以外にも、Supabaseの内部的な管理に使われるauth.instances、auth.audit_log_entries、auth.schema_migrationsといったテーブルが存在するが、これらは開発者が通常関心を持つべきではない。これらは認証サービス自身の管理やログ記録に使われるものであり、開発者がデータを参照したり操作したりすることはない。システムエンジニアを目指す上で、Supabaseの認証機能の仕組みと、authスキーマのこれらの主要なテーブルの役割と関係性を理解することは、安全で堅牢なアプリケーションを構築する上で非常に役立つだろう。