0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@1985-0705

API認証方式の完全リスト：Basic認証からOAuth2、JWTまで

0
Posted at

みなさん、こんにちは！日々の開発お疲れ様です。
新しいAPIを作っているとき、エンドポイントの実装に夢中になって「認証（Authentication）は後回しでいいか」なんて思ったことはありませんか？実は、かつての私もそうでした。でも、セキュリティを疎かにするのは、実はとんでもなく恐ろしいことなんです。

今回は、API認証の基本から応用まで、まるで「家の鍵」を選ぶような感覚で楽しく学べる完全ガイドをまとめました。これを読めば、あなたのAPIを「ハッカーたちの無料ビュッフェ」にせずに済みますよ！

想像してみてください。毎朝、家の玄関を全開にしたまま外出して、ドアには「Wi-Fi無料、お菓子も無料、防犯カメラなし！」という大きなネオンサインを掲げている自分を。

……ありえないですよね？

でも、適切な認証を実装せずにAPIを公開するのは、まさにこれと同じことをしているんです。

APIは、ユーザーのプロフィール、請求情報、製作中の猫ミームなど、アプリにとって最も大切なデータへの「玄関口」です。そして悲しいかな、インターネットという巨大なデジタル近所には、犬の散歩をしている善良な人ばかりではありません。

適切な錠前（ロック）、鍵（キー）、そして身分証明のチェックがなければ、あなたのAPIはボットや悪意のある攻撃者、あるいは「間違えて」本番環境にステージング用のトークンを投げ込んでしまう同僚たちのための食べ放題ビュッフェになってしまいます。

そこでこのガイドでは、複雑なAPI認証の世界を分かりやすく解き明かしていきます。

Basic認証のようなシンプルな「身分証提示」スタイルから、AWS Signature V4のような暗号化署名まで。
何を、いつ使うべきか、そして最も重要な「どうすればAPIをハッカーの餌食にせずに済むか」を、私と一緒に見ていきましょう。

さあ、あなたのAPIを「鉄壁の要塞」にする準備はいいですか？
1112.png

API認証の世界

✅ 1. モダン派：現代の標準メソッド (今どきの開発ならこれ)

認証方式 いつ使う？ ひとことで言うと？
Bearer Token ログイン済みユーザー、OAuth 2アクセストークン ジムの会員証。提示するだけで中に入れる
JWT Bearer SSO（シングルサインオン）、マイクロサービス スマートな身分証。名前や写真、誕生日情報が内蔵されている
OAuth 2.0 サードパーティログイン（GitHub, Googleなど） 用心棒があなたの金持ちの友人（Google）に「こいつ、通していいか？」と確認する仕組み

🛠 2. 古典派：「古き良き」レガシー認証 (内部ツールや、急ぎのMVP開発向け)

認証方式 いつ使う？ ひとことで言うと？
Basic Auth 内部ツール、自動化スクリプト 「502号室のジョンです」と名乗るだけ。認証情報をBase64で送る（暗号化ではない）
Digest Auth 古いシステム、簡易的なセキュリティ ボイスチェンジャー越しにパスワードをささやくようなもの
API Key 公開API、利用制限のトラッキング ホテルのカードキー。コピーされやすいが、役割は果たす

🧷 3. 鉄壁派：署名と封印のセキュリティ (金融系や、セキュリティ重視の場合)

認証方式 いつ使う？ ひとことで言うと？
OAuth 1.0 Twitter v1、レガシーAPI 署名、タイムスタンプ、ナンス……官僚的な手続きが詰まった厳重な書類
Hawk 安全なREST間の通信 全ての荷物に署名をして、改ざんされていないことを証明する仕組み
AWS Signature AWSサービス（S3, Lambdaなど）の呼び出し 秘密の解読リング、タイムスタンプの魔法、AWSの魔術が必要
Akamai EdgeGrid Akamaiの要塞の背後にあるAPI CDNの鉄の門。聖なる巻物（署名付きヘッダー）なしでは通れない

🧩 4. 組織内：独自およびエンタープライズ認証 (企業向け設定やWindows懐古主義)

認証方式 いつ使う？ ひとことで言うと？
NTLM認証 イントラネット、Windows企業ネットワーク 社員証をスワイプして、受付（Active Directory）に挨拶する感じ
ASAP (Atlassian) Jira, Confluence, AtlassianスタックのCI/CD Atlassian内部のVIPパス。JWTベースで高速

🧪 5. テストツール ＆ 開発ショートカット (トークンを100回打つのは嫌ですよね)

認証方式 いつ使う？ ひとことで言うと？
親から継承 APIコレクションのテスト モール全館共通のリストバンド。一度設定すれば、どのお店も入れる
No Auth 公開API、開発初期段階 「誰でも歓迎」。身分証は不要

認証方式ディープダイブ（例え話付き）

1. Basic Auth – 古典的なユーザー名とパスワード

例え: 警備員に「502号室のジョンです」と伝え、そのまま通してもらうようなものです。

