Apr 12, 2026 · 14:30 JST

認証ページは誰が提供すべきか

認証ページを認証基盤側でホストする（Hosted Login）か、各プロダクトに埋め込む（Embedded Login）か。セキュリティ、SSO、UX、運用コストの観点で比較する。

認証 OIDC UX セキュリティ設計

はじめに

自社で OIDC Provider を運営するとき、「ログイン画面をどこに置くか」は重要な設計判断です。

選択肢は 2 つ：

Hosted Login — 認証基盤がログインページを丸ごと提供する。プロダクトはリダイレクトするだけ
Embedded Login — 各プロダクトがログインフォームを自前で持ち、バックエンドで認証 API を叩く

結論から言うと、Hosted Login が正解です。この記事ではその理由を整理します。

プロダクトはログイン UI を一切持ちません。ユーザーは一旦 auth.example.com に移動し、認証後にプロダクトに戻ってきます。

プロダクトがログインフォームを持ち、パスワードを受け取って認証 API に送信します。

比較

観点	Hosted Login	Embedded Login
パスワードの経路	認証基盤にしか送られない	プロダクトを経由する
SSO	自然に実現（認証基盤の cookie）	実現困難
プロダクト側の実装	リダイレクトするだけ	ログインフォーム + API 呼び出し
UI の一貫性	全プロダクトで同じログイン画面	プロダクトごとにバラバラ
UI のカスタマイズ	認証基盤側で管理	プロダクトが自由に変更可能
ログイン UI の更新	1 箇所で全プロダクトに反映	各プロダクトで個別対応
UX	リダイレクトが入る	シームレス
MFA 対応	認証基盤が一括対応	各プロダクトで実装が必要
セキュリティ監査	認証基盤だけ監査すればよい	全プロダクトを監査する必要あり

1. パスワードがプロダクトを通らない

Embedded Login では、ユーザーのパスワードがプロダクトのフロントエンド → バックエンドを経由します。

これは以下のリスクを生みます：

プロダクトのログにパスワードが残る可能性
プロダクトの XSS 脆弱性でパスワードが漏洩する可能性
プロダクトの開発者がパスワードを盗める（信頼の問題）

Hosted Login なら、パスワードは auth.example.com にしか送られません。プロダクトが受け取るのは認可コードだけです。

2. SSO が自然に動く

Hosted Login では、認証基盤のドメイン（auth.example.com）にセッション cookie が保存されます。

Embedded Login でこれを実現するには、各プロダクトが認証基盤のセッション状態を確認する仕組み（hidden iframe や silent authentication）が必要になり、複雑さが大幅に増します。

3. MFA の追加が 1 箇所で済む

将来 MFA（TOTP、WebAuthn 等）を追加するとき：

Hosted Login: 認証基盤のログインページに MFA ステップを追加するだけ。全プロダクトに即反映
Embedded Login: 各プロダクトのログインフォームに MFA UI を追加する必要がある。MFA の種類が増えるたびに全プロダクトを更新

4. セキュリティ監査のスコープが小さい

認証に関するセキュリティ監査（SOC 2、ISO 27001 等）を受ける場合：

Hosted Login: auth.example.com だけを監査すればよい
Embedded Login: パスワードを扱う全プロダクトが監査対象になる

5. OAuth 2.0 / OIDC の標準に沿っている

Authorization Code Flow は本来、ユーザーを認可サーバーにリダイレクトして認証する設計です。Embedded Login で Resource Owner Password Grant を使うのは OAuth の設計意図に反しており、OAuth 2.1 で正式に廃止されます。

弱点 1: リダイレクトの UX

ユーザーがプロダクトのドメインから一旦離れるのは、UX として若干の違和感があります。

対策:

ログインページのデザインを統一ブランドにする（「〇〇にログイン」ではなく「〇〇アカウントでログイン」）
SSO が効いている場合はリダイレクトが一瞬で終わるので、ほとんど気にならない
Auth0、Google、GitHub など主要サービスは全てこの方式であり、ユーザーは慣れている

