認可コードからアクセストークンを取得する
OAuth 2.0のフローで、ゲストユーザーが認可すると、指定されたリダイレクトURIにリダイレクトされ、パラメータとして認可コード(code)が発行されます。
上記のAPIを利用し、認可コードから、アクセストークン、およびリフレッシュトークンを取得します。
なお、セキュリティ上の目的もありますが、認可コードの有効期間は十分に短いため、リダイレクトで取得したら即座にアクセストークンAPIからアクセストークンを取得するように実装してください。
アクセストークンとリフレッシュトークンの利用について
アクセストークンのライフタイム(寿命)は短いものです。
有効期間が過ぎたら、アクセストークンと同時に発行されるリフレッシュトークンから再度、新しいアクセストークン及びリフレッシュトークンを取得します。
アクセストークン及びリフレッシュトークンのライフタイムについて
アクセストークンの有効期限は通常1時間ですが、
expires_in
の値(秒数)で有効期間を判定する実装をしてください。
リフレッシュトークンの有効期限は十分に長いもの(数ヶ月以上)ですが、仕様として定義しません。これはセキュリティ上の理由などにより、今後変更される可能性があります。
リフレッシュトークンは原則1回のみの利用できます。しかし、リフレッシュトークンを利用してアクセストークンを取得してから、新しく発行されたアクセストークンが利用されるまでは、そのリフレッシュトークンは再利用可能です。
これは例えば、リフレッシュトークンを利用してアクセストークンを取得するAPIをリクエストした時に、ネットワーク障害などで応答内容が戻ってこない場合などに、再度リフレッシュトークンを使って新しいトークンを取得できるようにするためです。
リフレッシュトークンの重要性
リフレッシュトークンは、用途として、パスワードのようなものであると言えます。
取り扱いには十分にご注意し、厳重に保管してください。例えば、システムのログなどに出力したりしないようにしてください。
これはアクセストークン、リフレッシュトークンにおいても同様に、ログや機密性がそれほど高くないデータベースなどに保管しないでください。
URLクエリパラメータに機密情報を送信しないでください
URLのクエリーパラメーターに機密情報を送信することは、セキュリティ上の問題があります。
URL のパラメータとしてclient_secret
、access_token
またはrefresh_token
を送信しないでください。
詳細については留意点を参照してください。