認可コードからアクセストークンを取得する

OAuth 2.0のフローで、ゲストユーザーが認可すると、指定されたリダイレクトURIにリダイレクトされ、パラメータとして認可コード（code）が発行されます。
上記のAPIを利用し、認可コードから、アクセストークン、およびリフレッシュトークンを取得します。

なお、セキュリティ上の目的もありますが、認可コードの有効期間は十分に短いため、リダイレクトで取得したら即座にアクセストークンAPIからアクセストークンを取得するように実装してください。

アクセストークンとリフレッシュトークンの利用について

アクセストークンのライフタイム（寿命）は短いものです。
有効期間が過ぎたら、アクセストークンと同時に発行されるリフレッシュトークンから再度、新しいアクセストークン及びリフレッシュトークンを取得します。

📘

アクセストークン及びリフレッシュトークンのライフタイムについて

アクセストークンの有効期限は通常１時間ですが、expires_inの値（秒数）で有効期間を判定する実装をしてください。
リフレッシュトークンの有効期限は十分に長いもの（数ヶ月以上）ですが、仕様として定義しません。これはセキュリティ上の理由などにより、今後変更される可能性があります。

リフレッシュトークンは原則１回のみの利用できます。しかし、リフレッシュトークンを利用してアクセストークンを取得してから、新しく発行されたアクセストークンが利用されるまでは、そのリフレッシュトークンは再利用可能です。
これは例えば、リフレッシュトークンを利用してアクセストークンを取得するAPIをリクエストした時に、ネットワーク障害などで応答内容が戻ってこない場合などに、再度リフレッシュトークンを使って新しいトークンを取得できるようにするためです。

❗️

リフレッシュトークンの重要性

リフレッシュトークンは、用途として、パスワードのようなものであると言えます。
取り扱いには十分にご注意し、厳重に保管してください。例えば、システムのログなどに出力したりしないようにしてください。
これはアクセストークン、リフレッシュトークンにおいても同様に、ログや機密性がそれほど高くないデータベースなどに保管しないでください。

❗️

URLクエリパラメータに機密情報を送信しないでください

URLのクエリーパラメーターに機密情報を送信することは、セキュリティ上の問題があります。
URL のパラメータとして client_secret、access_token または refresh_token を送信しないでください。
詳細については留意点を参照してください。