WordPress REST APIの認証とOAuth 2.0｜アプリケーションパスワードとの使い分け

外部のプログラムやサービスから WordPress の REST API を使うとき、「OAuth 2.0 で認証したい」という相談はよくあります。ただし WordPress 本体には OAuth 2.0 の仕組みは入っていません。この記事では、WordPress 本体が持つ認証方法、OAuth 2.0 が本当に必要になる場面、プラグインで OAuth 2.0 を使うときの流れを説明します。プラグインの情報は2026年10月時点のものです。

WordPress 本体が持つ REST API の認証方法

REST API ハンドブックの「認証」のページでは、本体の認証方法として次の2つが説明されています。

同じページでは、OAuth 1.0a や JSON Web Token（JWT）はプラグインで追加する方法として紹介されています。OAuth 2.0 も同じで、使うにはプラグインが必要です。

OAuth 2.0 が必要な場面と、不要な場面

多くの連携はアプリケーションパスワードで足ります。OAuth 2.0 は、複数のユーザーが「このアプリに自分のアカウントの操作を許可する」画面を通す必要がある場合に選びます。

アプリケーションパスワードで API を呼ぶ

発行する

1. 管理画面の「ユーザー」→「プロフィール」（別のユーザーの分は「ユーザー」→「ユーザー一覧」から編集画面）を開きます。
2. 下の方の「アプリケーションパスワード」の欄に、用途がわかる名前（例: report-script）を入れて追加します。
3. 表示されたパスワードを控えます。この画面を閉じると再表示できません。

アプリケーションパスワードは、サイトが HTTPS で動いていることが前提です。HTTP のサイトでは、この欄に HTTPS が必要という案内が出て発行できません（WP_ENVIRONMENT_TYPE が local の開発環境を除く）。

curl で確認する

curl --user "editor-bot:abcd efgh ijkl mnop qrst uvwx" \
  https://example.com/wp-json/wp/v2/users/me

自分のユーザー情報が JSON で返れば認証は成功です。記事を下書きで作るには次のようにします。

curl --user "editor-bot:abcd efgh ijkl mnop qrst uvwx" \
  -X POST https://example.com/wp-json/wp/v2/posts \
  -H "Content-Type: application/json" \
  -d '{"title":"API test","content":"Hello","status":"draft"}'

• パスワードの空白は入れたままでも外しても使えます。
• 連携ごとに別のアプリケーションパスワードを発行しておくと、不要になったものだけを取り消せます。
• 連携専用のユーザーは、必要な権限だけを持つ権限グループ（例: 投稿だけなら「投稿者」や「編集者」）にします。

OAuth 2.0 の基本: 認可コードフローと PKCE

OAuth 2.0（RFC 6749）では、登場する役割と流れは次のとおりです。

• クライアント: API を使いたい外部アプリ。事前に認可サーバーへ登録し、client_id（機密クライアントなら client_secret も）を受け取ります。
• 認可サーバー: ユーザーに許可を求め、アクセストークンを発行します。この記事では WordPress にプラグインを入れてこの役割を持たせます。
• リソースサーバー: トークンを受け取って API を提供する側です。

認可コードフローの流れは次のとおりです。

1. クライアントがユーザーのブラウザーを認可エンドポイントへ移動させます。
2. ユーザーが WordPress にログインし、アクセスを許可します。
3. 認可サーバーが、登録済みの redirect_uri に認可コードを付けてブラウザーを戻します。
4. クライアントがサーバー側から、認可コードをトークンエンドポイントでアクセストークンに交換します。
5. クライアントは Authorization: Bearer ACCESS_TOKEN（ACCESS_TOKEN は受け取ったトークン）を付けて API を呼びます。

PKCE（RFC 7636）は、認可コードを横取りされても使えないようにする仕組みです。クライアントが毎回ランダムな code_verifier を作り、そのハッシュ（code_challenge）を最初の要求で送り、交換時に元の code_verifier を送ります。スマートフォンアプリや JavaScript だけで動くアプリのように client_secret を安全に保管できないクライアントでは、PKCE を使います。

プラグインで WordPress を OAuth 2.0 サーバーにする例

ここでは wordpress.org で配布されている WP OAuth Server (OAuth Authentication)（プラグインのスラッグは oauth2-provider）を例にします。2026年10月時点の配布ページの記載では、無料版で使えるのは認可コード（Implicit を含む）と PKCE、OpenID Discovery です。クライアントクレデンシャル・リフレッシュトークン・OpenID Connect などは有料版の機能とされています。導入前に、配布ページで最終更新日・対応する WordPress のバージョン・レビューを確認してください。

