API認証入門 Basic・APIキー・Bearer・JWT・OAuthの違い

はじめに

APIの説明を読むと、Basic認証、APIキー、Bearerトークン、JWT、OAuthといった言葉が出てきます。

名前を並べると「この中から認証方式を1つ選ぶのかな」と思うかもしれません。ところが、 これらは同じ種類の選択肢ではありません。 資格情報の送り方、データ形式、権限を渡す仕組みが混ざっています。

この記事では、まず「APIとは何か」から始めます。そのうえで、予定表を取得する架空のアプリを例に、認証・認可と各用語の関係を整理します。実装経験がなくても読み進められる内容を目指します。

HTTPの例は読み方を学ぶための概念例です。api.example.comなどは架空の接続先で、実際に予定表を取得できるAPIではありません。本番用の認証サーバーの実装は扱いません。

1. APIとは「プログラムから使うための窓口」

APIは Application Programming Interface の略です。簡単にいうと、あるプログラムの機能やデータを、別のプログラムから使うための取り決めです。

人がアプリを操作するときは、画面のボタンを押します。一方、プログラム同士では「この形式で依頼すると、この形式で結果が返る」という窓口を使います。その窓口がAPIです。

たとえば、予定表アプリには「自分の予定一覧を取得するAPI」があると考えてみてください。

• リクエスト ：呼び出す側から送る依頼。
• レスポンス ：API側から返ってくる応答。
• クライアント ：APIを呼び出す側。この例では予定を表示するアプリ。
• サーバー ：依頼を受け付け、処理して応答する側。

APIにはさまざまな種類があります。この記事で扱うのは、ネットワーク越しにHTTPで呼び出す Web API です。APIすべてがWeb APIというわけではありません。

出典：MDN：Introduction to web APIs。窓口・予定表の例は理解を助けるための筆者の例です。

リクエストは「どこへ・何を・どんな条件で」のセット

HTTPは、リクエストとレスポンスをやり取りするための通信上の取り決めです。HTTPSは、そのHTTP通信をTLSという仕組みで保護します。

予定一覧を取得するリクエストを、HTTP/1.1の形で単純化すると次のようになります。

予定一覧を取得するリクエストの概念例

GET /v1/events HTTP/1.1
Host: api.example.com
Accept: application/json

部分	意味	この例
URL	呼び出す先の住所	https://api.example.com/v1/events
メソッド	依頼する操作の種類	GETは取得。新規登録などにはPOSTが使われる
ヘッダー	依頼に添える情報	Acceptは受け取りたいデータ形式を伝える
ボディ	送るデータ本体	予定を新規登録するときの日時や件名など。このGET例にはない

APIの個々の呼び出し先を エンドポイント と呼びます。たとえばGET /v1/eventsは、予定一覧を取得するエンドポイントという説明になります。

この例で返ってくるデータは、次のようなJSONを想定しています。JSONは、名前と値を組み合わせてデータを表す形式です。

予定一覧のレスポンスボディ例

{
  "events": [
    {
      "id": "event-001",
      "title": "チーム定例"
    }
  ]
}

実際のレスポンスには、このデータに加えて、200 OKなどの処理結果を示す ステータスコード やヘッダーがあります。JSON以外の形式を返すAPIもあります。

出典：MDN：HTTP messages、OWASP：REST Security Cheat Sheet — HTTPS。表と予定表APIは筆者の概念例です。

2. API認証は「誰からの依頼か」を確認すること

先ほどのAPIに、誰でも自由にアクセスできたらどうなるでしょうか。

公開情報なら問題ない場合もありますが、個人の予定表を誰にでも返すわけにはいきません。そこで、APIにアクセスしてきた相手を確認します。

API認証は、リクエストに添えられた資格情報などを使って、利用者や呼び出し元を確認する仕組みです。 資格情報とは、パスワードやトークンなど、アクセス時の確認材料となる情報を指します。

方式によって確認できる対象は異なります。「このアプリに発行したキーを持っている」と分かることと、「操作している人が社員A本人である」と分かることは、同じではありません。

認証と認可は別の確認

OWASPのAuthorization Cheat Sheetの区別を、社内システムの例に置き換えると次のようになります。