弱点 2: カスタマイズの制限

ログインページのデザインを各プロダクトに合わせたい場合、認証基盤側で対応する必要があります。

対策:

クエリパラメータでテーマを切り替える（?theme=cases → プロダクト A 用のスタイル）
ロゴ、カラー、文言をクライアント登録時に設定できるようにする
CSS カスタマイズ用のエンドポイントを提供する

GET /oidc/authorize?client_id=cases-app&theme=cases
→ Cases プロダクト用のデザインでログイン画面を表示

弱点 3: 認証基盤がダウンすると全停止

これは Hosted Login 特有の問題ではなく、認証基盤に依存するすべての設計で同じです。認証基盤の高可用性は前提条件です。

ケース	理由
ネイティブモバイルアプリ	OS が提供する WebView / Custom Tabs で Hosted Login を表示するのが標準だが、独自 UI を求められることもある
レガシーシステムの移行期	既存のログインフォームを維持しながら段階的に Hosted Login に移行
ファーストパーティの 1 プロダクトのみ	SSO が不要で、認証基盤とプロダクトが同一チームの場合

ただし、これらのケースでも 将来的に Hosted Login に移行する前提 で設計しておくのが望ましいです。

主要サービスの選択

サービス	方式
Google	Hosted Login（accounts.google.com）
GitHub	Hosted Login（github.com/login/oauth）
Auth0	Hosted Login（Universal Login を推奨）
Firebase Auth	両方（Hosted 推奨）
Cognito	Hosted UI あり（カスタマイズ制限あり）
Okta	Hosted Login（Sign-In Widget も提供）

ほぼすべてのサービスが Hosted Login を推奨しています。

ログインページの品質

Hosted Login を採用するなら、ログインページの品質が全プロダクトの第一印象を決めます。最低限押さえるべきポイント：

項目	内容
レスポンシブ	モバイル・タブレットで崩れない
高速	3 秒以内にインタラクティブ
アクセシビリティ	キーボード操作、スクリーンリーダー対応
エラーメッセージ	「メールアドレスまたはパスワードが正しくありません」（どちらが間違いかは言わない）
ブランディング	会社ロゴ、統一カラー
多言語	日本語・英語（最低限）
ソーシャルログインボタン	Google 等のボタンデザインガイドラインに準拠

まとめ

Hosted Login（認証基盤がログインページを丸ごと提供）が正解
パスワードがプロダクトを通らない、SSO が自然に動く、MFA 追加が 1 箇所で済む
リダイレクトの UX は SSO が効いていればほぼ気にならない
カスタマイズはテーマ機能やクライアント別設定で対応
Auth0、Google、GitHub 等の主要サービスもすべてこの方式
Embedded Login は Resource Owner Password Grant を使うことになり、OAuth 2.1 で廃止予定

## はじめに

自社で OIDC Provider を運営するとき、「ログイン画面をどこに置くか」は重要な設計判断です。

選択肢は 2 つ：

1. **Hosted Login** — 認証基盤がログインページを丸ごと提供する。プロダクトはリダイレクトするだけ
2. **Embedded Login** — 各プロダクトがログインフォームを自前で持ち、バックエンドで認証 API を叩く

結論から言うと、**Hosted Login が正解**です。この記事ではその理由を整理します。

## Hosted Login の動き

```mermaid
sequenceDiagram
    participant U as ユーザー
    participant P as プロダクト A (cases.example.com)
    participant A as 認証基盤 (auth.example.com)
    U->>P: 「ログイン」ボタン押下
    P->>U: /oidc/authorize へリダイレクト
    U->>A: ログイン画面を表示
    Note over A: auth.example.com のログインフォーム（メール / パスワード / Google でログイン / ログイン）
    U->>A: 認証成功
    A->>U: 認可コードで戻る
    U->>P: /callback?code=xxx
    P->>A: コードをトークンに交換
    A-->>P: トークン
    P->>U: ログイン完了
```

