WordPress 5.6が外部アプリ認証のためのアプリケーションパスワードを導入 – Capital P

WordPressは4.4からREST APIを導入しており、「WordPressのデータを外部から操作する」ということが本質的には可能になっているが、認証方法がCookieしかデフォルトで提供されていなかった。ところがフィーチャープラグインとして開発されていたApplication Passwordが5.6からコアにマージされるため、あらたな認証方法が追加されることとなった。

Cookie認証以外のREST APIは何があるのか？

まず、WordPressのREST APIが現在サポートしている認証方法であるCookieについて説明しておこう。

そもそもWordPressはCookieをログインに利用している。ブラウザからアクセスする場合はこのCookieを読み取ることで「ログイン済みのユーザーかどうか」を判定している。REST APIではリクエストにnonce（24時間に限り有効な認証情報）が含められている場合に限りCookie認証を許可する。これはどういうことかというと、「いままさにWordPressのWebサイトを見ている人でしか入手できない情報を持っている限りREST APIの利用を許す」とうことである。というのも、Cookieはブラウザしか読み取れないためだ。

別言すれば、デフォルトのREST APIは外部からデータをとる場合は常に未認証のユーザーとして扱われていたのである。Webサイトの外部からの利用というのは、Capital Pの読者であればすぐに思いつくだろう。Facebookやtwitterといった各種SNSは同じ認証情報でWeb＆モバイルの両方から利用することができる。

REST APIの主な利点はWebサイト以外からのアプリによるデータの利用だ。「REST API + SPAでサイトがサクサク！　最高のUX」というのはあまり本質的ではなく、「そうなんだ、よかったね」という話でしかない。我々はGitHubでの出来事をSlackに投稿したり、Zoomでミーティングの予定をGoogle カレンダーに書き込んだりをしているが、この外部連携の容易さが様々なサービス体験を向上させているのだ。世界の相互作用でいろんなものが便利になったから生産性が向上しているのであり、人類自体は何万年も大して進化していない。

REST APIによる外部連携で重要になるのは認証である。OAuthやOpenIDによる認証などは意識せずとも利用している手法である（例・EvernoteにGoogleアカウントでログイン）。

こうした手法、特にモバイルアプリとWordPressを連携させるべく色々と頑張っていたプラグインは多く、たとえば以下のようなものがある。

おそらく、クライアントに「WordPressをモバイルアプリから使えるようにしてね」と言われてこうしたプラグインを使いながら人知れず苦しい夜を過ごした開発者も少なからずいるだろう。筆者も自分のサービスを外部（NodeJSアプリ）から使えるようにするために死ぬような思いをしたことがある。

Application Passwordは、ユーザーが自分のパスワード以外に特定のアプリ専用にパスワードを払い出す機能である。この利点はなにかというと、セキュリティの担保である。アプリに脆弱性があって悪用された、あるいはそのアプリを作っていた奴がもともと悪者だった場合など、アプリ専用パスワードを無効にすれば安全である。

正直いうと、このアプリケーションパスワードはかなりレガシーというか、原始的な機能であり、いまそこなのかという思いはないでもないが、「外部から利用できる認証情報がデフォルトで追加された」というのはかなり大きいだろう。

Application Passwordで何ができるか？

これは利用者というより開発者視点での考えなのだが、「世界中のWebサイトの3分の1以上がWordPressである場合、アプリケーションパスワードがあるとなにができるのか？」という点で考えると、色々できることはあるだろう。パターンとしては以下の2点がメインになると思われる。

Saasとの接続。
モバイルアプリからの利用。

もちろん、前述したREST APIを外部に提供するプラグインでも実現できたのだが、筆者が死ぬ思いをした5年前から比べてもそんなに一般的な事例にはなっていないので、「外部のサービスを利用するためにWordPressに目的がなんなのかよくわからないプラグインをインストールする」というのがそもそもハードルが高かったのだろう。

とりわけ、フロントエンドに強く、実はSwiftがちょっとできたりする開発者は、バックエンドとしてのみWordPressを利用すること（＝ヘッドレスCMS）のハードルが下がる。いくつか面白い事例が出てくることは期待してよいだろう。

もちろん、WordPressサイトにログインしてアプリケーションパスワードを発行し、それをモバイルアプリに入力するというフローがくそダルいことは確かだ。たとえば、最近のFacebook関連アプリでは、「OAuth認証でアプリ内ブラウザが立ち上がり、Facebookログインを求められるのだが、キーチェーンがなぜか効かないのでパスワードを入力できない」という地獄を回避する工夫がされており大変スムースなUXを提供している。そのレベルを求めるのは難しいが、なんにせよWordPress自身のREST API利用以外の道が開かれたのは大きな進歩だ。

また、パーミッションの概念がないことも問題ではある。我々は「Facebookでログイン」を選んだとき、パーミッションを確認している。「タイムラインに投稿」と書いてあったら「あ、こいつやばい奴だ」と判断する。アプリケーションパスワードにはパーミッションレベルが（いまのところ）ないので、これも将来的には実装すべきだろう。余談だが、このパーミッションの話題はすでにコメント欄で挙がっているのだが、会話をしている人物がほぼ全員Automatticのメンバーだというのはコミュニティに詳しい人にとっての「あるある」だ。「ここは社内チャットじゃないぞ！」とツッコまずにいられる人はオープンソースエコシステム上級者である。

なお、Application PassowrdはWordPressデータを外部に晒す恐れがあるので、現在はもっぱらセキュリティリスクについて関心が移っている。たとえば、SSLが有効なサイトでしか動かないとか、MFA（多要素認証）をサポートするのかとか、そういったことだ。二段階認証プラグインはすでにリリースされており、これはマージした方がいいのでは、という意見はすでに出ている。IPhoneをなにも考えずに機種変更した上で二段階認証に使っていた旧端末をメルカリに放流してWordPressにログインできなくなった人々がフォーラムに押し寄せる未来もそう遠くないかもしれない。

今年の12月にWordPress 5.6はリリースされる予定なので、もしかしたらリリースに合わせてモバイルアプリを出してくる野心家もいるかもしれない。その際はCapital Pでレビュー記事を書く予定である。