認証・認可とセキュリティ基礎

Webサービスの開発において、機能やパフォーマンスと同じくらい重要なのがセキュリティです。特にバックエンドエンジニアは、外部との通信やデータ保護、アクセス制御といった領域で、セキュアな設計・実装を行う責任があります。

この記事では、認証・認可の基本的な違いから、CookieやJWTを用いた認証、OAuth2.0の仕組み、そしてOWASP Top10に代表されるWeb脆弱性への対策まで、セキュアなWebシステムを作るための最低限の知識を体系的に解説します。

1. 認証（Authentication）と認可（Authorization）の違い

セキュリティにおける基礎概念として、まずは「認証」と「認可」の違いを正しく理解することが重要です。

項目	説明	例
認証（Authentication）	ユーザーが「誰か」を確認する	ログイン処理、パスワード確認、2段階認証
認可（Authorization）	ユーザーが「何ができるか」を決める	管理者だけが記事を削除可能などのアクセス制御

この2つは混同されがちですが、認証が済んでも認可されていなければ操作はできないという点を理解しておきましょう。

2. Cookieとセッション管理の基本

2.1 セッション管理の流れ

Webは本質的にステートレス（状態を持たない）なプロトコルですが、ユーザーのログイン状態を維持するためにセッション管理が導入されます。

ユーザーがログインすると、サーバー側でセッションIDを発行
セッションIDをCookieに保存してクライアントに返す
以降のリクエストでCookie内のセッションIDを使ってユーザーを特定

この方式は「サーバーセッション管理」と呼ばれ、ユーザー情報をサーバー側に保持するため安全性が高いですが、スケーリング時のセッション共有に工夫が必要です。

2.2 Cookieのセキュリティ設定

Cookieを使ったセッション管理では、以下のセキュリティ対策が重要です：

HttpOnly：JavaScriptからアクセスできないようにする
Secure：HTTPS通信でのみCookieを送信
SameSite：クロスサイトからの送信制御（CSRF対策）

Set-Cookie: sessionid=xyz123; HttpOnly; Secure; SameSite=Strict

3. JWT認証とOAuth2.0の基本

3.1 JWT（JSON Web Token）とは？

JWTは、JSON形式のトークンに署名を加え、サーバーレスでユーザー認証を行う手法です。

ログイン時に署名付きトークンを発行
その後はリクエストヘッダーにトークンを付与
サーバーはトークンを検証して認証状態を判定

JWTの構造

[Header].[Payload].[Signature]

Base64でエンコードされているため見える化できるが、署名により改ざん検知が可能です。

例（Authorizationヘッダーで送信）：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6...

メリットと注意点

メリット：スケーラビリティが高い（サーバーで状態保持不要）
注意点：トークンが盗まれたら不正アクセスされるため有効期限や署名管理が重要

3.2 OAuth2.0とは？

OAuth2.0は、ユーザーが第三者アプリに対して限定的なアクセス権を許可するための認可フレームワークです。

代表例：Googleアカウントでログイン、GitHubと連携して外部サービスへ情報提供

主な登場人物

リソースオーナー：ユーザー本人
クライアント：アクセスを希望するアプリ
認可サーバー：ユーザーの同意を管理
リソースサーバー：実際のデータ提供元

OAuthのフロー（Authorization Code Grant）

クライアントが認可サーバーにリダイレクト
ユーザーがログイン・同意
認可コードをクライアントに返す
認可コードを使ってアクセストークンを取得
トークンを使ってリソースサーバーからデータ取得

アクセストークンには有効期限とスコープ（アクセス範囲）があり、安全性と柔軟性のバランスをとっています。

4. OWASP Top10とWebセキュリティ対策

OWASP（Open Web Application Security Project）は、Webアプリケーションのセキュリティに関する国際的な非営利プロジェクトです。

「OWASP Top10」は、特に注意すべき脆弱性をランキング形式でまとめたリストで、セキュアコーディングの教科書ともいえる存在です。

代表的な脆弱性と対策

脆弱性	説明	主な対策
SQLインジェクション	ユーザー入力からSQLを改ざん	プレースホルダを使う、ORMの活用
XSS（クロスサイトスクリプティング）	悪意あるJavaScriptを注入	HTMLエスケープ、Content Security Policy
認証の不備	セッション固定、パスワード保護不十分	ハッシュ化（bcrypt等）、二段階認証
CSRF	ログイン状態のまま悪意あるリクエストを強制	トークン制御（CSRFトークン）、SameSite設定

OWASP公式では、各項目についての詳細なガイドラインや実装例も公開されており、バックエンドエンジニアは積極的に参照すべき資料です。

5. 推奨される学習順序

Cookie/セッションによる基本的な認証とユーザー管理の理解
JWTを使ったステートレスな認証の実装
OAuth2.0を用いた外部サービス連携
OWASP Top10に基づいた脆弱性とその対策の学習

実際の開発やポートフォリオ制作では、セッションとJWTの違いや選択理由を言語化できるようになることが大切です。

まとめ

認証は「誰か」を確認する仕組み
認可は「何ができるか」を制御する仕組み
Cookie・JWT・OAuth2.0は目的に応じて選択すべき
セキュリティ対策は「実装」「設定」「教育」の3層で行う

セキュアなアプリケーション設計は、信頼性と継続性の根幹を支えます。機能実装と並行して、常にセキュリティの視点を持ち続けることが、プロフェッショナルなバックエンドエンジニアへの第一歩です。

バックエンドエンジニア必須の基礎知識：認証・認可とセキュリティ対策の全体像