トークンの有効期限
BlueskyのAPIを利用して各種操作を行う場合、まず最初にIDとパスワードを使って認証し、払い出されたトークンを使って投稿やリソースの取得を行います。
最初の認証で払い出されるトークンは accessJwt と refreshJwt で、前者は投稿やリソース取得を行う場合の認証に使われ、後者はaccessJwtの再発行とセッションの終了・破棄に利用されます。
accessJwt と refreshJwt はいずれも JWT (JSON Web Token) の規格にしたがっているため、その一部 (xxxx.yyyyy.zzzz のようにピリオドで区切られた文字列の真ん中) をbase64 デコードすることで発行日時や失効のタイミングを読み取ることができます。
Blueskyのトークン accessJwtをデコードしてみると以下のような情報が含まれていることがわかります。
{ "scope": "com.atproto.appPass", "sub": "did:plc:ad5t3aryxxxbf32qd6hpbq7", "iat": 1707835494, "exp": 1707842694, "aud": "did:web:chaga.us-west.host.bsky.network" }
ここで iat と exp がそれぞれ発行と失効の時刻で、差を見ると7200秒 =2時間 がアクセストークンの有効期間だとわかります。
ドキュメントだと”数分”と書かれていますが、クラウドフローの実行時間の観点からだと結構長いですね。
一方で、リフレッシュトークン refreshJwt を見てみると
{ "scope": "com.atproto.refresh", "sub": "did:plc:ad5t3axxxxjbf32qd6hpbq7", "aud": "did:web:bsky.social", "jti": "hxbx0wrCdssssssDez6oVYy3gVuiPe6OiGRhHcc", "iat": 1707835494, "exp": 1715611494 }
今度は expとiatの差が 7,776,000秒 = 2160時間 = 90日 と非常に長く設定されていることがわかります。
Bluesky（に限らずですが）では一度ID/PWで認証を行った後は長寿命なリフレッシュトークンを使ってアクセストークンを更新しながらAPIを利用するのが好ましいと思われます。
トークンのリフレッシュ
BlueskyのAPIでアクセストークンをリフレッシュするには以下のように、com.atproto.server.refreshSessionを実行します。
- URI:
https://bsky.social/xrpc/com.atproto.server.refreshSession - Method:
POST - Headers:
Authorization : Bearer <リフレッシュトークン>,Accept : application/json
この応答として、新たな期限が設定された accessJwt と refreshJwt が発行されます。
ここでわかることは、アクセストークンはリフレッシュトークンのみで再発行可能であり、漏れると危険ということです。
トークンの強制失効
発行されたトークンは時間経過でも失効しますが、リフレッシュトークンは結構長寿命なのでなかなか失効しません。
発行されたそれぞれのトークンを強制的に失効させるためには com.atproto.server.deleteSession を利用します。
- URI:
https://bsky.social/xrpc/com.atproto.server.deleteSession - Method:
POST - Headers:
Authorization : Bearer <リフレッシュトークン>
deleteSessionするときに使うのは アクセストークン accessJwt ではなく リフレッシュトークン refreshJwt である点に注意しましょう。
これで作成された アクセストークンとリフレッシュトークンがつかえなくなります。（次に操作するときはまたcreateSessionが必要）
Power Automateでどうするか
ごにょごにょと書いてきましたが、これらを踏まえてじゃあPower AutomateやLogic Appsではどう使うといいのか ということです。
もし、IDやapp PWを毎回入力しても問題ないということであれば、最低限セキュアインプットの機能を使い、フローの最初で createSession、フローの最後でdeleteSessionすればよいでしょう。
もしくは、一度発行したトークンを更新し続けるようなフローを用意しておいて、KeyVaultのような安全な場所でトークンを保管しておいてもいいのかなと思います。
(APIを使うフローの中ではKeyVaultからトークンを取得して使う)
本来はこのあたりの煩わしさ、リスクを低減するためにカスタムコネクターがあるといいですね。
おわり
今回はずいぶんまとまりのない投稿でしたが、BlueskyのAPIを使う上でのトークン関連の紹介でした。
JWTのところは以下を参考にしました。
