概要

LINE WORKSのAPIがVer2.0になりましたね。

そろそろ対応しておかないとな、と思って、Postmanで2.0のアクセストークンを取ったりして触っていたのですが、アクセストークンはどうやら24時間で切れる模様。

Access Token

有効期限： 24時間

Refresh Token

有効期限： 90日

LINE WORKSに限らず、アクセストークンなどはAzure KeyVaultに格納しているので、毎日KeyVaultのシークレットを更新する必要があるということになります。
LINE WORKSのBot運用はPowerAutomateで行っているので、トークンの更新もPowerAutomateのフローで行ってみました。

問題は...

リフレッシュトークンが90日で切れるということ。
リフレッシュトークンが有効期限切れとなった場合は、どうするんだろう...
ググってみると、

Refresh Tokenの有効期限は90日となっておりますので、期限内にTokenを再発行するような運用をご検討ください。

どうやら延長はできなさそう。
やっぱり、取り直さないといけないのか。

手っ取り早く対応するには

JWTの期限を十分長く取っておけば、作成したJWTは何度でも使いまわせるので、ダイスケ的にもオールオッケー（誰だお前は）
ただ、セキュリティ的にはどうなんでしょう？よく分からんとです。

JWTは使いまわさず、その都度作る

リフレッシュトークンが有効期限切れの時は、その都度JWTを作ってトークンを発行する方向で、フローを組んでみたいと思います。
（JWTの有効期限を長くすればよいと思いついたのが、なんやかんやでPowerAutomateでJWT作れた後だったので、今更後にも引けず）

事前準備

KeyVaultに以下のシークレットを作っておきます。

ClientId
ClientSecret
AccessToken（有効期限付き）
RefreshToken（有効期限付き）

それと、JWTの署名に使うプライベートキーファイルをKeyVaultにアップロードします。

ファイルの拡張子は.keyから.pemに変更しておく必要があります。

フロー

全体

１日２回起動するため、「繰り返し」トリガーで起動します。
前半はKeyVaultのアクセストークンの取得です。
その後、LINE WORKSのIDやシークレットをKeyVaultから取得。
条件ブロックでリフレッシュトークンが有効かどうか判別して、リフレッシュトークンによる更新か、JWTを作成して新規に発行するか、の場合分けを行っています。

KeyVaultにアクセスするためのトークンを取得

シークレットの更新はアクションが用意されていないので、直接APIを叩く必要があります。
その際に、アクセストークンが必要になるので、以下のような感じで、KeyVault用にアクセストークンを取得します。
こちらもアクセストークンの有効期限は１時間（3599秒）なので、都度取る必要があります。

詳しくはMSの公式を参照してください。

取得したトークンは変数にぶち込んでおきます。

あと、LINE WORKSのシークレット等をKeyVaultから取得しておきます。
（AccessTokenは使わないので取らなくても構いません）

条件分岐

KeyVaultに設定された、RefreshTokenの有効期限までの残り日数で場合分けします。

残り日数は以下の式で求めています。

div(sub(ticks(outputs('LW2-RefreshToken')?['body/validityEndTime']),ticks(utcNow())),864000000000)

はいの場合（リフレッシュトークンで更新）

有効期限まで３日以上あれば、リフレッシュトークンでアクセストークンを更新します。

リフレッシュトークンによる再発行

はまりポイントは、本文を改行で区切るとエラーではじかれました。
ぜんぶURLエンコードして渡しているのは、そのときの名残で、必要ないものまで全部URLエンコードしてます。（たぶん、必要ない）

シークレットの更新

KeyVaultのAPIを叩くときは、日時はUNIX時間を指定する必要があります。
UNIX時間への変換は以下のページを参考にさせてもらいました。ありがとうございます。

updatedとexpに、更新日時と有効期限を渡してやります。

こちらは、ここで終了。

いいえの場合（JWTを作成して再発行）

JWTを作成して、アクセストークンを発行し、KeyVaultのシークレットを更新する流れになります。

JWTに必要なHeader、Payload、Signatureをそれぞれこさえていきます。

JWTのHeader部(①)

LINE WORKSのAPIリファレンス通りにJSONを書いて、Base64エンコードするだけ。
簡単ですね。

JWTのPayload部(②)

これもリファレンス通り。
生成日時をutcNow()、期限日時をutcNow()の１時間後としています。

JWTのSignature部(③)

最大の難関だったところです。
そもそも、署名のアルゴリズムとか全然わかっていないので、なにをどうしたらいいやら状態でした。

カスタムコネクタの前に、KeyVaultに格納されたキーファイルで署名を作成するHTTPアクションですが、これもKeyVaultのコネクタには署名アクションが用意されていないため、直接APIを叩く必要があります。

algでアルゴリズムを指定して、valueで値を渡すだけです。
結論としては、concat(①,'.',②)をSHA256でハッシュ化した値を渡せばよいということになります。
PowerAutomateではハッシュ化する関数は用意されていないので、以下のページを参考にさせていただきました。

上記ページは、MD5でのハッシュかですが、コードの中のMD5をSHA256に変えるだけで、ほぼそのまま流用させていただきました。感謝！
「SHA256」アクションに、以下の式を渡して、その結果をKeyVaultに渡すと、署名が出来上がります。

concat(outputs('作成-Header(encoded)'),'.',outputs('作成-ClaimSet(encoded)'))

JWT完成！

できあがった①②③を、'.'で連結するとJWTが完成します。

concat(outputs('作成-Header(encoded)'),'.',outputs('作成-ClaimSet(encoded)'),'.',body('JSON-PrivateKeyを使用して署名')?['value'])

（署名はBase64エンコード不要です）

アクセストークンの発行

作成したJWTをassertionに渡して、アクセストークンを発行します。

アクセストークン・リフレッシュトークンをKeyVaultに格納!

リフレッシュトークンで更新した場合と同様、KeyVaultに格納していきます。
アクセストークンだけでなく、リフレッシュトークンも更新する必要があります。
リフレッシュトークンの有効期限を90日後として、expに渡すことで、条件ブロックが正しく判別できるようになります。
2022-08-24_23h13_57.png

最後にお知らせ

更新したアクセストークンで、LINE WORKSに通知してやります。
この辺はお好みで。

あと、エラーとなった場合、LINE WORKSのアクセストークンが正しくないと思われるので、LINE WORKSではなく、Teamsに通知するようにしました。

まとめ

だいぶ苦労しましたが、署名の方法やカスタムコードなど、初めて知ったことが多いフローとなりました。
Azure Functionsでやるしかないか、と思っていたのが、Power Platform内で完結できるのは非常に便利だなと思います。
ただ、C#が...（VBぐらいしか使えない人間なので）

PrivateKeyを再発行した場合でも、KeyVaultのキーを更新すれば手動でJWTを作り直して格納しておく必要もないので、運用はかなり楽になるのではないかと思います。（そんなに頻繁に再発行するものではないと思いますが）

最後に、長くなりすぎてごめんなさい。（スクリーンショットが...）