主な特徴:

  • リクエストごとにユーザー名とパスワード（Base64エンコード）を送信
  • 非常にシンプルだが安全ではない。通信を傍受されると簡単に盗まれる
    いつ使うか: 信頼できる環境（内部ネットワークやテストなど）

📌 最適: 内部システム、小規模チーム用ツール
💡 リクエスト例:

GET /api/data HTTP/1.1  
Authorization: Basic am9objpwYXNzd29yZA==  # john:password をBase64化したもの

💻 Python例:

import requests
from requests.auth import HTTPBasicAuth

requests.get('https://api.example.com/data', auth=HTTPBasicAuth('john', 'password'))

2. Bearer Token – シンプルな通行証

例え: ジムの会員証を使うようなものです。名前までは確認されませんが、そのカードが有効かどうかだけを見られます。

主な特徴:

  • トークンがセッションを代表する
  • トークン自体にユーザー情報は含まれず、「許可されていること」だけを証明する
    いつ使うか: ログイン後、ユーザー固有のデータにアクセスする場合

📌 最適: ログイン後の認証済みAPIアクセス
💡 リクエスト例:

GET /api/profile HTTP/1.1  
Authorization: Bearer eyJhbGciOiJIUzI1NiIsIn...

JavaScript 例（フロントエンド）：

fetch('/api/profile', {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN_HERE'
  }
})

3. JWT Bearer – スマートな身分証明書

例え: 名前、写真、役職が記載されたIDカードのようなものです。単なるパスではなく、情報そのものを持ち歩きます。

主な特徴:

  • ユーザーデータを含む自己完結型トークン（JSON Web Token）
  • 毎回データベースに問い合わせる必要がない
    いつ使うか: マイクロサービス、SSO、ステートレスなアプリ

📌 最適: マイクロサービス、シングルサインオン
💡 トークンの中身（Payload）:

{
  "sub": "user123",
  "role": "admin",
  "exp": 1710000000
}

Node.js 例：

const jwt = require('jsonwebtoken');
const token = jwt.sign({ user: 'john' }, 'secret', { expiresIn: '1h' });

fetch('/api/data', {
  headers: {
    Authorization: `Bearer ${token}`
  }
});

4. API Key – ホテルのルームキー

例え: ホテルの部屋に入るために必要なカードキーです。

主な特徴:

  • 呼び出し元を特定するためのユニークな文字列
  • ヘッダー、クエリパラメータ、またはボディで渡される
    いつ使うか: 簡易的なアクセス制御や、利用料のトラッキング

📌 最適: 公開API、プラットフォームの利用統計
💡 ヘッダー例:

GET /api/news HTTP/1.1  
x-api-key: abc123456789

クエリストリング例：

GET /api/news?apikey=abc123456789

5. OAuth 2.0 – 標準的なサードパーティログイン

例え: Googleアカウントを使ってPayPalにログインするようなものです。Googleがあなたの身元を保証してくれます。

主な特徴:

  • ユーザーデータのアクセス権限を委譲するためのもの
  • 複数のフローをサポート（認証コード、パスワード、クライアント認証など）
    いつ使うか: ソーシャルログインや企業間連携

📌 最適: サードパーティ連携、権限委譲
💡 簡略化された認証コードフロー:

  1. ユーザーが認証ページにリダイレクトされる
  2. code（認可コード）を取得する
  3. サーバーがcodeをアクセストークンと交換する：
POST https://oauth.example.com/token  
Content-Type: application/x-www-form-urlencoded  

grant_type=authorization_code&code=abc123&client_id=xxx&client_secret=yyy

6. OAuth 1.0 – オールドスクールな方法

例え: 個人の署名に加えて「会社の印鑑」も必要な、整合性を重視した厳格な手続きです。

主な特徴:

  • リクエストに署名（Signature）が必要
  • 安全だが実装が複雑
    いつ使うか: APIがOAuth 1.0しかサポートしていない場合（例：Twitterの古いAPI）

📌 最適: TwitterなどのレガシーAPI

認可ヘッダー：

Authorization: OAuth oauth_consumer_key="key",
                      oauth_nonce="random",
                      oauth_signature="hmac_sha1",
                      ...

Python 例：

from requests_oauthlib import OAuth1

auth = OAuth1('YOUR_KEY', 'YOUR_SECRET', ...)
requests.get('https://api.twitter.com/1.1/statuses/home_timeline.json', auth=auth)

7. Digest Auth – 難読化されたパスワード

例え: ID番号をボイスチェンジャーを通して伝えるようなものです。大声で叫ぶ（Basic認証）よりは安全です。

主な特徴:

  • Basic認証より安全（ソルトとハッシュ化を使用）
  • 互換性の問題が起こりやすい
    いつ使うか: ユーザー名とパスワードが必要だが、少しでも安全性を高めたいレガシーシステム

Python 例：

from requests.auth import HTTPDigestAuth
requests.get('https://example.com/api', auth=HTTPDigestAuth('user', 'pass'))

