Authの仕組みについて

Basic認証からOAuth 2.0、OpenID Connect、Auth0までの軌跡

Webサービスを開発していると、次のような言葉をよく見かけます。

• Basic認証
• Cookie
• Session
• JWT
• OAuth 2.0
• OpenID Connect
• Auth0

どれもログイン周辺で使われる言葉ですが、それぞれ役割が異なります。

特に混同しやすいのが、次の2つです。

• OAuth 2.0：第三者のアプリケーションへ権限を渡すための「認可」の標準仕様
• Auth0：OAuth 2.0やOpenID Connectなどを利用して、認証・認可機能を提供するサービス

つまり、Auth0とOAuth 2.0は競合する技術ではありません。

Auth0は、OAuth 2.0などの標準仕様を利用しやすい形で提供する認証プラットフォームです。

この記事では、現在の認証・認可の仕組みがどのように生まれたのかを、歴史に沿って解説します。

---

Authとは何か

「Auth」という言葉は、主に次の2つの意味を含んでいます。

Authentication：認証

認証とは、アクセスしている人が誰なのかを確認することです。

例えば、ログイン画面でメールアドレスとパスワードを入力し、

このユーザーは本当に川崎さんなのか

を確認する処理が認証です。

ユーザー
  ↓
メールアドレス・パスワードを入力
  ↓
本人であることを確認
  ↓
ログイン成功

Authorization：認可

認可とは、認証されたユーザーが何をしてよいのかを判断することです。

例えば、次のような権限管理が認可に該当します。

一般ユーザー
  └─ 記事を閲覧できる

編集者
  ├─ 記事を閲覧できる
  └─ 記事を編集できる

管理者
  ├─ 記事を閲覧できる
  ├─ 記事を編集できる
  └─ ユーザーを削除できる

簡単に整理すると、次のようになります。

用語	意味	確認すること
Authentication	認証	あなたは誰ですか
Authorization	認可	あなたは何をしてよいですか

---

第1章：Basic認証

初期のWebでは、非常にシンプルな認証方式としてBasic認証が使われていました。

Basic認証では、ブラウザがユーザー名とパスワードをHTTPリクエストのヘッダーに含めて送信します。

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Basicの後ろにある文字列は、次のような情報をBase64形式でエンコードしたものです。

username:password

Base64は暗号化ではない

Base64は、データの形式を変換しているだけです。

暗号化ではないため、簡単に元の文字列へ戻せます。

そのため、Basic認証を利用する場合はHTTPSが必須です。

ユーザー
  ↓
ユーザー名・パスワード
  ↓
Base64でエンコード
  ↓
サーバーへ送信

Basic認証の問題点

Basic認証には、次のような問題があります。

• リクエストのたびにユーザー名とパスワードを送信する
• ログアウトやセッション管理を実装しにくい
• 細かい権限管理が難しい
• 第三者サービスへ安全に権限を渡せない

小規模な管理画面や検証環境では現在も使われますが、一般ユーザー向けサービスのログイン機能としては、より柔軟な方式が利用されています。

---

第2章：CookieとSession

毎回パスワードを送信する問題を解決するために、CookieとSessionを利用したログイン方式が広く使われるようになりました。

Sessionを利用したログインの流れ

1. ユーザーがメールアドレスとパスワードを送信する
2. サーバーがユーザー情報を確認する
3. サーバーがSessionを作成する
4. Session IDをCookieとしてブラウザへ返す
5. 以降、ブラウザはCookieを自動的に送信する

図にすると、次のようになります。

ユーザー
  │
  │ メールアドレス・パスワード
  ▼
サーバー
  │
  │ Sessionを作成
  │ Session IDを返す
  ▼
ブラウザ
  │
  │ CookieにSession IDを保存
  ▼
次回以降はSession IDだけを送信

Cookieには、一般的にSession IDだけを保存します。

Set-Cookie: session_id=abc123xyz

実際のユーザー情報はサーバー側に保存されます。