プロダクトはログイン UI を一切持ちません。ユーザーは一旦 `auth.example.com` に移動し、認証後にプロダクトに戻ってきます。

## Embedded Login の動き

```mermaid
sequenceDiagram
    participant U as ユーザー
    participant F as プロダクト A フロントエンド (cases.example.com)
    participant B as プロダクト A バックエンド
    participant A as 認証 API (auth.example.com/auth/login)
    Note over F: cases.example.com のログインフォーム（メール / パスワード / ログイン）
    U->>F: メールとパスワードを入力
    F->>B: パスワードをバックエンドに送信
    B->>A: 認証 API を呼び出し
    A-->>B: トークン取得
    B->>U: ログイン完了
```

プロダクトがログインフォームを持ち、パスワードを受け取って認証 API に送信します。

## 比較

| 観点 | Hosted Login | Embedded Login |
|------|-------------|---------------|
| **パスワードの経路** | 認証基盤にしか送られない | プロダクトを経由する |
| **SSO** | 自然に実現（認証基盤の cookie） | 実現困難 |
| **プロダクト側の実装** | リダイレクトするだけ | ログインフォーム + API 呼び出し |
| **UI の一貫性** | 全プロダクトで同じログイン画面 | プロダクトごとにバラバラ |
| **UI のカスタマイズ** | 認証基盤側で管理 | プロダクトが自由に変更可能 |
| **ログイン UI の更新** | 1 箇所で全プロダクトに反映 | 各プロダクトで個別対応 |
| **UX** | リダイレクトが入る | シームレス |
| **MFA 対応** | 認証基盤が一括対応 | 各プロダクトで実装が必要 |
| **セキュリティ監査** | 認証基盤だけ監査すればよい | 全プロダクトを監査する必要あり |

## Hosted Login を選ぶべき理由

### 1. パスワードがプロダクトを通らない

Embedded Login では、ユーザーのパスワードがプロダクトのフロントエンド → バックエンドを経由します。

```mermaid
flowchart LR
    U["ユーザー"] -->|"パスワード"| P["プロダクトA"]
    P -->|"パスワード"| A["認証API"]
    P -.- N["プロダクトAがパスワードを見れる"]
```

これは以下のリスクを生みます：

- プロダクトのログにパスワードが残る可能性
- プロダクトの XSS 脆弱性でパスワードが漏洩する可能性
- プロダクトの開発者がパスワードを盗める（信頼の問題）

Hosted Login なら、パスワードは `auth.example.com` にしか送られません。プロダクトが受け取るのは認可コードだけです。

### 2. SSO が自然に動く

Hosted Login では、認証基盤のドメイン（`auth.example.com`）にセッション cookie が保存されます。

```mermaid
sequenceDiagram
    participant U as ユーザー
    participant PA as プロダクト A
    participant PB as プロダクト B
    participant A as auth.example.com
    U->>PA: プロダクト A にログイン
    PA->>A: リダイレクト（認証）
    A-->>U: セッション cookie が作られる
    U->>PB: プロダクト B にアクセス
    PB->>A: auth.example.com にリダイレクト
    Note over A: セッション cookie があるのでログイン画面スキップ
    A-->>PB: 即座に認可コード発行してプロダクト B に戻る
    PB->>U: ログイン完了（ユーザーはログイン画面を見ていない）
```

### 3. MFA の追加が 1 箇所で済む

将来 MFA（TOTP、WebAuthn 等）を追加するとき：

- **Hosted Login**: 認証基盤のログインページに MFA ステップを追加するだけ。全プロダクトに即反映
- **Embedded Login**: 各プロダクトのログインフォームに MFA UI を追加する必要がある。MFA の種類が増えるたびに全プロダクトを更新

### 4. セキュリティ監査のスコープが小さい

認証に関するセキュリティ監査（SOC 2、ISO 27001 等）を受ける場合：

