Webアプリのための認証と認可

認証と認可：あなたは誰で、何ができますか？

認証とは、誰が誰であるかを確認することです。通常はユーザー名とパスワード、ソーシャルログイン、または指紋を使用します。認可とは、その人が何を許可されているか、つまりアクセスできるページや実行できるアクションを決定することです。両方ともユーザーがいるアプリケーションには不可欠です。

認証の仕組み

従来のアプローチではセッションを使用します。ログインすると、サーバーはデータベースまたはキャッシュにセッションレコードを作成し、セッションIDを含むCookieをブラウザに送信します。後続のリクエストでは、ブラウザがCookieを送信し、サーバーはセッションを調べてユーザーを特定します。このアプローチはシンプルで安全ですが、サーバー側のストレージが必要です。

より現代的なアプローチでは、JSON Web Token（JWT）を使用します。ログインすると、サーバーはあなたの身元と権限を含む署名付きトークンを作成します。トークンはクライアントに送信され、クライアントはそれを保存し、すべてのリクエストとともに送信します。サーバーはデータベースを参照することなくトークンを検証できます。トークン自体に情報が含まれているからです。これはステートレスでスケーラブルですが、トークンを簡単に取り消すことはできません。

OAuth 2.0とソーシャルログイン

OAuth 2.0は、Google、GitHub、または他のプロバイダーでログインできるようにする標準です。アプリケーションはユーザーをプロバイダーにリダイレクトし、プロバイダーが許可を求めます。ユーザーが許可すると、プロバイダーはコードを返し、アプリケーションがそれをトークンと交換します。これは自分でパスワードを処理するよりも安全で、ユーザーは別のアカウントを作成する必要がないことを評価します。

OpenID ConnectはOAuth 2.0の上にIDレイヤーを追加し、ユーザーのプロフィール情報を取得する標準化された方法を提供します。ほとんどの最新の認証システムは両方を実装しています。

多要素認証

パスワードだけでは不十分です。人々はパスワードを使い回し、フィッシングに引っかかり、弱いパスワードを使用します。多要素認証（MFA）は第二のセキュリティ層を追加します。最も一般的な形式は、認証アプリからの時間ベースのワンタイムパスワード（TOTP）です。より安全なのは、ハードウェアセキュリティキーとパスキーで、フィッシングに強く、推測できません。

認可：アクセス制御

誰であるかがわかったら、その人が何をできるかを決定する必要があります。最も単純なモデルはロールベースのアクセス制御（RBAC）です。ユーザーは管理者、編集者、閲覧者などのロールを持ち、各ロールには特定の権限があります。より柔軟なモデルには、属性ベースのアクセス制御（ABAC）があり、ユーザー、リソース、環境の属性を考慮して決定を行います。

認証プロバイダーの利用

認証をゼロから構築するのは複雑でリスクが伴います。Auth0、Clerk、Supabase Authなどの最新のプロバイダーは、パスワードのハッシュ化、セッション管理、ソーシャルログイン、MFA、セキュリティ監視といった難しい部分を処理します。これらはフロントエンドとバックエンドに統合できるSDKを提供し、セキュリティのベストプラクティスを標準で処理します。ほとんどのプロジェクトでは、プロバイダーを使用するのが適切な選択です。