はじめに

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

単語一覧

JWT証
CORS
CSRF
ポーリング
SMAL認証
OWIN
ISS
vite
XXS
MSAL
SSO
Cookie
Azure B2C
Azure AD認証

JWT認証

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

JWTの基本構造

WTは、3つの部分からなる文字列です。ドット (.) で区切られています：

<ヘッダー>.<ペイロード>.<署名>

例えば：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VySWQiOjEyMywiaXNBZG1pbiI6dHJ1ZX0.
sflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

各部分の意味

部分	内容
ヘッダー	どんな署名アルゴリズムが使われているか（例：HS256）など
ペイロード	認証されたユーザーの情報（例：ユーザーIDや権限など）
署名	トークンの改ざんを防ぐために、秘密鍵を使って生成された署名

JWT認証の流れ

ログイン時にJWTを発行
- ユーザーがログイン成功後、サーバーはJWTを生成してクライアントに返します。
クライアントがトークンを保存
- 通常、ブラウザでは localStorage や sessionStorage に保存されます。
APIリクエスト時にトークンを送信
- クライアントは、APIにアクセスする際に Authorization ヘッダーにトークンを付けて送信します。

Authorization: Bearer <JWT>

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

JWTのメリット

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

注意点

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

CORS

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

「オリジン」とは？

オリジンは以下の3つの組み合わせで構成されます：

スキーム（例：http や https）
ドメイン（例：example.com）
ポート番号（例：:3000）

たとえば：

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

なぜ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に勝手に投稿される
メールアドレスが変更される
ユーザー削除や購入処理が実行される

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

攻撃の仕組み（ざっくり）

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

防ぐには？

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

補足情報

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

ポーリング

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

たとえば何に使うの？

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

仕組み（ざっくり）

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

メリット

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

デメリット

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

コード例（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アプリなど

認証の流れ（ざっくり）

ユーザーが SP（アプリ）にアクセス
SP は「このユーザー誰？」と IdP にリダイレクト
ユーザーは IdP でログイン
IdP は「この人は○○さんです」と SAMLレスポンス（署名付き）を SP に返す
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の流れ（ざっくり）

WebサーバーがHTTPリクエストを受け取る
OWINインターフェースを通してアプリに渡す
アプリは一連のミドルウェアを順に処理
最終的にレスポンスを返す

最小構成のサンプル（C#）

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）の一部例です：

{
  "iss": "https://auth.example.com/",
  "sub": "user123",
  "aud": "myapp",
  "exp": 1710000000
}

"iss"：トークンを発行した Issuer
"sub"：トークンの対象（Subject）
"aud"：トークンの受け手（Audience）

なぜ重要？

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

アプリ側での検証処理（擬似コード）

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 を使う場合：

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（一例）

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を起こすタイプ

攻撃の例（反射型）

<!-- 悪意ある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`

基本的な処理の流れ

ユーザーがログインを試みる
MSALがAzure AD（IdP）にリダイレクト
認証成功後、アクセストークンを取得
トークンを使ってAPI（Microsoft Graphなど）にアクセス

JavaScript版（msal-browser）の使用例

インストール

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の場合）

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

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ヘッダー）

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での操作例

// クッキーの設定
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	任意（指定可能）	自動で送信される
LocalStorage	ブラウザ	約5MB	明示的に削除しない限り保持	送信されない
SessionStorage	ブラウザ（タブ単位）	約5MB	タブを閉じると削除される	送信されない

まとめ

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 を使用します。

対応プロトコル

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

認証の基本フロー（OpenID Connect）

ユーザーがアプリケーションにアクセス
Azure AD にリダイレクトされログイン
ログイン成功後、IDトークンが発行される
アプリ側がトークンを検証し、ユーザーを認証
アクセストークンを使って 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製品だけでなく、自社アプリやクラウドサービスとの統合も簡単
業界標準のプロトコルに対応しており、将来的な拡張性も高い