- **Hosted Login**: `auth.example.com` だけを監査すればよい
- **Embedded Login**: パスワードを扱う全プロダクトが監査対象になる

### 5. OAuth 2.0 / OIDC の標準に沿っている

## Hosted Login の弱点と対策

### 弱点 1: リダイレクトの UX

ユーザーがプロダクトのドメインから一旦離れるのは、UX として若干の違和感があります。

**対策:**

- ログインページのデザインを統一ブランドにする（「〇〇 にログイン」ではなく「〇〇 アカウントでログイン」）
- SSO が効いている場合はリダイレクトが一瞬で終わるので、ほとんど気にならない
- Auth0、Google、GitHub など主要サービスは全てこの方式であり、ユーザーは慣れている

### 弱点 2: カスタマイズの制限

ログインページのデザインを各プロダクトに合わせたい場合、認証基盤側で対応する必要があります。

**対策:**

- クエリパラメータでテーマを切り替える（`?theme=cases` → プロダクト A 用のスタイル）
- ロゴ、カラー、文言をクライアント登録時に設定できるようにする
- CSS カスタマイズ用のエンドポイントを提供する

```
GET /oidc/authorize?client_id=cases-app&theme=cases
→ Cases プロダクト用のデザインでログイン画面を表示
```

### 弱点 3: 認証基盤がダウンすると全停止

これは Hosted Login 特有の問題ではなく、認証基盤に依存するすべての設計で同じです。認証基盤の高可用性は前提条件です。

## Embedded Login が許容されるケース

| ケース | 理由 |
|-------|------|
| **ネイティブモバイルアプリ** | OS が提供する WebView / Custom Tabs で Hosted Login を表示するのが標準だが、独自 UI を求められることもある |
| **レガシーシステムの移行期** | 既存のログインフォームを維持しながら段階的に Hosted Login に移行 |
| **ファーストパーティの 1 プロダクトのみ** | SSO が不要で、認証基盤とプロダクトが同一チームの場合 |

ただし、これらのケースでも **将来的に Hosted Login に移行する前提** で設計しておくのが望ましいです。

## 主要サービスの選択

| サービス | 方式 |
|---------|------|
| **Google** | Hosted Login（accounts.google.com） |
| **GitHub** | Hosted Login（github.com/login/oauth） |
| **Auth0** | Hosted Login（Universal Login を推奨） |
| **Firebase Auth** | 両方（Hosted 推奨） |
| **Cognito** | Hosted UI あり（カスタマイズ制限あり） |
| **Okta** | Hosted Login（Sign-In Widget も提供） |

ほぼすべてのサービスが Hosted Login を推奨しています。

## ログインページの品質

Hosted Login を採用するなら、ログインページの品質が全プロダクトの第一印象を決めます。最低限押さえるべきポイント：

| 項目 | 内容 |
|------|------|
| **レスポンシブ** | モバイル・タブレットで崩れない |
| **高速** | 3 秒以内にインタラクティブ |
| **アクセシビリティ** | キーボード操作、スクリーンリーダー対応 |
| **エラーメッセージ** | 「メールアドレスまたはパスワードが正しくありません」（どちらが間違いかは言わない） |
| **ブランディング** | 会社ロゴ、統一カラー |
| **多言語** | 日本語・英語（最低限） |
| **ソーシャルログインボタン** | Google 等のボタンデザインガイドラインに準拠 |

## まとめ

- **Hosted Login**（認証基盤がログインページを丸ごと提供）が正解
- パスワードがプロダクトを通らない、SSO が自然に動く、MFA 追加が 1 箇所で済む
- リダイレクトの UX は SSO が効いていればほぼ気にならない
- カスタマイズはテーマ機能やクライアント別設定で対応
- Auth0、Google、GitHub 等の主要サービスもすべてこの方式
- Embedded Login は Resource Owner Password Grant を使うことになり、OAuth 2.1 で廃止予定