用語	確認すること	社内システムでの例
認証：Authentication	あなたは誰か	社員Aのアカウントとして本人確認する
認可：Authorization	何をしてよいか	社員Aは自分の勤怠を見られるが、他人の給与は見られない

つまり、 ログインできたことと、すべてのデータにアクセスできることは別です。

API側では、資格情報が有効かに加えて、「この人に、このデータを、この操作で扱わせてよいか」を確認します。たとえばURL中の社員IDを書き換えただけで、他人の勤怠を読めてはいけません。

権限確認は、画面のボタンを隠すだけでは不十分です。API側でもリクエストごとに確認します。

認証情報はどこに付けるのか

よく使われるのが、HTTPの Authorizationヘッダー です。

Authorizationヘッダーの形

Authorization: <方式名> <資格情報>

名前はAuthorizationですが、このヘッダーを付ければ認可まで完成するわけではありません。サーバーが値を検証し、権限を判断する処理が必要です。

次のBasicやBearerは、この<方式名>に入る名前です。APIキーは、サービス独自のヘッダーを使うこともあります。

出典：RFC 9110 §11.6.2：Authorization、OWASP：リクエストごとの権限確認。

3. Basic認証：ユーザー名とパスワードを送る

RFC 7617で定義されるBasic認証では、ユーザー名とパスワードを:でつなぎ、Base64という文字列の表現方法で変換して送ります。

Basic認証の組み立て方

ユーザー名:パスワード
        ↓ Base64に変換
Authorization: Basic 変換した文字列

たとえば、架空のユーザー名demoとパスワードexample-passwordなら、次のようになります。

Basic認証ヘッダーの例

Authorization: Basic ZGVtbzpleGFtcGxlLXBhc3N3b3Jk

保護されたAPIを呼び出すリクエストに、この資格情報を添えます。認証に成功しても、操作を許可するかどうかは別の判断です。

Base64は暗号化ではない

Base64は表現を変えているだけで、秘密にする仕組みではありません。 逆の変換をすれば、元の文字列に戻せます。

OpenSSLがあるmacOS・Linuxのターミナルなら、次の例を通信なしで試せます。実際のパスワードに置き換えず、架空の値のまま使ってください。

ターミナル

# 架空のユーザー名とパスワードをBase64に変換する
printf '%s' 'demo:example-password' | openssl base64 -A

# 同じ値を元の文字列に戻す
printf '%s' 'ZGVtbzpleGFtcGxlLXBhc3N3b3Jk' | openssl base64 -d -A

1つ目の結果はZGVtbzpleGFtcGxlLXBhc3N3b3Jk、2つ目はdemo:example-passwordです。末尾に改行は出ません。ファイルも作らないため、後片付けは不要です。

本当に秘密にしたいのは、変換後の文字列も含めた認証情報です。 Basic認証はHTTPSで使い、ヘッダーをログやGitへ残さない ようにします。

出典：RFC 7617 §4：Security Considerations。上の変換例は2026年9月19日にローカルで実行確認しています。

4. APIキー：API提供者から発行された文字列を送る

APIキーは、API提供者から発行される識別用・アクセス用の文字列です。利用者、アプリ、プロジェクトなどを識別し、利用状況やアクセスを管理するために使われます。

ヘッダーで送るサービスなら、たとえば次のような形です。

APIキーヘッダーの概念例

X-API-Key: <発行されたAPIキー>

X-API-Keyは一例です。APIキーに共通する単一の送信ルールがあるわけではなく、ヘッダー名、権限、期限、更新方法はサービスごとに異なります。

また、 APIキーを確認できても、操作中の人の本人確認までできたとは限りません。 アプリで1つのキーを共有していれば、そのキーだけでは利用者を区別できないためです。

秘密として扱うAPIキーは、パスワードと同じように保護します。ブラウザーへ配布するJavaScriptや公開リポジトリに埋め込まないでください。サービスが公開用として設計したキーとは、扱いを分けます。

出典：OWASP：REST Security Cheat Sheet — API Keys、Stripe：API keys（公開可能キーと秘密のキーを区別する例）。

AWS API Gatewayでは「使用量管理」と「アクセス制御」を分ける