8. Hawk – 署名付きの配達物

例え: 荷物の中身を含めて、受取時に署名をするようなものです。途中で中身がすり替えられていないことを保証します。

主な特徴:

  • HMAC署名でリクエストの整合性を守る
  • パスワードが露出することはない
    いつ使うか: サービス間通信でメッセージの完全性が必要な場合

Node.js 例：

const hawk = require('@hapi/hawk');

const credentials = {
  id: 'user-id',
  key: 'secret-key',
  algorithm: 'sha256'
};

const { header } = hawk.client.header('https://api.example.com/resource', 'GET', { credentials });

fetch('https://api.example.com/resource', {
  headers: { Authorization: header }
});

9. AWS Signature – Amazon公式フォーマット

例え: AWS本社を訪問するなら、彼らの「公式招待状フォーマット」に従う必要があります。

主な特徴:

  • 厳密にフォーマットされた署名（タイムスタンプ、ヘッダー、リージョンなどを含む）
  • AWSサービスの利用には必須
    いつ使うか: S3やLambdaなどのAWS APIを叩くとき

Python 例：

import boto3

s3 = boto3.client('s3', aws_access_key_id='AKIA...', aws_secret_access_key='...')
s3.list_buckets()

10. NTLM Authentication – Windows内部の社員証

例え: オフィスのゲートで社員証をスワイプするようなものです。内部ネットワーク専用です。

主な特徴:

  • Windowsドメイン認証
  • 古い社内システムでよく使われる
    いつ使うか: Microsoft環境の企業向けアプリ

Python 例：

from requests_ntlm import HttpNtlmAuth
requests.get("http://windows-server.local", auth=HttpNtlmAuth('DOMAIN\\user', 'password'))

11. Akamai EdgeGrid – 大規模な門番

例え: 空港の保安検査場を通る際、パスが彼らの厳格なフォーマットと一致しなければならないようなものです。

主な特徴:

  • Akamai特有の署名メカニズム
  • 大規模トラフィックを安全に処理するための設計

認可ヘッダー：

Authorization: EG1-HMAC-SHA256 client_token=xxx;access_token=yyy;timestamp=...;nonce=...

Node.js 例：

const edgegrid = require('akamai-edgegrid');

const eg = new edgegrid('client_token', 'client_secret', 'access_token', 'host');
eg.auth({
  path: '/endpoint',
  method: 'GET'
});

12. ASAP (Atlassian Service Auth Protocol) – 社内専用バッジ

例え: 社内の部署間を移動するとき、社員証があれば自動的にアクセスが許可される仕組みです。

主な特徴:

  • AtlassianのJWTベースのサービス間認証
  • 秘密鍵による署名
    いつ使うか: Atlassianエコシステム内やマイクロサービス間の通信

認可例：

Authorization: Bearer eyJraWQiOiJhc2FwS2V5IiwidHlwIjoiSldUI...

13. Inherit from Parent – 一括管理のパス

例え: モールの入り口で一度パスをもらえば、中のショップは再チェックなしで入れる仕組みです。

主な特徴:

  • 子リクエストが親の設定から認証を引き継ぐ
    いつ使うか: EchoAPIのようなツールで、共通の認証を持つ多くのエンドポイントをテストするとき

📌 最適: APIテストツール（EchoAPIのコレクションなど）

14. No Auth – 誰でも歓迎

例え: 公園のようなものです。チケットも身分証もいりません。

主な特徴:

  • 認証不要
    いつ使うか: 公開データ、開発中のスタブ、ヘルスチェック用エンドポイント

🎁 おまけ：泣かずにデバッグする方法は？ EchoAPIを試してみて

トークン、ヘッダー、謎の署名……これらを管理するのに疲れ果てていませんか？
私がお勧めするのは EchoAPI です。これを使うと、APIのデバッグが「500行のcurlスクリプトを書く苦行」から「コーヒーを片手に楽しむ作業」に変わります。

現場で使える: GitHub連携から社内のレガシーな通信まで、EchoAPIなら何でもござれ。
一元テスト: BearerからAWS Signatureまで、一つの場所ですべてテスト可能。
エンタープライズ対応: NTLMからAkamai EdgeGridまで、大企業の仕様もしっかりカバー。
爆速デバッグ: ログイン、認証フロー、サービス呼び出しをシミュレート。もう手動でヘッダーをコピペする地獄には戻れません。

ふぅ、お疲れ様でした！一気に紹介しましたが、いかがでしたか？
「自分のプロジェクトにはどれが合うんだろう？」と迷ったら、まずは使い勝手の良いBearer TokenやJWTから検討してみるのがお勧めです。

認証の設定は少し手間がかかりますが、一度しっかり作ってしまえば、夜も安心して眠れますからね（これ、エンジニアにとって一番大事なことですよね！）。

もし「この認証方式の実装で詰まってるんだよね……」という悩みがあれば、いつでも私に相談してください。一緒に解決策を考えましょう！

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?