1. インストールとクライアントの登録

wp plugin install oauth2-provider --activate

管理画面の「設定」→「OAuth Server」を開き、「Clients」タブの「Add New Client」でクライアントを登録します。リダイレクト先の URL（redirect_uri）を登録し、発行された Client ID と Client Secret を控えます。

2. エンドポイント

このプラグインのドキュメントでは、エンドポイントはサイトの URL に /oauth を付けた形です。

3. curl で流れを確かめる

まず code_verifier と code_challenge を作ります（OpenSSL を使う例）。

CODE_VERIFIER=$(openssl rand -base64 48 | tr -d '=+/' | cut -c1-64)
CODE_CHALLENGE=$(printf '%s' "$CODE_VERIFIER" | openssl dgst -sha256 -binary | openssl base64 | tr '+/' '-_' | tr -d '=')
echo "$CODE_VERIFIER"
echo "$CODE_CHALLENGE"

次の URL をブラウザーで開き、WordPress にログインして許可します。state は要求ごとにランダムな値にし、戻ってきたときに同じ値か確かめます。

https://example.com/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=https%3A%2F%2Fapp.example.net%2Fcallback&state=RANDOM_STATE&code_challenge=CODE_CHALLENGE&code_challenge_method=S256

redirect_uri に ?code=...&state=... が付いて戻ってきたら、その code をトークンに交換します。

curl -X POST https://example.com/oauth/token \
  -d grant_type=authorization_code \
  -d code=AUTHORIZATION_CODE \
  -d redirect_uri=https://app.example.net/callback \
  -d client_id=CLIENT_ID \
  -d client_secret=CLIENT_SECRET \
  -d code_verifier="$CODE_VERIFIER"

返ってきた JSON の access_token を使い、トークンに結びついたユーザーを確認します。

curl -H "Authorization: Bearer ACCESS_TOKEN" https://example.com/oauth/me

4. REST API で使えるか確かめる

発行したトークンで /wp-json/ の各エンドポイントを認証できるかは、プラグインの実装と設定によります。次のリクエストでログイン中のユーザーが返れば、REST API の認証にも使えています。rest_not_logged_in などのエラーが返る場合は、プラグインの説明書で REST API との連携方法を確認してください。

curl -H "Authorization: Bearer ACCESS_TOKEN" https://example.com/wp-json/wp/v2/users/me

Authorization ヘッダーが届かない場合

Apache で PHP を CGI / FastCGI として動かしていると、Authorization ヘッダーが PHP に渡らず、アプリケーションパスワードでも OAuth のトークンでも認証されないことがあります。WordPress が書き出す標準の .htaccess には、このヘッダーを渡すための次の行が入っています。古い .htaccess を使い続けている場合は、# BEGIN WordPress の中にこの行があるか確認してください。

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

ほかに REST API が 401・403 を返す原因は WordPress REST APIのエラーの直し方 を参考にしてください。

運用上の注意

• HTTPS で使う: トークンもアプリケーションパスワードも、盗まれればそのまま使われます。HTTP では送らないでください。
• redirect_uri は完全一致で登録する: 任意の URL へ戻せる設定にすると、認可コードを第三者のサイトへ送らせる攻撃に使われます。
• state と PKCE を使う: CSRF と認可コードの横取りを防ぎます。
• 権限を絞る: 連携用のユーザーやスコープは、必要な操作だけに限ります。
• 秘密情報の保管: client_secret・アクセストークン・アプリケーションパスワードはソースコードに直接書かず、環境変数や秘密情報の保管機能に置きます。
• 取り消し手順を決めておく: アプリケーションパスワードはプロフィール画面から個別に取り消せます。OAuth のトークンは /oauth/revoke などプラグインの機能で取り消します。
• 使っていない API を閉じる: 外部に公開する必要のない REST API の制限は REST APIへのアクセスを制限する方法 を参考にしてください。

まとめ

• WordPress 本体の REST API 認証は Cookie＋nonce とアプリケーションパスワードの2つで、OAuth 2.0 はプラグインで追加します。
• 自分のスクリプトや決まった連携なら、アプリケーションパスワードで足ります。
• 第三者のアプリが各ユーザーの許可を得て操作する場合は、OAuth 2.0 の認可コードフローと PKCE を使います。
• プラグインを選ぶときは、対応するグラントの種類、REST API の認証に使えるか、更新が続いているかを確認します。