session_id: abc123xyz
user_id: 100
expires_at: 2026-08-01 12:00:00

Session方式のメリット

• 毎回パスワードを送信しなくてよい
• サーバー側からSessionを無効化できる
• ログアウトを実装しやすい
• ブラウザ向けのWebアプリケーションと相性がよい

Session方式の課題

Session情報をサーバー側で管理する必要があります。

サーバーが1台だけであれば問題ありませんが、複数台になるとSession情報を共有しなければなりません。

             ┌─ WebサーバーA
ユーザー ────┤
             └─ WebサーバーB

WebサーバーAで作成したSessionを、WebサーバーBでも確認できるようにする必要があります。

そのため、Redisなどの共有ストレージにSessionを保存する構成が使われます。

WebサーバーA ─┐
              ├─ Redis
WebサーバーB ─┘

---

第3章：APIと外部サービス連携の登場

Webサービスが増えるにつれて、サービス同士を連携したいという需要が生まれました。

例えば、写真印刷サービスがGoogleフォトの写真を取得したいとします。

当時、標準的な権限委譲の仕組みがなければ、ユーザーは写真印刷サービスへGoogleのIDとパスワードを渡す必要がありました。

ユーザー
  ↓
写真印刷サービスへGoogleのID・パスワードを入力
  ↓
写真印刷サービスがGoogleへログイン
  ↓
写真を取得

これは非常に危険です。

写真印刷サービスがGoogleのIDとパスワードを知ってしまうため、写真以外の情報にもアクセスできる可能性があります。

また、ユーザーがパスワードを変更すると連携できなくなります。

本当に渡したいのはパスワードではない

ユーザーが本当に許可したいのは、次のような限定的な権限です。

この写真印刷サービスに、Googleフォトの写真を読み取る権限だけを与えたい

しかし、IDとパスワードを渡す方式では、アカウント全体へのアクセス権を渡すことになります。

この問題を解決するために登場したのがOAuthです。

---

第4章：OAuth 1.0

OAuthの基本的な目的は、パスワードを第三者サービスへ渡さずに、限定的な権限だけを与えることです。

例えば、あるアプリケーションからSNSへ投稿したい場合、次のような流れになります。

ユーザー
  ↓
アプリケーションからSNSの認可画面へ移動
  ↓
「このアプリに投稿を許可しますか？」
  ↓
ユーザーが許可
  ↓
アプリケーションへTokenを発行
  ↓
アプリケーションがTokenを使って投稿

アプリケーションは、ユーザーのSNSパスワードを知る必要がありません。

パスワードを渡す
       ×

限定的なTokenを渡す
       ○

OAuth 1.0の特徴

OAuth 1.0では、APIリクエストごとに署名を作成します。

署名によって、リクエストが途中で改ざんされていないことなどを確認できます。

一方で、次のような課題がありました。

• 署名の作成処理が複雑
• クライアント側の実装が難しい
• 開発言語ごとの差異が発生しやすい
• モバイルアプリなど、新しい利用形態へ対応しにくい

より柔軟で実装しやすい仕組みとして、OAuth 2.0が設計されました。

---

第5章：OAuth 2.0

OAuth 2.0は、第三者アプリケーションへ限定的な権限を渡すための認可フレームワークです。

2012年にRFC 6749として標準化されました。

重要なのは、OAuth 2.0は基本的にログインのための仕様ではないという点です。

OAuth 2.0が扱うのは、次の問題です。

このアプリケーションに、どのAPIを利用する権限を与えるか

つまり、OAuth 2.0の中心は認証ではなく認可です。

---

OAuth 2.0に登場する4つの役割

OAuth 2.0には、主に次の4つの役割があります。

Resource Owner

保護されたデータの所有者です。

一般的にはユーザーを指します。

例：Google Driveの所有者であるユーザー

Client

ユーザーの代わりにAPIを利用したいアプリケーションです。

例：Google Driveのファイルを読み取りたいタスク管理アプリ

Authorization Server

