リフレッシュトークンを用いたアクセストークン再取得操作時のクライアントシークレットについて
## 前提
Postmanを用いてリフレッシュトークンによるアクセストークン再取得を検証しています。
## 起こっていること
クライアントシークレットのパラメータ部分をDeveloper Consoleのページで取得したものではなくデタラメな文字列（画像内では "a"）としてものでも200 OKと共に正常にアクセストークンが取得できてしまいました。（下画像）
差分比較サイトで差をとっても正常なクライアントシークレットにより取得したアクセストークンとデタラメなクライアントシークレットで取得したアクセストークンには違いがみられませんでした。（下画像）
## 質問
上画像で同じアクセストークンが取得できたということは、極論、アクセストークン再発行の際のクライアントシークレットはデタラメな文字列でも問題ないということでしょうか。
確認をお願いいたします。
投稿に新しいコメントが追加されましたら通知を送信します。
コメント2
업데이트 된 답글입니다.
LINE WORKS 公式アカウント
本事象については今後のバージョンにて修正を予定しております。
ご報告いただきありがとうございます。
2022.08.10
업데이트 된 답글입니다.
im 投稿者
JWTを用いたアクセストークンとリフレッシュトークン取得の場合はクライアントシークレットが不正値だと400エラー「Client-id or secret is not valid.」が戻ってくることを確認しました。
2022.08.10
まだ、解決できませんか？
今すぐ実際に使用しているLINE WORKSユーザーに質問してみましょう。