Web開発を行う上で知っておくと役に立つ単語集

#  はじめに
web開発を行う上で、私自身が知らなかった単語とその意味を後で見返せるようにまとめました。(自分用メモ)
間違いがありましたら、コメントで教えてください。:joy:

# 単語一覧
- [JWT証](#jwt認証)
- [CORS](#cors)
- [CSRF](#csrf)
- [ポーリング](#ポーリング)
- [SMAL認証](#smal認証)
- [OWIN](#owin)
- [ISS](#iss)
- [vite](#vite)
- [XXS](#xxs)
- [MSAL](#msal)
- [SSO](#sso)
- [Cookie](#cookie)
- [Azure B2C](#azure-b2c)
- [Azure AD認証](#azure-ad認証)



## JWT認証
JWT認証（JSON Web Token 認証）とは、Webアプリケーションなどでユーザーの認証状態を保持するための仕組みです。セッションベースの認証に代わる仕組みとして広く使われています。
JWTをジョットと呼ぶ方もいます。

### JWTの基本構造
WTは、3つの部分からなる文字列です。ドット (.) で区切られています：
```
<ヘッダー>.<ペイロード>.<署名>
```
例えば：
```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VySWQiOjEyMywiaXNBZG1pbiI6dHJ1ZX0.
sflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
```
### 各部分の意味
| 部分   | 内容 |
|--------|------|
| ヘッダー | どんな署名アルゴリズムが使われているか（例：HS256）など |
| ペイロード | 認証されたユーザーの情報（例：ユーザーIDや権限など） |
| 署名 | トークンの改ざんを防ぐために、秘密鍵を使って生成された署名 |

### JWT認証の流れ
1. ログイン時にJWTを発行
   - ユーザーがログイン成功後、サーバーはJWTを生成してクライアントに返します。

2. クライアントがトークンを保存
   - 通常、ブラウザでは localStorage や sessionStorage に保存されます。
3. APIリクエスト時にトークンを送信
   - クライアントは、APIにアクセスする際に Authorization ヘッダーにトークンを付けて送信します。
```
Authorization: Bearer <JWT>
```
4. サーバーがトークンを検証

   - サーバーは署名を検証し、正しければユーザー情報を取得して処理を進めます。

### JWTのメリット
- サーバー側でセッション管理が不要（スケーラブル）
- ステートレスで、マイクロサービスとの相性が良い
- トークンに情報を埋め込める（ただし注意が必要）

### 注意点
- トークンは誰でも見られるので、パスワードや秘密情報は含めない
- 長時間有効なトークンは、漏洩すると危険
- HTTPSを使って通信しないと盗聴の恐れがある



## CORS
CORSとは、「Cross-Origin Resource Sharing（クロスオリジン リソースシェアリング）」の略で、Webブラウザが異なるオリジン間でリソースを共有することを制御する仕組みです。

### 「オリジン」とは？
オリジンは以下の3つの組み合わせで構成されます：
- スキーム（例：http や https）
- ドメイン（例：example.com）
- ポート番号（例：:3000）

たとえば：
| URL   | 	同一オリジン？（基準: `https://example.com`） |
|--------|------|
| `https://example.com` | :o:　同一 |
| `http://example.com` | :heavy_multiplication_x:　スキームが違う |
| `https://api.example.com` | :heavy_multiplication_x:　サブドメインが違う |
| `https://example.com:3000` | :heavy_multiplication_x:　ポートが違う |

### なぜCORSが必要？
セキュリティの観点から、ブラウザは異なるオリジン間の通信を制限しています。たとえば、あなたのWebアプリ（`http://localhost:3000`）から外部API（`https://api.example.com`）にリクエストを送ると、ブラウザはCORSポリシーに従ってその通信をブロックする可能性があります。

### CORSの解決方法（サーバー側）
サーバーがレスポンスヘッダーに以下のような情報を含めることで、CORS通信を許可できます：
```
Access-Control-Allow-Origin: http://localhost:3000
```
または、すべてのオリジンを許可したい場合：
```
Access-Control-Allow-Origin: *
```
### まとめ
| 用語   | 	内容 |
|--------|------|
| CORS | 異なるオリジン間のリソース共有を制御する仕組み |
| 目的 | セキュリティ保護（CSRFなど） |
| 対策方法 | サーバー側で適切なCORSヘッダーを返す |



## CSRF
CSRF（Cross-Site Request Forgery / クロスサイト・リクエスト・フォージェリ）とは、  
ユーザーがログイン中のWebサイトに対して、**意図しないリクエストを他の悪意あるサイトから送らせる攻撃**です。

###  簡単に言うと？
ログイン中のユーザーが、別の悪意あるサイトを見ている間に、  
そのサイトから勝手に「投稿」や「設定変更」などのリクエストが送信されることで、  
**ユーザーの意図しない操作が行われてしまう**攻撃です。

### どんな被害がある？

例：

- SNSに勝手に投稿される
- メールアドレスが変更される
- ユーザー削除や購入処理が実行される

など、ユーザーになりすまして操作される可能性があります。

### 攻撃の仕組み（ざっくり）
1. ユーザーが正規のWebサイト（例：SNS）にログイン中
2. 同時に別の悪意あるサイトを開く
3. そのサイトに仕込まれたHTMLやJavaScriptが、自動でSNSにリクエストを送る
4. SNSはクッキーでユーザーを認識 → 正当な操作と誤解
5. 結果、ユーザーの意図しない操作が行われてしまう

### 防ぐには？

| 対策                     | 説明                                                             |
|--------------------------|------------------------------------------------------------------|
| CSRFトークンの導入       | フォーム送信時に一意のトークンを付与し、サーバー側で検証する            |
| CookieのSameSite属性     | `SameSite=Lax` や `Strict` を使って、外部サイトからのリクエストでクッキーを送らせない |
| Referer / Originチェック | リクエスト元のドメインを確認して正規のものか判定する                   |

### 補足情報

- CSRFは、**クッキーによるセッション管理**をしているサイトで特に危険です。
- 一方、**トークンベース（JWTなど）のAPI認証**を使っている場合は、CSRFのリスクが小さいこともあります。



## ポーリング
**ポーリング**とは、「一定間隔でサーバーやデバイスの状態を定期的にチェックする」仕組みのことです。

### たとえば何に使うの？
- Webアプリで「新着通知」が来ているかどうかをチェック
- センサーやハードウェアの状態確認
- チャットアプリで新しいメッセージが届いていないか確認

### 仕組み（ざっくり）
1. クライアント（ブラウザやアプリ）が一定時間ごとにサーバーへアクセス
2. サーバーに「何か変化あった？」と問い合わせる
3. サーバーが「あるよ / ないよ」と返す
4. それを繰り返す

### メリット
- 実装が簡単（JavaScriptの`setInterval`などですぐできる）
- サーバー側も特別な仕組みが不要

### デメリット
- 無駄なリクエストが多い（変化がなくてもアクセスしてしまう）
- リアルタイム性が弱い（チェック間隔次第）
- 大規模になるとサーバーに負荷がかかる

### コード例（JavaScript）
```javascript
setInterval(() => {
  fetch('/api/check-updates')
    .then(res => res.json())
    .then(data => {
      if (data.hasUpdate) {
        console.log('更新があります！');
      }
    });
}, 5000); // 5秒ごとにチェック
```

### その他のリアルタイム技術との比較
| 技術                   | 説明                                                   |
|------------------------|--------------------------------------------------------|
| **Polling**            | 一定時間ごとにサーバーへ問い合わせる。最もシンプル。     |
| **Long Polling**       | サーバーが更新を検知するまで応答を保留し、検知後に返す。リアルタイム性が高め。 |
| **WebSocket**          | クライアントとサーバーが常時接続し、双方向通信が可能。リアルタイム性が高い。 |
| **Server-Sent Events** | サーバーからクライアントへ一方向のストリーム送信が可能。ブラウザ対応も広い。 |

### まとめ
- **ポーリング**は「手軽さ重視」のリアルタイム処理に向いています。
- 頻度が高すぎるとサーバーに負荷がかかるので注意。
- よりリアルタイム性を求める場合は、**WebSocket** や **SSE（Server-Sent Events）** を検討しましょう。



## SMAL認証
**SAML（Security Assertion Markup Language）認証**とは、  企業や組織でよく使われる**シングルサインオン（SSO）**を実現するための認証プロトコルの一つです。

### どんなときに使うの？
- 複数のWebサービスを1つのID・パスワードで使いたいとき（SSO）
- 社内システムで、IDプロバイダー（IdP）とアプリケーション（SP）を分離したいとき
- Azure AD や Google Workspace などと連携したログインを実現したいとき

### SAMLの登場人物
| 役割 | 名前 | 説明 |
|------|------|------|
| 認証提供者 | **IdP（Identity Provider）** | ユーザーの認証を担当するサービス（例：Azure AD、Googleなど） |
| サービス提供者 | **SP（Service Provider）** | 認証されたユーザーにサービスを提供するWebアプリなど |

### 認証の流れ（ざっくり）
1. ユーザーが SP（アプリ）にアクセス
2. SP は「このユーザー誰？」と IdP にリダイレクト
3. ユーザーは IdP でログイン
4. IdP は「この人は○○さんです」と SAMLレスポンス（署名付き）を SP に返す
5. SP はその情報を検証し、ログイン完了

### メリット
- **SSOの実現**：一度のログインで複数サービスを利用可能
- **セキュリティが高い**：電子署名付きのXMLでやり取り
- **中央管理**：ユーザー管理がIdP側で一元化される

### デメリット
- 実装がやや複雑（XMLのやり取りや署名の検証など）
- フロントエンド単体では扱いにくい（サーバー側で処理することが多い）

### よくある構成例
- IdP：Azure Active Directory / Google Workspace / Okta
- SP：自社の業務Webアプリ、SaaS（Salesforce、Boxなど）

### SAML vs OAuth2 / OpenID Connect
| 項目             | SAML                        | OAuth2 / OpenID Connect      |
|------------------|-----------------------------|------------------------------|
| 主な用途         | エンタープライズSSO         | モバイル・Webの認可/認証    |
| データフォーマット | XML                         | JSON                         |
| トークンの種類   | SAMLアサーション（XML）     | アクセストークン / IDトークン（JWT） |
| よく使われる場所 | 社内システム、SaaS連携       | Webサービス、API、スマホアプリ  |

### まとめ
- SAMLは**企業向けのSSO**の標準的な仕組み
- IdPとSPの連携で、安全かつ便利なログインが可能になる
- 最近はOAuth2 / OIDCが主流だけど、SAMLもまだまだ現役！



## OWIN
**OWIN（Open Web Interface for .NET）** とは、  **.NETアプリケーションとWebサーバーの間の標準的なインターフェース**を定義した仕様です。

### 目的は？
- **Webサーバー（IISなど）とアプリケーションの依存を減らす**
- **軽量なWebアプリケーションの開発を可能にする**
- **ミドルウェア構成の柔軟性を高める**

### なぜ必要？
従来のASP.NETは、IISに強く依存していました。  
OWINを使うことで、**IIS以外のサーバー**（たとえば`Kestrel`や`Nowin`）でも動作できるようになります。

### 主要な構成要素
| 名称       | 説明                                           |
|------------|------------------------------------------------|
| **OWIN**   | 仕様そのもの（標準インターフェース）           |
| **Middleware** | リクエスト処理の部品（パイプラインのように連結） |
| **Katana** | Microsoftが提供するOWINの実装ライブラリ         |

### OWINの流れ（ざっくり）
1. WebサーバーがHTTPリクエストを受け取る
2. OWINインターフェースを通してアプリに渡す
3. アプリは一連の**ミドルウェア**を順に処理
4. 最終的にレスポンスを返す

### 最小構成のサンプル（C#）
```csharp
using Microsoft.Owin;
using Owin;
using System.Threading.Tasks;

[assembly: OwinStartup(typeof(MyApp.Startup))]

namespace MyApp
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.Run(context =>
            {
                context.Response.ContentType = "text/plain";
                return context.Response.WriteAsync("Hello, OWIN!");
            });
        }
    }
}
```

### Katanaとは？
**Katana** は Microsoft が提供する **OWIN のリファレンス実装**です。  
OWINの仕様に基づいて、.NET Framework 上でミドルウェアベースのアプリケーションを構築するためのライブラリ群です。

### Katanaが提供する主な機能：
- HTTPリクエスト/レスポンスの処理
- 認証（Cookie、OAuth、外部ログインなど）
- 静的ファイルの配信
- SignalR の統合
- Web API / MVC との統合

### ASP.NET Coreとの違い
| 項目               | OWIN / Katana                                  | ASP.NET Core                                     |
|--------------------|------------------------------------------------|--------------------------------------------------|
| 目的               | OWIN仕様に準拠した軽量Webアプリ開発            | .NET全体を再設計した新しいWebフレームワーク     |
| 使用可能な環境     | .NET Framework                                  | .NET Core / .NET 5 以降（クロスプラットフォーム）|
| ミドルウェア定義方法 | `IAppBuilder` を使用                            | `Startup.cs` の `Configure` メソッドで定義       |
| パフォーマンス     | ASP.NETに比べて軽量（だがCoreより劣る）         | 高速でスケーラブルな設計（Kestrelなどを使用）     |
| サポート状況       | 古いが今でも一部で利用                          | Microsoft公式が推奨（最新の技術）               |

### まとめ
- **OWIN** は、Webサーバーと.NETアプリのインターフェース仕様
- **Katana** は、Microsoftが提供する OWIN の実装ライブラリ
- **ASP.NET Core** は、OWINの考えを発展させた新しいフレームワークで、現在は主流
- レガシーな.NET Framework環境では Katana + OWIN がまだ使われることもある



## ISS
**ISS（Issuer）** は、主に **JWT（JSON Web Token）** や **OAuth2 / OpenID Connect** において使われる  **「このトークンを発行した主体は誰か」** を表す識別子です。

### どこで使われる？
- **JWTのクレーム（claims）** の1つとして含まれる
- **認可サーバー（Authorization Server）** の識別
- **トークンの正当性を検証するため**に利用される

### 具体例（JWTの中身）
JWTは3つの部分（ヘッダー・ペイロード・署名）で構成されます。  
以下はペイロード（claims）の一部例です：
```json
{
  "iss": "https://auth.example.com/",
  "sub": "user123",
  "aud": "myapp",
  "exp": 1710000000
}
```
- "iss"：トークンを発行した Issuer
- "sub"：トークンの対象（Subject）
- "aud"：トークンの受け手（Audience）

### なぜ重要？
- 信頼性の確認：アプリは「iss が自分の想定した発行元か？」を確認することで、トークンの信頼性をチェック
- マルチテナント環境での識別：複数のIssuerが存在する環境で、どのIdPが発行したかを判別

### アプリ側での検証処理（擬似コード）
```python
if decoded_token["iss"] != "https://auth.example.com/":
    raise Exception("Issuerが不正です！")
```
### よく使われる `iss` の例
| システム         | `iss` の例 |
|------------------|------------|
| **Auth0**        | `https://your-tenant.auth0.com/` |
| **Firebase Auth**| `https://securetoken.google.com/your-project` |
| **Azure AD**     | `https://login.microsoftonline.com/{tenantId}/v2.0` |
| **Okta**         | `https://dev-xxxxx.okta.com/oauth2/default` |

### まとめ
- iss（Issuer）はトークンの発行元を示すクレーム
- トークンの信頼性を確認するために非常に重要
- OAuth2 / OpenID Connect / JWT を扱うときは、必ず iss を検証しよう！


## vite
**Vite（ヴィート）** は、フロントエンド開発のための **超高速なビルドツール / 開発サーバー** です。  
Vue.js の作者 Evan You 氏が開発し、現在は Vue だけでなく React や Svelte などにも対応しています。

### 特徴まとめ
| 特徴             | 説明                                                                 |
|------------------|----------------------------------------------------------------------|
| 超高速な起動     | 開発サーバーが即時に立ち上がる（ESMを活用）                          |
| 高速なHMR        | Hot Module Replacement（モジュールの即時反映）が爆速                 |
| ESM対応          | ネイティブの ES Modules を使用                                       |
| ビルドも高速     | Rollupベースの最適化されたビルドプロセス                             |
| フレームワーク非依存 | Vue / React / Svelte / Lit など、幅広く対応                           |

### なぜ速いの？
従来のツール（Webpackなど）は、開発中でもすべてのファイルをまとめてバンドルする必要がありました。  
Vite はそれに対して、
- **ESM（ネイティブモジュール）** を使って、必要なファイルだけを読み込む
- **依存モジュールは事前にキャッシュ＆変換**
- **ソースコードはオンデマンドで処理**
という仕組みで、**初回起動・更新・保存の反映すべてが爆速**です。

### インストール＆プロジェクト作成
### npm を使う場合：
```bash
npm create vite@latest my-project
cd my-project
npm install
npm run dev
```
または、yarn / pnpm にも対応しています。

### テンプレート選択肢（実行時に選べる）
- Vanilla
- Vue
- React
- Svelte
- Preact
- Lit
- Solid
- その他 TypeScript 対応版もあり

### 設定ファイル：vite.config.js（一例）
```js
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  server: {
    port: 3000,
  },
})
```
###  ディレクトリ構成例
```
my-project/
├─ index.html
├─ vite.config.js
├─ src/
│  ├─ main.jsx
│  └─ App.jsx
├─ public/
```

### Vite vs Webpack 比較
| 比較項目             | Vite                          | Webpack                          |
|----------------------|-------------------------------|----------------------------------|
| 起動速度             | ◎（即時）                     | △（初回バンドルが重い）         |
| HMR速度              | ◎（部分更新）                 | △（全体再バンドルの可能性）     |
| 設定の簡単さ         | ◎（デフォルトで十分）         | △（複雑になりやすい）           |
| プラグイン数         | ○（必要十分）                 | ◎（豊富）                        |
| プロダクションビルド | ◎（Rollupベース）             | ◎（最適化可能）                 |

### まとめ
- Vite は現代的で超高速な開発体験を提供するビルドツール
- Vue / React / Svelte など幅広く対応
- 開発サーバーは爆速、設定もシンプル
- 初学者からプロフェッショナルまでおすすめの選択肢！



## XXS
**XSS（Cross-Site Scripting）** とは、  Webサイトに **悪意のあるスクリプトを注入し、ユーザーのブラウザ上で実行させる攻撃** のことです。

### どんな攻撃なの？
- 攻撃者が Webサイトに **JavaScript などのスクリプトを埋め込む**
- そのページを閲覧した **他のユーザーのブラウザでスクリプトが実行される**
- 結果、以下のような被害が発生：

### 例：
- クッキーやセッションIDの盗難
- 偽の入力フォーム表示（フィッシング）
- 勝手なページ遷移やAPI実行
- キーロガーの仕込み

### XSSの主な種類
| 種類             | 説明 |
|------------------|------|
| **反射型（Reflected）**   | ユーザーからの入力がそのままレスポンスに反映されるタイプ（例：URLにスクリプト） |
| **保存型（Stored）**      | スクリプトがDBなどに保存され、後で他のユーザーに表示されるタイプ |
| **DOMベース型**           | フロントエンドのJavaScriptが、ユーザー入力を元に動的にDOM操作し、XSSを起こすタイプ |

### 攻撃の例（反射型）
```html
<!-- 悪意あるURL -->
https://example.com/search?q=<script>alert('XSS')</script>

<!-- サーバーがそのまま表示 -->
検索結果：<script>alert('XSS')</script>
```
→ ユーザーのブラウザで alert が実行される

### 対策方法
| 対策                         | 内容                                                                 |
|------------------------------|----------------------------------------------------------------------|
| **エスケープ処理**           | HTMLに出力する際は `&`, `<`, `>` などの文字を安全な形に変換する       |
| **Content Security Policy**  | 不正なスクリプトの読み込みや実行を制限するHTTPヘッダーを設定する       |
| **入力のバリデーション**     | ユーザーの入力内容を事前にチェックし、不正な形式を弾く                |
| **HTTPOnly属性のCookie**     | JavaScriptからクッキーを読み取れないようにする                         |
| **ライブラリやフレームワークの利用** | ReactやVueなどはデフォルトでXSSに強い設計になっている                 |

### フレームワーク別の対応
- **React**  
  JSXでは `{{ }}` による出力が自動でHTMLエスケープされる  
  ※ `dangerouslySetInnerHTML` を使うとXSSのリスクがあるため注意

- **Vue.js**  
  `{{ variable }}` は自動的にエスケープされる（v-html を使うときは注意）

- **Django / Rails / Laravel**  
  いずれもテンプレートエンジンが標準で出力をエスケープしてくれる

### まとめ
- **XSSは非常に危険な攻撃手法**。  
  ユーザーの情報を盗む、画面を偽装する、操作を乗っ取るなどの被害が発生する可能性がある。

- 特に **ユーザーの入力を画面に表示する機能** は要注意！

- 適切な **エスケープ処理** や **セキュリティヘッダー（CSPなど）** を活用し、  
  **安全なWebアプリケーション開発を心がけよう！**



## MSAL
**MSAL（Microsoft Authentication Library）** は、  Microsoft が提供する **認証・認可ライブラリ** で、Azure AD や Microsoft アカウントを使った **シングルサインオン（SSO）** や **トークン取得**を簡単に実装できます。

### MSALの主な用途
- Azure Active Directory（Azure AD）へのログイン
- Microsoft 365 API（Graph APIなど）へのアクセス
- OAuth 2.0 / OpenID Connect によるトークン取得と管理
- シングルサインオン（SSO）の実現

### サポートされているプラットフォーム
MSAL は以下のプラットフォーム向けに公式ライブラリが提供されています：
| プラットフォーム     | ライブラリ名             |
|----------------------|--------------------------|
| JavaScript / TypeScript | `msal.js` / `@azure/msal-browser` |
| .NET（C#）           | `Microsoft.Identity.Client` |
| Python               | `msal`（pipでインストール） |
| Java / Android       | `msal4j` / `msal-android` |
| iOS (Swift)          | `MSAL`                   |

### 基本的な処理の流れ
1. ユーザーがログインを試みる
2. MSALがAzure AD（IdP）にリダイレクト
3. 認証成功後、アクセストークンを取得
4. トークンを使ってAPI（Microsoft Graphなど）にアクセス

### JavaScript版（msal-browser）の使用例
### インストール
```bash
npm install @azure/msal-browser
import { PublicClientApplication } from "@azure/msal-browser";

const msalConfig = {
  auth: {
    clientId: "YOUR_CLIENT_ID",
    authority: "https://login.microsoftonline.com/common",
    redirectUri: "http://localhost:3000"
  }
};

const msalInstance = new PublicClientApplication(msalConfig);

// ログイン
msalInstance.loginPopup().then((response) => {
  console.log("Access Token:", response.accessToken);
});
```

### 取得できるトークンの種類
| トークン種類         | 説明                                               |
|----------------------|----------------------------------------------------|
| **IDトークン**        | 認証情報を含むトークン（ユーザー名やメールアドレスなど） |
| **アクセストークン**  | APIへのアクセスに使用されるトークン（Graph APIなど）     |
| **リフレッシュトークン** | トークンの再取得に使用（通常はMSALが自動管理）           |

### MSALと旧ライブラリ（ADAL）の違い
| 項目                 | ADAL                                 | MSAL                                  |
|----------------------|--------------------------------------|----------------------------------------|
| **サポート状況**     | 2022年6月にサポート終了              | 現在も Microsoft が積極的に開発中      |
| **対応プロトコル**   | Azure AD 独自                        | OAuth 2.0 / OpenID Connect に準拠     |
| **マルチテナント対応** | △                                    | ◎                                      |
| **取得できるトークン** | アクセストークンのみ                  | アクセストークン + IDトークン          |

### まとめ
- **MSALはMicrosoft公式の認証・認可ライブラリ**
- **OAuth 2.0 / OpenID Connect に準拠**し、セキュアで拡張性が高い
- Microsoft 365 や Azure AD を使ったログイン・APIアクセスに最適
- 旧ADALの後継として、**今後の標準的ライブラリ**として推奨されている



## SSO
**SSO（Single Sign-On／シングルサインオン）** とは、  **1度のログインで複数のシステムやサービスにアクセスできる仕組み**のことです。

### どういうときに使われる？
- 複数の社内業務システムを、1つのIDとパスワードで使いたいとき
- Microsoft 365 や Google Workspace にログインすれば、他のサービスも使えるようにしたいとき
- ユーザーの利便性やセキュリティを向上させたいとき

### 具体的なイメージ
- 朝1回、社内ポータルにログインするだけで…
  - 勤怠管理システム
  - チャットツール（Teams, Slackなど）
  - ファイル共有サービス（Box, Google Driveなど）  
  → すべて追加のログインなしで使える！

### SSOを実現する技術
| 技術               | 説明 |
|--------------------|------|
| **SAML**           | XMLベースの認証プロトコル。主に企業のWebアプリ向け |
| **OpenID Connect** | OAuth2の拡張仕様。Webやモバイルで広く使われる |
| **LDAP / Active Directory** | Windows系システムとの連携で使われる           |

### 認証の流れ（SAMLやOpenID Connectの場合）
1. ユーザーがサービス（SP）にアクセス
2. サービスが「この人誰？」とIdP（認証サーバー）にリダイレクト
3. ユーザーがIdPでログイン
4. IdPがユーザー情報を返す（SAMLアサーションやIDトークン）
5. サービスはログイン済みとして処理し、アクセスを許可

### SSOのメリット
| 項目               | 内容 |
|--------------------|------|
| **ユーザー体験向上** | 毎回ログイン不要で快適な操作が可能 |
| **セキュリティ強化** | パスワードの使い回しが減る。多要素認証も集中管理できる |
| **管理の効率化**     | アカウント情報を一元管理でき、退職時の権限削除も簡単 |

### SSOの注意点・デメリット
| 項目                 | 内容 |
|----------------------|------|
| **IdPが単一障害点になる** | 認証サーバーが落ちるとすべてのサービスに入れなくなる |
| **初期設定が複雑**       | SAMLやOIDCの設定・証明書など技術的な知識が必要 |
| **セッションハイジャック対策** | クッキー管理やタイムアウト設定が重要 |

### よく使われるSSOサービス（IdP）
| サービス名      | 特徴                         |
|-----------------|------------------------------|
| Azure AD        | Microsoft製。MS365との相性◎  |
| Google Workspace | Googleアカウント連携が可能   |
| Okta            | ID管理に特化したクラウド型IdP |
| Auth0           | 開発者向けの柔軟な認証サービス |

### まとめ
- **SSOは1度のログインで複数サービスにアクセス可能にする仕組み**
- **利便性とセキュリティを両立**できるため、企業・教育・医療など広く導入されている
- 実現には SAML や OpenID Connect などの認証技術が使われる



## Cookie
**Cookie（クッキー）** とは、  Webサイトが **ユーザーのブラウザに一時的なデータを保存する仕組み**です。  セッション管理やユーザー追跡、カート情報の保持などに使われます。

### Cookieの用途
| 用途                   | 説明                                         |
|------------------------|----------------------------------------------|
| **セッション管理**       | ログイン状態の保持、セッションIDの保存など         |
| **パーソナライズ**       | ユーザー名や言語設定の保存                        |
| **トラッキング / 分析** | アクセス解析や広告表示のためのユーザー識別         |
| **ショッピングカート**   | カートに入れた商品情報の一時保持                    |

### Cookieの基本構造（HTTPヘッダー）
```http
Set-Cookie: name=value; Expires=Fri, 01 Jan 2027 00:00:00 GMT; Path=/; HttpOnly; Secure; SameSite=Lax
```

### Cookieの主な属性
| 属性名             | 説明                                                                 |
|--------------------|----------------------------------------------------------------------|
| `name=value`       | 保存するキーと値のペア（例：`sessionId=abc123`）                     |
| `Expires` / `Max-Age` | 有効期限の指定。省略すると「セッションクッキー」になります        |
| `Path`             | クッキーが送信されるパス。指定されたパス以下にのみ送信される        |
| `HttpOnly`         | JavaScriptからのアクセスを禁止。セキュリティ強化に有効               |
| `Secure`           | HTTPS通信時のみ送信される                                            |
| `SameSite`         | 他サイトからのリクエストでクッキーが送信されるかを制御              |

### Cookieの種類
| 種類                   | 説明                                                               |
|------------------------|--------------------------------------------------------------------|
| **セッションクッキー**   | ブラウザを閉じると消える。一時的なデータ保存に使用                 |
| **永続クッキー**         | 有効期限を持ち、ブラウザを閉じても残る                             |
| **サードパーティクッキー** | 閲覧中のサイトとは別ドメインが発行。広告・トラッキングなどの用途に使用 |

### JavaScriptでの操作例
```javascript
// クッキーの設定
document.cookie = "username=John; path=/; max-age=3600";

// クッキーの取得
console.log(document.cookie); // username=John
```

### セキュリティのポイント
| 対策項目         | 説明                                                                 |
|------------------|----------------------------------------------------------------------|
| **HttpOnly属性** | JavaScriptからアクセスできなくなるため、XSS対策に有効               |
| **Secure属性**   | HTTPS通信時のみ送信されるため、中間者攻撃（MITM）対策になる         |
| **SameSite属性** | CSRF対策として、外部サイトからのリクエストでの送信を制限できる      |

### Cookieと他のストレージとの違い
| ストレージ種類     | 保存場所               | 容量制限 | 有効期限                    | サーバーへ送信     |
|--------------------|------------------------|----------|-----------------------------|---------------------|
| **Cookie**          | サーバー + ブラウザ     | 約4KB     | 任意（指定可能）            | :o: 自動で送信される  |
| **LocalStorage**    | ブラウザ                | 約5MB     | 明示的に削除しない限り保持  | :heavy_multiplication_x: 送信されない      |
| **SessionStorage**  | ブラウザ（タブ単位）    | 約5MB     | タブを閉じると削除される     | :heavy_multiplication_x: 送信されない      |

### まとめ
- **Cookieは Webとユーザー間の状態を保持する仕組み**
- セッション管理やログイン状態の維持に欠かせない重要な技術
- セキュリティ属性（`HttpOnly` / `Secure` / `SameSite`）を正しく使って  
  **安全に運用することが非常に重要！**



## Azure B2C
**Azure Active Directory B2C（Azure AD B2C）** は、  Microsoftが提供する **エンドユーザー向けのクラウド認証基盤**です。  Webアプリやモバイルアプリに対して、**ユーザー登録・ログイン・認可機能**を簡単に組み込むことができます。

### 主な特徴
| 特徴                        | 内容 |
|-----------------------------|------|
| **エンドユーザー認証に特化** | 一般消費者（顧客）向けの認証システムを提供 |
| **SNSログイン対応**         | Google / Facebook / Microsoftアカウントなどと連携可能 |
| **多要素認証（MFA）**       | SMS・メールなどで2段階認証を実装可能 |
| **カスタマイズ可能なUI**    | ログイン・登録画面のデザインを自由に変更可能 |
| **スケーラブル＆セキュア**  | Microsoft Azureのスケーラビリティとセキュリティを活用 |

### ユースケース例
- 会員制ECサイトのログイン機能
- スマホアプリのユーザー登録と認証
- 複数アプリに共通するログイン基盤の構築（SSO）
- 外部サービス連携（Googleログインなど）を簡単に導入

### 対応している認証プロトコル
| プロトコル         | 説明 |
|--------------------|------|
| **OpenID Connect** | OAuth2ベースの標準的な認証プロトコル。IDトークンを取得可能 |
| **OAuth 2.0**      | アクセストークンを使ってAPIアクセスの認可を行う |
| **SAML 2.0**       | 企業間連携などでよく使われるXMLベースの認証プロトコル |

### Azure AD（企業向け）との違い
| 比較項目         | Azure AD                        | Azure AD B2C                             |
|------------------|----------------------------------|------------------------------------------|
| **対象ユーザー** | 従業員・内部ユーザー向け         | 一般顧客・外部ユーザー向け               |
| **ログイン方法** | 会社のメールアドレス＋認証       | SNS / メール / 電話番号など柔軟に対応    |
| **UIカスタマイズ性** | △（ほぼ変更不可）             | ◎（HTML / CSSで自由にデザイン可）        |
| **多言語対応**   | 一部対応                         | ◎（多言語UI切り替え可能）                |

### まとめ
- **Azure AD B2Cは、エンドユーザー向けのIDaaS（Identity as a Service）**
- SNS認証・メール認証・パスワードレス・多要素認証など、柔軟な認証方式に対応
- **ログイン・登録画面のUIカスタマイズが可能**で、ブランド統一もしやすい
- **OAuth2 / OpenID Connect / SAML** に対応し、業界標準プロトコルに準拠
- 顧客向けWeb・モバイルアプリに最適な認証基盤



## Azure AD認証
**Azure Active Directory（Azure AD）** は、Microsoft が提供する **クラウドベースのIDおよびアクセス管理サービス**です。  ユーザーの認証やアプリケーションへのアクセス制御を一元的に行うことができます。

### Azure AD 認証の主な用途
- Microsoft 365 や Azure ポータルへのログイン
- 社内 Web アプリやモバイルアプリへのシングルサインオン（SSO）
- Microsoft Graph API を使ったユーザー/デバイス管理
- オンプレミスADとの連携（ハイブリッド環境）

### 対象ユーザー

Azre AD は **企業や組織の従業員・内部ユーザー**を対象とした認証サービスです。  
一般顧客向けには別サービスの [Azure AD B2C](https://learn.microsoft.com/ja-jp/azure/active-directory-b2c/) を使用します。

### 対応プロトコル
| プロトコル         | 用途                                         |
|--------------------|----------------------------------------------|
| OAuth 2.0          | 認可（APIアクセス制御）                      |
| OpenID Connect     | 認証（ログイン）                             |
| SAML 2.0           | エンタープライズ向けSSO                      |
| WS-Federation      | レガシーシステムとの連携に使用されることがある |

### 認証の基本フロー（OpenID Connect）
1. ユーザーがアプリケーションにアクセス  
2. Azure AD にリダイレクトされログイン  
3. ログイン成功後、IDトークンが発行される  
4. アプリ側がトークンを検証し、ユーザーを認証  
5. アクセストークンを使って API にアクセスも可能

### セキュリティ機能
| 機能                 | 説明                                           |
|----------------------|------------------------------------------------|
| 多要素認証（MFA）     | SMS や 認証アプリによる 2 段階認証             |
| 条件付きアクセス     | ロールや場所・デバイスに応じたアクセス制御     |
| セッション管理       | タイムアウト・再認証・トークン有効期限の設定など |

### Azure AD 認証のメリット
- Microsoft 製品との連携が強力（Microsoft 365、Teams、SharePointなど）
- 業界標準プロトコルに対応しており、幅広いアプリと統合可能
- セキュリティ機能が豊富で、ゼロトラスト環境にも対応
- アカウント・アクセス管理を一元化し、運用負荷を削減できる

### Azure AD vs Azure AD B2C
| 比較項目         | Azure AD                         | Azure AD B2C                           |
|------------------|----------------------------------|----------------------------------------|
| 対象ユーザー     | 社内ユーザー・従業員向け         | 顧客・外部ユーザー向け                 |
| ログイン手段     | 職場アカウント（メール + パスワード） | SNS / メール / 電話番号など柔軟に対応 |
| UIカスタマイズ性 | ほぼ不可                         | HTML / CSS で自由にカスタマイズ可能   |

### まとめ
- **Azure AD 認証は、企業向けのID管理・認証基盤として広く利用されている**
- **SSO・MFA・条件付きアクセス**など、セキュリティ対策も充実
- Microsoft製品だけでなく、自社アプリやクラウドサービスとの統合も簡単
- 業界標準のプロトコルに対応しており、将来的な拡張性も高い