LINE Messaging API 最近一個比較重大的變更是 access token 新版的發放方式(v2.1),同時也配合 OAuth2 。比較不同的點是它是用 JSON Web Token (JWT) 去取 access token,這樣的好處是如果今天 Provider 本身(也就是付錢的人)請開發商開發 bot ,他並不需要把 channel secret/access token 都給開發商(這通常也暗示你要把開發人員加到 bot admin 去,當然也可以不這麼做,就是麻煩了點)。

改用 JWT 的好處在於開發商只需要知道 channel ID 以及 Provider 幫他申請的一組 Assertion Signing Key (RSA 加密的),對 Provider 來說資訊的保護層級就提高了,終止合作只要把這組 Assertion Signing Key 砍掉就好,不必重新申請 channel access token 且/或 channel secret。

但相反地,開發商沒有 long-lived channel access token,新版的 OAuth2 認證方式使用 JWT 產生的 access token 最長只有 30 天的限期,期限到了之前要再生,某種程度造成程式開發上的困難(安全與方便通常不是站在同一邊的),原本的邏輯上要多加處理 token expiry 。

對於 API 變動來說,可以分為兩部份來看。其一,是 JWT 的取得;其二,是 access token 的取得。前者並沒有直接呼叫到 LINE Messaging API server ,所以在開發 SDK 的時候,可以先著重在已有 JWT 的情況下與 server 端做申請/列出/撤銷 access token 的行為。這部份也提出了 pull request (PR) 在等待官方團隊的審核。

Web interface for generating JWT

而 JWT 的生成就比較麻煩了,在看官網的介紹時發現做 JWT 沒有想像中那麼容易。(中間省略一段心路歷程)最後就是決定自己開發工具來幫助生成 JWT 。

clsung/line-oauth2-helper 名字有 “OAuth2” ,實則沒有關係,是用來生 JWT 的,但因為這生出來的 JWT 也只能讓 LINE OAuth2 v2.1+ 使用,所以才取這個名子。

執行的方式看 README 即可,若是一般 go 開發者使用,那 go get github.com/clsung/line-oauth2-helper/cmd/line_jwt 最快,若是系統沒有 go 的,可以考慮用 docker 的版本(若是都沒有的,請按上一頁離開):docker pull clsung/line-oauth2-helper:stable

用 line_jwt 執行的話,預設生出來的 JWT 需要在 30 分鐘內去 access LINE server ,而生出來的 access token 會在 30 天後過期,要細部調整的則建議就使用 docker / web 的版本。若是要接在程式碼當 API 呼叫的,也可以參考 cmd/ 下的程式自行開發。