認証について
- OAuth
- ユーザーのパスワードを直接共有することなく、他のアプリケーションやサービスにユーザーの情報へのアクセスを許可するための認証プロトコル
- アクセストークンという一時的なキーが発行
- 例えば、あなたがTwitterのアカウントを使って別のWebサイトにログインするとき、OAuthを利用して、TwitterがそのWebサイトに対してあなたのアカウント情報への一部のアクセスを許可します。このとき、Webサイトにはあなたのパスワードが知らされることはなく、Twitterが認証を代行します
- Cookie-Based認証
- Cookie-based認証の流れ
- ログイン:ユーザーがログインフォームにユーザー名とパスワードを入力し、サーバーに送信します。
サーバーは認証情報を確認し、正しければユーザーを認証します。 - Cookieの発行:認証が成功すると、サーバーは認証トークン(通常はセッションID)を作成し、それをクッキーとしてユーザーのブラウザに送信します。
このクッキーは、ユーザーのブラウザに保存され、次回以降のリクエストに自動的に含まれます。 - リクエストの認証:ユーザーが別のページをリクエストすると、ブラウザは保存されたクッキーをサーバーに送信します。サーバーはクッキーに含まれる認証トークンを確認し、有効であればユーザーを認証済みとしてリクエストを処理します。
- ログアウト:ユーザーがログアウトすると、サーバーはセッションを無効にし、クッキーを削除するか、無効化する指示をブラウザに送信します。
- ログイン:ユーザーがログインフォームにユーザー名とパスワードを入力し、サーバーに送信します。
- Cookie-based認証の流れ
- Token Authentication
- トークンの発行: ユーザーが最初にログインするとき、サーバーはユーザーの認証情報(通常はユーザー名とパスワード)を確認し、認証が成功すると、トークンが発行されます。このトークンは、認証が成功したことを証明するデジタルキーのようなもの
- トークンの利用: 認証が必要なリクエストを送る際、ユーザーはこのトークンを一緒に送ります。サーバーはそのトークンを確認し、正当であればアクセスを許可します。これにより、再度パスワードを入力する必要がなくなります
- トークンの特徴:
一時的: トークンには有効期限があり、期限が切れると再度ログインが必要になります。
セキュア: パスワードが漏れるリスクを軽減します。トークン自体が漏れても、期限が切れたり無効化されたりするので、被害を最小限に抑えることができます。
-トークン認証は、特にWebアプリケーションやモバイルアプリケーションで、セッション管理やセキュリティの向上のためによく使われます。
- Basic Authentication
- 最もノーマルな認証方法。ユーザー名とパスワードで認証する。
- 送信前にパスワードをエンコード, サーバーはパスワードをデコードする
- セキュリティが貧弱
- 平文に近い形でネットワークに流れるのでとても危険
- HTTPSでのパスワード暗号化が主流
Cookie-Based認証とToken Authenticationって似てね?
状態の管理: Cookie-based認証はサーバーでセッション状態を管理するのに対し、Token Authenticationはクライアント側でトークンを管理し、サーバーはステートレスです。
使われるシーン: Cookie-based認証はWebアプリケーションで、Token AuthenticationはAPIベースのサービスやモバイルアプリケーションでよく使用されます。
セキュリティ: Token Authenticationは、XSS(クロスサイトスクリプティング)などの攻撃に対して脆弱性が少なくなる一方、トークンが漏洩するとリスクがあります。Cookie-based認証もクッキーの盗難(クロスサイトリクエストフォージェリ (CSRF) やクッキー盗難)に対して対策が必要です。
※例えばRestAPIはステートレス(個々のリクエストに依存関係を持たせないため。リクエスト1つですべて完結)