クライアントクレデンシャルグラントについて調べると、フローや用途は書かれてますがリフレッシュトークンについては「含めるべきではない。」とまでしか書いてないですよね。
なんで？って思うじゃないですか。それについての考察です。
結論（読むの面倒な人向け）
クライアントクレデンシャルグラントとは
素晴らしい記事を参考にして頂ければと思いますが、
アプリケーションに対して権限を委譲しリソースサーバーとやり取りする方式ですね。
認可コードグラントとクライアントクレデンシャルグラントの違い
| 認可エンドポイント | トークンエンドポイント | |
|---|---|---|
| 認可コードグラント | ◯ | ◯ |
| クライアントクレデンシャルグラント | × | ◯ |
わざわざ表にする必要は置いておいて、
そう、クライアントクレデンシャルグラントは認可エンドポイントを必要としないんですね。
つまり、リソースオーナと認可サーバーとのやりとりがないのがポイントです。
リフレッシュトークンおさらい
RFC 6749: The OAuth 2.0 Authorization Framework
ここに書いてある通りなんですが、通常アクセストークンより長い生存期間を持ち、アクセストークンを再取得するために用いられるトークンです。
クライアントクレデンシャルグラントのリフレッシュトークンについて
では、クライアントクレデンシャルグラントでなぜリフレッシュトークンを含めるべきではないのか？
これは、クライアントクレデンシャルグラントの特性上含めてもあんまり意味がないからだと思います。
認可コードグラントではリソースオーナーとのやり取りがあり、リフレッシュトークンがまだ生きていればアプリの権限移譲の確認フローをやらなくても良くなりますね。ユーザ体験の向上とかに効果ありそうです。
クライアントクレデンシャルグラントの場合、アプリが直接権限をもらいに行きます。
そこには、認可コードグラントのような面倒なやり取りはありません。クレデンシャルを渡すだけです。
つまり、リフレッシュトークンを利用する旨味があまりなく、都度トークンエンドポイントを叩けばいいじゃんって感じですね。
