Google OAuth2承認フローを理解しよう。

Google OAuth2承認フロー

Google が提供している様々なサービスやAPIを利用するためにはGoogle に対してOAuth2承認を行う必要があります。まずOAuth2の承認フローを理解しましょう。

最もシンプルな承認フロー

以下の承認フローはネイティブアプリからGoogleの各サービスを利用する時の最もシンプルなOAuth2承認フローです。



上のフローではユーザーに承認画面を表示して、アクセストークンを取得して、GoogleのAPIを呼び出すまでの一連のOAuth2承認処理を示しています。しかし、これだけではユーザーがアプリを起動する度に承認しなければなりません。可能であればユーザービリティを考え、無駄な承認を避けたいですね。

これを解決するためには、初めてアプリが起動された時に取得したアクセストークンをアプリ(DBや外部ファイル)で保持し、2回目以後起動された時には承認画面を表示せずに前回のアクセストークンを使ってサービスプロバイダーのAPIを呼び出す必要があります。

トークンを保持するためのフロー

まずはアプリをインストールして初めて起動された時(アプリがまだアクセストークンを保持していない)のフローを以下に示します。この時、アクセストークンがまだDBに存在しないため、承認画面を表示して承認処理をユーザーに要求します。ユーザーの承認が完了後に、アクセストークンとリフレッシュトークンをサービスプロバイダーから取得してDBに保持します。(リフレッシュトークンはアクセストークンが期限切れになった場合、再度承認処理せずに新しいアクセストークンを取得するためのトークンです。通常、アクセストークンと一緒に取得できます。)


次に、2回目以後アプリが起動された場合のフローを考えてみます。この時、アクセストークンがDBから取得できるため、承認画面を表示せずに前回のアクセストークンを使ってAPIを呼び出します。ここで注意しないといけないのは、アクセストークンには有効期限があり、有効期限切れになった場合はリフレッシュトークンを使って再取得する必要があります。実際のフローは以下のようになります。


リフレッシュトークンが期限切れになった場合のフロー

最後に、リフレッシュトークンにも期限があり、リフレッシュトークンが有効期限切れになった場合は、ユーザーに再度承認してもらう必要があります。この場合のフローは以下です。


終わり

ここまで読んで頂きありがとうございました。次回はGoogle OAuth2を使えるために、Google APIs Consoleでの Projectの作成について説明します。


<