ユーザーの認証と同意を受け付け、Tokenを発行するサーバーです。

例：Googleの認可サーバー

Resource Server

保護されたデータやAPIを提供するサーバーです。

例：Google Drive API

全体の関係は次のようになります。

Resource Owner
    ユーザー
       │
       ▼
Client
    外部アプリ
       │
       ▼
Authorization Server
    認可サーバー
       │
       │ Access Tokenを発行
       ▼
Resource Server
    APIサーバー

---

第6章：Access Token

OAuth 2.0では、ClientがAPIを利用するためにAccess Tokenを使用します。

Access Tokenは、APIへアクセスするための一時的な通行証のようなものです。

Authorization: Bearer ACCESS_TOKEN

例えば、Google Drive APIへアクセスする場合は次のようになります。

GET /drive/v3/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

Resource ServerはAccess Tokenを確認し、そのTokenに必要な権限が含まれていればAPIの利用を許可します。

Scope

Access Tokenに与える権限の範囲をScopeと呼びます。

例えば、次のようなScopeが考えられます。

profile.read
email.read
files.read
files.write
posts.write

ユーザーには、どの権限を許可するのかを確認する画面が表示されます。

このアプリケーションは、次の権限を要求しています。

・プロフィール情報の確認
・メールアドレスの確認
・ファイルの読み取り

許可しますか？

Scopeを利用することで、アカウント全体の権限ではなく、必要な権限だけを渡せます。

---

第7章：Authorization Code Flow

現在、Webアプリケーションやモバイルアプリケーションで広く利用されているのがAuthorization Code Flowです。

処理の流れ

1. ClientがユーザーをAuthorization Serverへ移動させる
2. ユーザーがAuthorization Serverでログインする
3. ユーザーが権限の付与に同意する
4. ClientへAuthorization Codeが返される
5. ClientがAuthorization CodeをTokenと交換する
6. Access Tokenを使ってAPIへアクセスする

図にすると、次のようになります。

ユーザー
  │
  │ ① ログイン・認可画面へ移動
  ▼
Authorization Server
  │
  │ ② ユーザーがログイン
  │ ③ 権限の付与に同意
  ▼
Client
  │
  │ ④ Authorization Codeを受け取る
  │ ⑤ CodeをTokenと交換
  ▼
Authorization Server
  │
  │ ⑥ Access Tokenを発行
  ▼
Client
  │
  │ ⑦ Access Tokenを送信
  ▼
Resource Server

なぜ最初からAccess Tokenを返さないのか

ブラウザのURLなどを経由して、直接Access Tokenを返すと、Tokenが漏洩する危険性が高くなります。

そこで、まず短時間だけ使用できるAuthorization Codeを返し、そのCodeを安全な通信でAccess Tokenへ交換します。

---

第8章：PKCE

PKCEは「Proof Key for Code Exchange」の略称です。

Authorization Code Flowを、モバイルアプリやSPAでも安全に利用するための仕組みです。

「ピクシー」と読みます。

Client Secretを安全に保存できない問題

従来のサーバーサイドアプリケーションでは、Client Secretをサーバー内に保存できます。

しかし、次のようなアプリケーションでは、Client Secretを完全に隠すことができません。

• SPA
• iOSアプリ
• Androidアプリ
• デスクトップアプリ

JavaScriptやアプリケーションのバイナリを解析されると、Client Secretが取得される可能性があるためです。

PKCEの仕組み

Clientは、認可リクエストを始める前にランダムな文字列を作成します。

code_verifier

code_verifierを変換した値が、code_challengeです。

code_verifier
  ↓ ハッシュ化
code_challenge

最初の認可リクエストでは、code_challengeを送信します。

Tokenを取得するときには、元のcode_verifierを送信します。

Authorization Serverは、code_verifierから作られる値が最初のcode_challengeと一致するかを確認します。

Client
  │
  │ code_challenge
  ▼
Authorization Server
  │
  │ Authorization Code
  ▼
