同様のエラーが発生し、このページに飛びました。 自己解決できたので、一例ではありますが、解決策を載せておきます。
私の場合はまず、このエラーの前に"redirect_uriのエラー"が発生しており、 エラー箇所のコード修正だけして(ログインし直さずに)ページをリロードしたため、 このエラーが発生したようです。 一度、ログインボタンがあるページまで戻り、再度、ログインしたら解決しました。 後続の一助になればと。。。
(ちなみに、redirect_uriのエラー"redirect_uri does not match"は、 エンコード後のuriをredirect_uriに指定していたため、発生していました。)
- 0
私も質問者さまと同じ状態です。 curlコマンド試してみたのですが、結果は同じでした。
何かほかに考えられる原因はございますでしょうか? ちなみに環境は以下です。 docker rails6 ssl対応済(https://localhost:3001/)
以下は、curlの返答です。 `* Trying 203.104.153.64...
- TCP_NODELAY set
- Expire in 200 ms for 4 (transfer 0x564fb0710f50)
- Connected to api.line.me (203.104.153.64) port 443 (#1)
- ALPN, offering h2
- ALPN, offering http/1.1
- successfully set certificate verify locations:
- CAfile: none CApath: /etc/ssl/certs
- TLSv1.3 (OUT), TLS handshake, Client hello (1):
- TLSv1.3 (IN), TLS handshake, Server hello (2):
- TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
- TLSv1.3 (IN), TLS handshake, Certificate (11):
- TLSv1.3 (IN), TLS handshake, CERT verify (15):
- TLSv1.3 (IN), TLS handshake, Finished (20):
- TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
- TLSv1.3 (OUT), TLS handshake, Finished (20):
- SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
- ALPN, server accepted to use h2
- Server certificate:
- subject: C=JP; ST=Tokyo-to; L=Shinjuku-ku; O=LINE Corporation; CN=*.line.me
- start date: Jun 17 06:01:58 2020 GMT
- expire date: Sep 5 12:00:00 2022 GMT
- subjectAltName: host "api.line.me" matched cert's "*.line.me"
- issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018
- SSL certificate verify ok.
- Using HTTP2, server supports multi-use
- Connection state changed (HTTP/2 confirmed)
- Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
- Using Stream ID: 1 (easy handle 0x564fb0710f50)
POST /oauth2/v2.1/token HTTP/2 Host: api.line.me User-Agent: curl/7.64.0 Accept: / Content-Type: application/x-www-form-urlencoded Content-Length: 184
- We are completely uploaded and fine
- TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
- TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
- old SSL session ID is stale, removing
- Connection state changed (MAX_CONCURRENT_STREAMS == 128)! < HTTP/2 400 < server: openresty < date: Tue, 27 Apr 2021 00:59:21 GMT < content-type: application/json;charset=UTF-8 < content-length: 74 < cache-control: no-store < x-content-type-options: nosniff < x-frame-options: DENY < x-xss-protection: 1; mode=block <
- Connection #1 to host api.line.me left intact {"error":"invalid_grant","error_description":"invalid authorization code"}`
- 0
不思議ですねぇ。
認可コードの使用方法について再確認するくらいでしょうか。
有効期間10分以内にアクセストークンを発行しているか(していると思いますが)と、利用回数(実は2回アクセストークンを発行しようとしていて1回目は破棄されていたり…?。これもなさそうですが)を確認する感じでしょうか。。
アクセストークンの取得に使用される認可コード。有効期間は10分です。また、認可コードは1回のみ利用可能です。
いったんお使いのソースコードを使ってcodeを取得するだけにして、アクセストークンの発行は、別途、curlコマンドを使って試してみると、ある程度の切り分けができるかもしれません。
- 0
@Yazaki 様
ご回答ありがとうございます。 ログインユーザーが認証した後にパラメータとしてstateと併せて送信されてくるcodeの値を指定しています。
- 0
こんにちは
たとえば、以下のようなcurlコマンドで {"error":"invalid_grant","error_description":"invalid authorization code"} が返されます。正しいcode(authorization code)を指定しているか確認してみていただけますか?
curl -v -X POST https://api.line.me/oauth2/v2.1/token \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'grant_type=authorization_code' \
-d 'code=適当なコード' \
-d 'redirect_uri=正しいredirect_uri' \
-d 'client_id=正しいチャネルID' \
-d 'client_secret=正しいチャネルシークレット'
- 0