ここはAWS固有の注意点です。Amazon API GatewayのREST API向け使用量プランに紐づくAPIキーは、 認証・認可によるアクセス制御の代わりに使わない ことが公式に案内されています。

アクセス制御には、IAM、Lambdaオーソライザー、Amazon Cognitoユーザープールなどを使います。

「APIキーを必須にした」と「利用者ごとの権限確認を実装した」は別です。この注意を、すべてのサービスのAPIキーが認証に使えない、という一般論に広げないことも大切です。

5. Bearerトークン：「持っていること」で使う資格情報

トークンは、アクセス時の確認に使うデータです。APIでは、発行された文字列として扱うことがよくあります。

Bearerトークンは、そのトークンを持つ相手が、トークンに対応する権限を使える性質の資格情報 です。使う際に、そのトークンとは別の暗号鍵を持っていることの証明を求めません。

HTTPでは、次のように送ります。

Bearerトークンを添えたリクエストの概念例

GET /v1/events HTTP/1.1
Host: api.example.com
Authorization: Bearer <アクセストークン>
Accept: application/json

アクセストークンは、保護されたAPIへアクセスするための資格情報です。Bearerは、その使い方を表します。

イメージは「持参した人が使える入場券」です。ただし、有効期限切れや対象外の会場なら使えません。API側でも、トークンの有効性、対象API、権限などを検証します。

そのため「Bearerと付ければどんな文字列でも通る」「トークンを持てば何でもできる」という意味ではありません。

漏えいすると、第三者が使えるおそれがあります。HTTPSに加えて、保存場所やログへの出力にも注意します。

出典：RFC 6750 §1.2・§2.1：Bearer Token／Authorization Request Header、RFC 6749 §1.4：Access Token。入場券は筆者のたとえです。

6. JWT：「トークンに情報を入れる形式」

JWTは JSON Web Token の略です。RFC 7519で定義される、情報をJSONとして表現し、やり取りするための形式です。

JWTに入る個々の情報を クレーム（claim） と呼びます。苦情という意味ではなく、「誰についての情報か」「いつまで有効か」といった項目です。

よく見かける署名付きJWTは3つの部分に分かれる

一般的な署名付きJWTを文字列で表すと、.で区切られた次の形になります。

署名付きJWTの構造

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

部分	入っているもの
ヘッダー	署名に使うアルゴリズムなど
ペイロード	対象者、有効期限、利用先などの情報
署名部分	内容の改ざんなどを検出するための値

厳密には、改ざん検知にデジタル署名またはMAC（共有鍵を使う認証用の値）を使います。また、JWTには暗号化する形式もあり、すべてのJWTがこの3区切りとは限りません。

ペイロードを読みやすいJSONに戻した例は、次のとおりです。これは形式の説明であり、APIに送れる完成済みトークンではありません。

JWTペイロードの概念例

{
  "iss": "https://auth.example.com",
  "sub": "user-123",
  "aud": "calendar-api",
  "exp": 1893456000
}

RFC 7519 §4.1のクレームを、この例に沿って読むと次のようになります。

項目	意味	確認すること
iss	発行者	信頼する発行元から来たものか
sub	対象者・対象となる主体の識別子	誰についてのトークンか
aud	想定する受け取り先	自分のAPI向けのトークンか
exp	有効期限	期限を過ぎていないか

この例のexpは、1970年1月1日UTCからの秒数で表した日時です。例示用の値であり、実際のトークンを長期間有効にする推奨ではありません。

JWTの基本仕様では、これらがすべての用途で一律必須というわけではありません。 使う仕様やサービスごとに、必須項目と検証ルールを決めます。

「読めた」と「信頼できる」は別

署名付きJWTのヘッダーやペイロードは、通常、Base64urlという表現で格納されています。これは暗号化ではないため、トークンを入手した相手が内容を読めます。

署名は「中身を秘密にする」ためではなく、改ざんなどを検出するためのものです。パスワードや不要な個人情報を入れないでください。

そして、デコードしてsubが見えただけでは本人確認になりません。受け取る側では、信頼する鍵と許可したアルゴリズムによる検証に加え、発行者・利用先・有効期限など、その用途の条件を確認します。