Client
  │
  │ Authorization Code
  │ code_verifier
  ▼
Authorization Server
  │
  │ code_verifierを検証
  ▼
Access Tokenを発行

Authorization Codeだけを盗まれても、code_verifierがなければTokenへ交換できません。

現在は、Authorization Code FlowとPKCEを組み合わせる構成が基本です。

---

第9章：Refresh Token

Access Tokenは、漏洩したときの被害を抑えるため、一般的に有効期限が短く設定されます。

例えば、Access Tokenの有効期限が1時間の場合、1時間ごとにユーザーへログインを求めるのは不便です。

そこで利用されるのがRefresh Tokenです。

Access Token
  └─ APIへアクセスするために使う
  └─ 有効期限が短い

Refresh Token
  └─ 新しいAccess Tokenを取得するために使う
  └─ Access Tokenより長期間利用される

処理の流れは次のとおりです。

Client
  │
  │ Access Token
  ▼
Resource Server
  │
  │ Tokenの期限切れ
  ▼
Client
  │
  │ Refresh Token
  ▼
Authorization Server
  │
  │ 新しいAccess Tokenを発行
  ▼
Client

Refresh Tokenは強力なTokenです。

漏洩すると、新しいAccess Tokenを継続的に発行される可能性があります。

そのため、次のような対策が必要です。

• 安全な場所へ保存する
• 有効期限を設定する
• 使用後に新しいRefresh Tokenへ交換する
• 漏洩が疑われる場合は無効化する
• Refresh Token Rotationを利用する

---

第10章：OAuth 2.0だけではログインを表現できない

OAuth 2.0では、Access Tokenを取得できます。

しかし、OAuth 2.0が保証しているのは、あくまでAPIを利用する権限です。

Access Tokenを受け取っただけでは、次の情報が標準的な方法で分かるとは限りません。

• ログインしたユーザーは誰なのか
• ユーザーの識別子は何か
• いつ認証されたのか
• どの認証方式を利用したのか

OAuth 2.0をログイン機能として独自に利用すると、サービスごとに実装が異なってしまいます。

この問題を解決するために登場したのがOpenID Connectです。

---

第11章：OpenID Connect

OpenID Connectは、OAuth 2.0の上に認証機能を追加した仕様です。

略してOIDCと呼ばれます。

OAuth 2.0
  └─ 認可の仕組み

OpenID Connect
  └─ OAuth 2.0を利用した認証の仕組み

OpenID Connectでは、Access Tokenに加えてID Tokenが発行されます。

Access Token
  └─ APIへアクセスするためのToken

ID Token
  └─ 認証されたユーザーの情報を表すToken

ID Token

ID Tokenには、一般的に次のような情報が含まれます。

{
  "iss": "https://example.auth0.com/",
  "sub": "auth0|123456789",
  "aud": "my-client-id",
  "exp": 1785500000,
  "iat": 1785496400,
  "name": "川崎 拓真",
  "email": "[e-mail]"
}

主な項目は次のとおりです。

項目	意味
iss	ID Tokenを発行した認証サーバー
sub	ユーザーを一意に識別するID
aud	このID Tokenを利用するClient
exp	有効期限
iat	発行日時
name	ユーザー名
email	メールアドレス

ID Tokenを検証することで、Clientはログインしたユーザーを特定できます。

Googleログインの実態

「Googleでログイン」は、一般的にOpenID Connectを利用しています。

ユーザー
  ↓
「Googleでログイン」を選択
  ↓
Googleの認証画面へ移動
  ↓
Googleで本人確認
  ↓
ClientへAuthorization Codeを返す
  ↓
ID TokenとAccess Tokenを発行
  ↓
Clientがユーザーをログイン状態にする

Googleログインを単純に「OAuthログイン」と呼ぶこともありますが、ユーザー認証まで行う場合は、厳密にはOpenID Connectが重要な役割を担っています。

---

第12章：JWT

JWTは「JSON Web Token」の略称です。

