OAuthのAccess TokenといわゆるPersonal Access Tokenとの違い
ritou です。
Digital Identity技術勉強会 #iddance Advent Calendar 2022 10日目の記事を代理で書きます。
今回は、APIを叩いて何がしを行うbotとかを作る際に必要になるアクセストークンの話をします。
世の中いろんなAPIが公開されてそれを組み合わせたピタゴラスイッチみたいな仕組みが実現できる時代でありますが、その際に利用されるアクセストークンについて、いくつか種類があります。
あるユーザーとして、その代わりとしてAPIを叩いてリソースアクセスを行うためのトークンは次の2種類のトークンがあるでしょう。
(この他にサービス/アプリケーション視点のものもありますが、今回は一旦対象外にします。)
- OAuth Access Token
- Personal Access Token
つい、このAPI使いたいわ〜。そのためにはアクセストークンが必要、なるほど発行！みたいに脳死でやってしまいがちなところもあるので、どんな違いがあるのか辺りを軽く説明します。
OAuth Access Token
OAuthの説明をすっ飛ばしてアクセストークンを一言で言うと、"リソースオーナーの同意のもとにクライアントがリソースオーナーの代わりとして保護リソースにアクセスするために利用するトークン" となります。
- 登場人物
- 認可サーバー
- リソースオーナー
- リソースサーバー : OAuthで保護リソースにアクセスさせるAPIを保護している
- クライアント : 保護リソースにアクセスしたいサービス/アプリケーション
クライアントがAPIアクセスを行う、それに必要なアクセストークンは認可フローを実装取得するのが一般的です。
これを使って自分用のbotを作りたい場合は
- クライアント=私のbot
- リソースオーナー=私
みたいになって、登録処理などが済んだら認可フローをちょっとしたアプリケーションを書くかcurlなどで手動で行ってアクセストークンを取得し、botに仕込んで利用します。botが私の代わりにアクセス...まぁ自然ですよね。
一点意識しておきたいのは、アクセストークンを使って利用できるリソースで言うと、3rd Partyアプリケーション向けのものとして位置付けられるものに限られることです。サービスによってはOAuthであまりリソースを解放していない場合もあります。
Personal Access Token
こちらは "パスワードなどのクレデンシャルよりもできることや期限を小さくしてAPIアクセスに利用できるトークン" みたいなところでしょう。
OAuth Access Tokenとの対比で言うと、こちらではOAuthのClient相当の登場人物がいません。
- 登場人物
- サービス : アクセストークンを発行
- リソースオーナー : 私
- リソースサーバー : OAuthで保護リソースにアクセスさせるAPIを保護している
既存のサービスで馴染みがありそうなのはこの辺りですかね。
- GitHub - Creating a personal access token
- Docbase - DocBase APIドキュメント : 昔ツッコミを入れさせてもらったことがあったんですが、色々改善されていました
GUIで行うような操作をAPIで実行する際に利用したり、自分の書いた記事一覧を引っ張ったりできそうですが、このアクセストークンを管理してAPIを叩く主体が定義されていない、と言うのがOAuth Access Tokenとの違いでしょう。
ユーザー本人向けに発行されるアクセストークンですので、それを用いて利用できるリソースは割と大きな範囲である場合が多いでしょう。DocBaseの場合は初期リリースの段階でユーザーに紐づくほぼ全てのリソースにフル権限でアクセスできそうな雰囲気だったのでTwitterで注意喚起などを行なったことがあります。今ではREAD or READ+WRITE なのかや有効期限、チーム単位での発行といったように対象のリソースとアクションを制限できる仕組みになっているようなので安心して使えるかもしれません。
両方対応してるところもある
例えばQiitaですね。
2012年ごろにPersonal Access Tokenみたいなのを実装したことは記憶にありますが、 その後OAuthの方も出ていました。
使い分けについて
OAuth Access Token は Client 単位に発行されますが、Personal Access Token はユーザー単位で発行される(＋チームなどの概念が入ることはある)ことになります。
繰り返しになりますが Personal Access Token を利用する=ユーザー自身という認識なので、(あまり聞いたことはありませんが)例えば漏洩や悪用などがあった場合、ペナルティを課されるのはユーザー自身ということにもなりそうです。（認証用のクレデンシャルを渡すスクレイピングに比べて少し安全ななりすまし的な位置付けになってしまうと思うので、）基本的には第３者が提供するアプリ/サービスに渡すべきではないと考えますし、Personal Access Tokenを入れろ！みたいなサービスやアプリがあったらリスクなどを慎重に判断してから利用しましょう。
- ritouのbot : 両方OK
- ritouが所属しているチームのbot : 微妙
- 外部のbotサービス : OAuth Access Tokenのみが良さそう
チーム向けでいうと、今回割愛した OAuth の ClientCredentials を用いたアクセストークン みたいなのも候補に上がってきますが機会があれば別途説明します。
まとめ
- OAuth Access Token はリソースオーナーの同意のもとに、保護されたリソースにアクセスするためのものでクライアントに対して発行されるトークン
- Personal Access Token は自分が作業する際に利用する、もしくは自分の代わりに作業させたい何者かに持たせるためのトークン
- 特徴、使いどころに微妙な違いがある
- 両方に対応しているサービスは少ないので、理想的な使い方ができるかはよく考えましょう
以上です。
ではまた。
Discussion