JWTの中身が指定したアルゴリズムを、そのまま無条件に信用してはいけません。 本番では対応するライブラリや認証基盤を使い、公式の検証手順に従います。

出典：RFC 8725 §3：JWTの検証に関する推奨事項、OWASP：JWT。

BearerとJWTは同じ意味ではない

ここまでを短く整理すると、次の違いです。

• Bearer ：その資格情報をどう使うか、という話。
• JWT ：情報をどんな形式で表すか、という話。

JWTをBearerトークンとして送ることはあります。一方、Bearerトークンが必ずJWTとは限りません。中身を利用側で読み取らず、単なる文字列として扱うトークンもあります。

7. OAuth 2.0：「別のアプリに権限を渡す仕組み」

OAuth 2.0は、保護されたデータや機能へのアクセスを、アプリに認めるための 認可の枠組み です。

たとえば、予定表サービスとは別の「予定をまとめて表示するアプリ」に、自分の予定を読ませたいとします。

予定表サービスのパスワードを連携アプリへ渡すと、そのアプリに広い操作を許してしまうかもしれません。そこで「予定を読むだけ」といった範囲を決めて、アクセスを許可します。

この許可範囲を表すのが スコープ（scope） です。たとえばcalendar:readという名前なら「予定を読む権限」を表す設計が考えられます。これは架空の名前で、実際のスコープ名と意味はサービスが定めます。

OAuthは外部サービス連携だけでなく、自社の複数アプリやAPI間の連携にも使われます。

出典：RFC 6749 §1・§3.3：OAuth 2.0／Access Token Scope。予定表連携とスコープ名は筆者の例です。

登場人物を分けると分かりやすい

RFC 6749 §1.1の役割を予定表の例に当てはめます。

役割	この例での担当
リソース所有者	自分の予定へのアクセスを許可する利用者
クライアント	予定をまとめて表示する連携アプリ
認可サーバー	利用者の認証や許可を扱い、トークンを発行する側
リソースサーバー	予定のデータを返すAPI側

認可サーバーとAPIは、同じサービス内にあることもあります。ここでは役割を分けて考えます。

認可コード方式の流れ

利用者が操作する連携では、 認可コード方式とPKCEの組み合わせ を押さえると理解しやすくなります。

認可コードは、アクセストークンを受け取るための短命な「引換券」のようなものです。コードをそのまま予定表APIに送るのではありません。

以下は、RFC 6749 §4.1とPKCE（RFC 7636）をもとに、筆者が予定表連携の例へ置き換えたシーケンス図です。ここでは、 連携アプリのサーバー側でコードの交換とAPI呼び出しを行うWebアプリ を例にします。ブラウザー内だけで動くアプリやモバイルアプリでは、処理を担当する場所が異なります。

シーケンス図は、 横に登場人物を並べ、上から下へ時間の流れを読む図 です。矢印を見ると「誰から誰へ、何を渡すか」が分かります。この図では実線を要求・処理、破線を応答・結果に使います。読みやすいよう、前半と後半に分けます。

前半：ブラウザー経由で認可コードを受け取る

「別のURLへ移動するようブラウザーに案内すること」を リダイレクト と呼びます。前半では、認可サーバーから連携アプリへ認可コードを直接送るのではなく、ブラウザーが戻り先URLへアクセスすることでコードを届けています。

連携開始時には、要求するスコープ、登録済みの戻り先URL、PKCEの照合用情報などを渡します。図ではパラメーターの細部を省略しています。既にログイン・許可済みの場合など、毎回同じ入力画面や同意画面が出るとは限りません。

後半：コードをトークンに交換してAPIを呼ぶ

ここからは、連携アプリのサーバーが認可サーバーやAPIと通信します。APIへのトークンの送り方は、RFC 6750 §2.1のBearerヘッダーを使う例です。

トークンの要求には、コードとPKCEの検証用値だけでなく、クライアントの種類や仕様に応じた認証情報、戻り先URLなども必要です（RFC 6749 §4.1.3）。PKCEは、必要なクライアント認証の代わりにはなりません。図は検証が成功した場合だけを示しており、失敗した場合はトークンや保護されたデータを返しません。