TokenのデータをJSON形式で表現し、署名を付けたものです。

「ジョット」と読みます。

ID Tokenには、一般的にJWTが利用されます。

Access TokenにもJWTが使われる場合がありますが、OAuth 2.0ではAccess TokenをJWTにすることは必須ではありません。

JWTの構造

JWTは、次の3つの部分で構成されています。

Header.Payload.Signature

実際には、次のような文字列になります。

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IuW3neW0ju‹省略›.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header

使用している署名アルゴリズムなどが含まれます。

{
  "alg": "RS256",
  "typ": "JWT"
}

Payload

ユーザーIDや有効期限などの情報が含まれます。

{
  "sub": "1234567890",
  "name": "川崎 拓真",
  "exp": 1785500000
}

Signature

HeaderとPayloadが改ざんされていないことを確認するための署名です。

JWTは暗号化ではない

JWTのPayloadは、通常Base64URL形式でエンコードされているだけです。

そのため、Tokenを取得した人はPayloadの内容を確認できます。

JWTに含めてはいけない情報

・パスワード
・クレジットカード番号
・秘密鍵
・外部へ公開できない個人情報

JWTの署名は、内容を隠すためではなく、内容が改ざんされていないことを確認するために使われます。

---

第13章：SessionとJWTの違い

Session方式とJWT方式は、完全な対立関係ではありません。

Session Cookieの中にJWTを保存する構成や、認証基盤ではJWTを使い、自社サービス内ではSessionを使う構成もあります。

Session方式

ブラウザ
  │ Session ID
  ▼
サーバー
  │ Session情報を検索
  ▼
ユーザーを特定

JWT方式

ブラウザ・アプリ
  │ JWT
  ▼
サーバー
  │ 署名・有効期限などを検証
  ▼
ユーザーや権限を確認

主な違いは次のとおりです。

項目	Session	JWT
状態の保存	サーバー側に保存	Token内に情報を含められる
無効化	サーバー側で行いやすい	有効期限前の無効化には工夫が必要
複数サーバー	Session共有が必要	公開鍵などで検証しやすい
Tokenサイズ	Session IDだけなら小さい	情報量によって大きくなる
ブラウザとの相性	非常によい	保存方法に注意が必要
APIとの相性	構成による	Bearer Tokenとして利用しやすい

「JWTの方が新しいから、常にSessionより優れている」というわけではありません。

サービスの構成やセキュリティ要件に応じて選択します。

---

第14章：Auth0の登場

OAuth 2.0やOpenID Connectを正しく実装するには、多くの知識が必要です。

例えば、次のような機能を考える必要があります。

• メールアドレスとパスワードによるログイン
• Googleログイン
• Appleログイン
• GitHubログイン
• パスワードのハッシュ化
• パスワード再設定
• メールアドレス認証
• 多要素認証
• Access Tokenの発行
• Refresh Tokenの管理
• OpenID Connectへの対応
• JWTの署名と検証
• 不正ログインの検知
• ユーザー情報の管理
• ログイン履歴の記録
• アカウントロック
• Bot対策

これらをすべて自社で実装し、安全に運用し続けるのは簡単ではありません。

そこで利用されるのがAuth0のようなID管理サービスです。

Auth0とは

Auth0は、認証・認可機能をアプリケーションへ組み込むためのIdentity Platformです。

Auth0を利用すると、次のような機能を導入できます。

• メールアドレス・パスワードログイン
• Googleなどのソーシャルログイン
• シングルサインオン
• 多要素認証
• OAuth 2.0
• OpenID Connect
• Access Tokenの発行
• ID Tokenの発行
• パスワードリセット
• ユーザー管理
• ロール・権限管理

Auth0は独自の認証規格ではありません。

OAuth 2.0やOpenID Connectなどの標準仕様を利用し、認証機能を導入しやすくするサービスです。

---

第15章：Auth0を利用したログインの流れ

Auth0を利用した一般的なログイン処理は、次のようになります。