この構成では、アクセストークンは連携アプリのサーバー側で扱います。最後に、取得した予定をブラウザーへ返して利用者に表示します。 ブラウザー経由で戻る認可コードと、APIに送るアクセストークンは別物 です。

重要なのは、 利用者のパスワードは認可サーバー側で扱い、連携アプリへ渡さずに済む ことです。連携アプリは、発行されたアクセストークンを使います。

PKCEは「コードを横取りされても交換されにくくする」仕組み

PKCEは Proof Key for Code Exchange の略で、「ピクシー」と読みます。

連携アプリは、連携を始めるたびにランダムな検証用の値を作り、その値から作った照合用の情報を先に認可サーバーへ渡します。コードをトークンへ交換するときに元の値を送り、対応しているか確認してもらいます。

認可コードだけを横取りしても、元の検証用の値を知らなければ交換できないようにする考え方です。 PKCE自体が利用者を認証したり、発行後のトークンの漏えいを防いだりするわけではありません。

現在のOAuthセキュリティ指針であるRFC 9700 §2.1.1では、認可コード方式を使う公開クライアントにはPKCEが必須です。公開クライアントとは、アプリ共通の秘密情報を安全に保持できない、ブラウザー内アプリやモバイルアプリなどを指します。秘密情報を保持できるサーバー側のクライアントにもPKCEが推奨されています。

新しく実装するなら、対応ライブラリやサービスの公式SDKを使い、PKCEのS256、戻り先URLの検証、リクエストと応答の対応確認などを含む推奨フローに従います。この図だけを実装仕様にしないでください。

古い解説の方式を、そのまま新規実装に使わないでください。
RFC 9700では、連携アプリが利用者のパスワードを受け取る方式（Resource Owner Password Credentials Grant）は使用禁止です。認可応答で直接アクセストークンを返すImplicit方式も、原則として使わないよう勧めています。

出典：RFC 9700 §2.1.2・§2.4、RFC 7636 §4.2：S256。

OAuthとJWTは組み合わせられる

OAuth 2.0は、アクセストークンの形式をJWTに限定していません。

「OAuthの手順で発行されたアクセストークンがJWT形式で、APIへはBearerとして送る」という構成もあります。

OAuthは権限を得る仕組み、JWTは形式、Bearerは使い方。 この3つは競合する選択肢ではありません。

なお、人が操作しないサーバー間の連携では、アプリ自身を確認するClient Credentials方式などもあります。OAuthに必ず利用者のログイン画面が登場するわけではありません。

出典：RFC 6749 §1.4：トークン形式、§4.4：Client Credentials。

8. OpenID Connect：ログインした人を確認するための仕組み

「ほかのサービスのアカウントでログインしたい」という目的では、 OpenID Connect（OIDC） が関係します。

OIDCは、OAuth 2.0の上に、利用者の認証結果をアプリへ伝える仕組みを加えた規格です。認可リクエストのスコープにopenidを含めて要求します。

OAuthのアクセストークンを取得しただけで、アプリがログインした人を標準的な方法で確認できるとは限りません。OIDCでは、そのために IDトークン を使います。

出典：OpenID Foundation：OpenID Connect Core 1.0 §1。

IDトークン・アクセストークン・リフレッシュトークンを分ける

次の表は、OIDCのID TokenとRFC 6749のAccess Token／Refresh Tokenを、用途で比較したものです。

名前	主な用途	主に受け取って処理する相手
IDトークン	誰が認証されたかなどをアプリへ伝える	ログインを受け付けるアプリ
アクセストークン	APIの保護された機能・データへアクセスする	API側
リフレッシュトークン	新しいアクセストークンを取得する	認可サーバーのトークン発行窓口

OIDCのIDトークンはJWTです。ただし、アクセストークンまでJWTとは限りません。また、リフレッシュトークンは常に発行されるものではありません。

IDトークンを、そのまま業務API用のアクセストークンの代わりに使わない でください。受け取り先と用途が違います。IDトークンも、署名・発行者・アプリを示す利用先・期限など、OIDCの規則に沿った検証が必要です。

同様に、リフレッシュトークンを予定表APIに送るわけではありません。トークンは「どれでも同じ鍵」ではなく、渡す相手と役割が決まっています。

9. 全体を「何の話か」で見直す

ここまでのBasic、Bearer、JWT、OAuth、OIDCを、筆者が学習用に比較した表です。公式な「認証方式の6分類」ではありません。

用語	主に何の話か	覚え方
Basic認証	ユーザー名とパスワードを送るHTTP認証方式	毎回のリクエストにIDと合言葉を添える
APIキー	提供者が発行する識別用・アクセス用の値	APIごとに役割と制限を確認するキー
Bearer	トークンの保有によって使う性質・送信方式	持参して使う入場券
JWT	情報を表現する形式	情報と検証用の仕組みを備えたデータ形式
OAuth 2.0	アプリにアクセスを認める認可の枠組み	権限を渡してトークンを受け取る手順
OpenID Connect	OAuth 2.0に利用者の認証を加える規格	誰がログインしたかを確認する仕組み

APIを使う側では、好みで方式を選ぶのではなく、まずAPI提供者の仕様に従います。

自分でAPIを設計する側なら、「人を確認したいのか、アプリを確認したいのか」「外部アプリへ権限を渡すのか」「誰のどのデータを扱わせるのか」を先に決めます。

10. 最後に押さえたい安全上の注意とエラーの読み方

方式の名前だけでは安全にならない

OWASPのREST API向け推奨事項とRFC 9700をもとに、この記事の範囲で確認したい点を整理します。

• HTTPSを使う ：Basic・APIキー・Bearerのどれでも、通信を保護する。
• 秘密の値を残さない ：URL、Git、ログ、スクリーンショット、質問投稿へ載せない。ヘッダーに置いた値もログのマスキング対象にする。
• 必要な権限だけにする ：読むだけのアプリへ、更新・削除の権限まで渡さない。
• 期限・更新・失効を考える ：漏えい時にキーやトークンを無効化できるか確認する。署名付きJWTも、ログアウトしただけで自動的に無効になるとは限らない。
• API側で権限を確認する ：有効なトークンでも、他人のデータを操作できないようにする。
• 実トークンを外部の解析サイトへ貼らない ：JWTを読む練習は、架空のサンプルで行う。

401と403は何が違う？

APIが返すエラーを読むときの目安です。RFC 9110 §15.5.2・§15.5.4の定義を、API利用時の確認につなげます。

ステータス	意味	まず確認すること
401 Unauthorized	対象へアクセスするための有効な認証情報がない	ヘッダーの付け忘れ、トークンの期限切れ、誤った資格情報
403 Forbidden	リクエストを理解したが、処理を拒否した	権限・スコープ不足、アクセス元の制限など

Bearerでは、無効なトークンに401、スコープ不足に403を返すことがRFC 6750 §3.1に示されています。

ただし、 403だから必ず認証済み、と断定はできません。 資格情報とは無関係な理由で拒否される場合もあり、リソースの存在を隠すために404を返す設計もあります。ステータスだけでなく、APIの仕様とエラー内容を合わせて確認します。

まとめ

最初からすべての用語を暗記する必要はありません。まずは次の3つを区別すると、APIのドキュメントを読みやすくなります。

1. APIは、プログラムが機能やデータを使うための窓口。
2. 認証は「誰か」、認可は「何をしてよいか」の確認。
3. Bearerは使い方、JWTは形式、OAuthは認可の仕組み。ログインの本人確認にはOIDCが関係する。

「どの資格情報を、誰から受け取り、誰へ送り、何を許可するのか」。この順に確認すると、名前だけを覚えるより整理しやすくなります。

仕様確認日：2026年9月19日。安全上の指針はRFC 9700、各方式の定義は各節の出典で確認しています。図、予定表の例、比較表は説明用であり、本番向けの実装仕様を網羅するものではありません。

おわりに

次にAPIの仕様書を読むときは、認証ヘッダー、必要な権限、トークンの期限、エラーの説明を探してみてください。

Wealthy Designでは、Webシステム開発やクラウド活用に取り組んでいます。会社の取り組みは公式サイトにまとめています。

AWS・Web開発・AI活用のご相談や、採用・カジュアル面談については、Wealthy Design公式LINEでもお問い合わせいただけます。