ユーザー
  │
  │ ① ログインボタンを押す
  ▼
自社アプリケーション
  │
  │ ② Auth0のログイン画面へ移動
  ▼
Auth0
  │
  ├─ メールアドレス・パスワード
  ├─ Google
  ├─ Apple
  └─ GitHub
  │
  │ ③ ユーザーを認証
  ▼
自社アプリケーション
  │
  │ ④ Authorization Codeを受け取る
  │ ⑤ CodeをTokenと交換
  ▼
Auth0
  │
  ├─ ID Token
  ├─ Access Token
  └─ 必要に応じてRefresh Token
  │
  ▼
自社アプリケーション

ID Tokenの用途

ID Tokenは、ユーザーの認証結果をClientへ伝えるために使用します。

このユーザーは誰なのか
いつ認証されたのか
どのサービスがTokenを発行したのか

Access Tokenの用途

Access Tokenは、APIへアクセスするために使用します。

GET /api/articles
Authorization: Bearer ACCESS_TOKEN

APIサーバーは、Access Tokenの署名やScopeなどを確認します。

自社フロントエンド
  │
  │ Access Token
  ▼
自社API
  │
  │ Tokenを検証
  ▼
データを返す

---

第16章：ソーシャルログイン

Auth0を利用すると、GoogleやGitHubなどの認証サービスと連携できます。

例えば、Googleログインでは次のような構成になります。

ユーザー
  ↓
自社サービス
  ↓
Auth0
  ↓
Google
  ↓
Auth0
  ↓
自社サービス

この場合、それぞれの役割は次のようになります。

サービス	主な役割
自社サービス	ユーザーへ機能を提供する
Auth0	認証処理をまとめて管理する
Google	Googleアカウントでユーザーを認証する

自社サービスは、Googleのパスワードを受け取りません。

Googleで認証された結果を、Auth0を経由して受け取ります。

---

第17章：シングルサインオン

シングルサインオンは、1回のログインで複数のサービスを利用できる仕組みです。

略してSSOと呼ばれます。

例えば、会社で次の3つのサービスを利用しているとします。

勤怠管理サービス
経費精算サービス
社内Wiki

それぞれが同じ認証基盤を利用していれば、ユーザーは一度ログインするだけで複数サービスを利用できます。

ユーザー
  │
  │ 1回ログイン
  ▼
認証基盤
  ├─ 勤怠管理サービス
  ├─ 経費精算サービス
  └─ 社内Wiki

Auth0のようなサービスは、複数のアプリケーションに対する共通の認証基盤としても利用できます。

---

第18章：現代的な認証構成

現在のWebサービスでは、次のような構成が考えられます。

ユーザー
  │
  ▼
フロントエンド
  │
  │ ログイン要求
  ▼
Auth0
  │
  ├─ Google
  ├─ Apple
  ├─ GitHub
  └─ メールアドレス・パスワード
  │
  │ ID Token・Access Token
  ▼
フロントエンド
  │
  │ Access Token
  ▼
自社API
  │
  │ Tokenを検証
  ▼
データベース

それぞれの役割を整理すると、次のようになります。

要素	役割
Auth0	ユーザーの認証とTokenの発行
OpenID Connect	ログインしたユーザーの情報を伝える
OAuth 2.0	APIを利用する権限を渡す
ID Token	認証されたユーザーの情報を表す
Access Token	APIへアクセスするために使う
Refresh Token	新しいAccess Tokenを取得する
JWT	Tokenを表現する形式として利用される
Cookie	ブラウザへ情報を保存・送信する仕組み
Session	ログイン状態などをサーバー側で管理する仕組み

---

認証技術の歴史

認証・認可の進化を簡単にまとめると、次のようになります。

Basic認証
  │
  │ 毎回パスワードを送るのは危険・不便
  ▼
Cookie・Session
  │
  │ ログイン状態を維持できるようになった
  ▼
外部API連携
  │
  │ パスワードを第三者サービスへ渡す問題が発生
  ▼
OAuth 1.0
  │
  │ パスワードを渡さず権限を委譲
  │ ただし署名処理が複雑
  ▼
OAuth 2.0
  │
  │ より柔軟な認可フレームワーク
  ▼
OpenID Connect
  │
  │ OAuth 2.0の上に認証機能を追加
  ▼
Auth0などの認証サービス
  │
  │ 標準仕様を利用した認証基盤を提供
  ▼
開発者はサービス本体の開発に集中できる

---

よくある勘違い

OAuth 2.0はログインの仕様ではない

OAuth 2.0は認可のための仕様です。

OAuth 2.0
  └─ アプリケーションへAPIの利用権限を与える

OpenID Connect
  └─ ユーザーを認証し、誰がログインしたかを伝える

「Googleでログイン」のような機能では、OAuth 2.0だけでなくOpenID Connectが利用されます。

Auth0とOAuth 2.0は同じものではない

OAuth 2.0は標準仕様です。

Auth0は、その標準仕様を利用して認証・認可機能を提供するサービスです。

OAuth 2.0
  └─ 設計ルール・標準仕様

Auth0
  └─ 標準仕様を実装した認証プラットフォーム

例えるなら、HTTPという標準仕様に対して、Webサーバー製品としてNginxやApacheが存在するような関係に近いです。

JWTは認証方式ではない

JWTはTokenの表現形式です。

JWTを使ったからといって、安全な認証が自動的に完成するわけではありません。

次のような検証が必要です。

• 署名が正しいか
• 有効期限が切れていないか
• 発行元が正しいか
• 利用対象のClientが正しいか
• 想定したアルゴリズムが使われているか
• 必要なScopeや権限を持っているか

JWTをLocalStorageへ保存すればよいとは限らない

LocalStorageに保存したTokenは、JavaScriptから読み取れます。

そのため、XSSが発生するとTokenが盗まれる可能性があります。

ブラウザアプリケーションでは、次のような構成も検討します。

• HttpOnly Cookie
• Secure Cookie
• SameSite属性
• BFF：Backend for Frontend
• 短い有効期限
• Refresh Token Rotation
• Content Security Policy

Tokenの保存場所は、アプリケーションの構成や脅威モデルに応じて判断する必要があります。

---

まとめ

Authの仕組みは、単純なID・パスワード認証から、外部サービスへ安全に権限を渡す仕組みへと進化してきました。

技術	主な役割
Basic認証	ユーザー名とパスワードをHTTPヘッダーで送信する
Cookie	ブラウザに情報を保存し、リクエスト時に送信する
Session	ログイン状態を主にサーバー側で管理する
OAuth 1.0	パスワードを共有せずに権限を委譲する
OAuth 2.0	Access Tokenを利用した柔軟な認可を実現する
PKCE	Authorization Codeの盗難による不正利用を防ぐ
OpenID Connect	OAuth 2.0の上にユーザー認証を追加する
JWT	Tokenの情報と署名を表現する形式
Auth0	認証・認可機能を提供するIdentity Platform

最も重要なポイントは、次の3つです。

認証
  └─ あなたは誰ですか

認可
  └─ あなたは何をしてよいですか

Auth0
  └─ OAuth 2.0やOpenID Connectなどを利用し、
     認証・認可機能を提供するサービス

現在のGoogleログインなどは、単に「OAuth 2.0でログインしている」のではありません。

OAuth 2.0による権限の委譲と、OpenID Connectによるユーザー認証を組み合わせて実現されています。

Auth0を利用すると、これらの複雑な仕様をすべて一から実装せずに、安全な認証基盤をアプリケーションへ導入できます。

---

参考資料

• RFC 7617：The Basic HTTP Authentication Scheme
• RFC 5849：The OAuth 1.0 Protocol
• RFC 6749：The OAuth 2.0 Authorization Framework
• RFC 7636：Proof Key for Code Exchange by OAuth Public Clients
• OpenID Connect Core 1.0
• Auth0 Documentation