アプリ内課金

【Google OAUTH2】アクセストークンの最後にドット文字列が付与される

数ヶ月前から少し気になっていた現象。

それは、GoogleAPI の OAUTH で取得したアクセストークンの文字列が何やらおかしいということ。

通常のアクセストークンの最後にドット文字列が付与されているのですよね。

[通常時]
ya29.c.hogefuga

[想定外の現象]
ya29.c.hogefuga. . . . . . . . . .

実際には末尾のドット部分だけで 767 文字もあるので、トークン部分の 223 文字と合わせて 990 文字(バイト)

パディングにしては中途半端ですし、これは一体何かということで調査してみました。
(業務中に結論は出たのですが、もう少し個人的に詳細を追いかけてみます)

アクセストークンの有効性

ちなみに、この末尾のドット文字列を付けていても付けていなくても、トークンとしては有効なものとして扱われます。

Google の API がおかしいのか、Google のクライアントライブラリを通すことによる挙動が変わったのか気になるところです。
(ちなみにライブラリのバージョンは変えていません)

Google API Client Libraries

まずはライブラリ側で情報を探してみましょう。

残念ながら github 上には関連した Issue は挙がっていないようです。

ちなみに、最新バージョンが 2021 年の 9 月 23 日時点で「1.32.1」となっています。

使用しているバージョンは「1.25.1」だったので、最新バージョンに置き換えてみましたが結果は変わらず。

ライブラリのバージョンに依存する現象ではなさそうです。

stackoverflow

困った時の Stack Overflow(スタック・オーバーフロー)ということで、こちらで関連情報を探してみます。

Google API Client Libraries の github の Bug Report の投稿画面にも以下が記載されています。

Please run down the following list and make sure you’ve tried the usual “quick fixes”:

– Search the issues already opened: https://github.com/googleapis/google-api-java-client/issues
– Check for answers on StackOverflow: http://stackoverflow.com/questions/tagged/google-cloud-platform

上から情報を探していくと、以下の情報がヒットしました。

タイトルをザックリ訳すと、「Google Auth2 のアクセストークンは、トークンの後にドットを付けることがあります」とのこと。

これは期待できそうなトピックスですね。じっくりと確認してみましょう。

Google auth2 access token gets dots(.) after the token time to time

質問内容に以下の事象が含まれています。

どうやら私が遭遇した問題と同じようですね。

Then I notice this below issue that API returns ………. after the token. The issue gets from time to time.

API がトークンの後に……….を返すという以下の問題に気付きました。この問題は時々発生します。

postman のスクリーンショットが貼られていますが、完全に同じ状況なので期待が持てそうです。

この質問に対する回答は 1 つだけですが、有益な情報が書かれています。

I found that Google informed customers about the issue via e-mail in May 2021. You can read the mail content, someone shared on the web, see the following link.

Google が 2021 年 5 月に電子メールでこの問題について顧客に通知したことがわかりました。ウェブ上で共有されているメールの内容を読むことができます。次のリンクを参照してください。

いや、そんなメール受け取った記憶はないのですが、Google Cloud Platform ってことは GCP なのかな?

Google experiments changing the token size with placeholder characters (periods) in the “verification phase” but will remove the placeholders and increase the token size at the specified date.

Googleは、「確認フェーズ」でプレースホルダー文字(ピリオド)を使用してトークンサイズを変更することを試みていますが、プレースホルダーを削除し、指定された日付にトークンサイズを増やします。

なるほど。ドットというかピリオドの文字列が付与されるのは意図した挙動のようですね。

Placeholders do not belong to the token. So, removing the padding does not invalidate the token.

プレースホルダーはトークンに属していません。したがって、パディングを削除してもトークンは無効になりません。

そうそう、こちらも確認した内容と一致します。

安心感が出てきたところで、Google からのメールの内容を追いかけてみましょう。

OAuth 2.0 Access Token Size for Google Cloud Platform Customers

Google からのメールの内容が oauth2-proxy の Issue に投稿されていました。

冒頭で、このメールのおかげで自身のライブラリの影響を意識しなくても良いと書かれています。

本当にその通りです。私の時間を返して欲しいですよ・・・。

We’re writing to let you know that on August 23, 2021, we will roll out security and reliability improvements that will increase the sizes of OAuth 2.0 access tokens that your services may be using to call Google Cloud Platform APIs.

2021年8月23日に、サービスがGoogle Cloud PlatformAPIの呼び出しに使用する可能性のあるOAuth2.0アクセストークンのサイズを拡大するセキュリティと信頼性の改善を展開することをお知らせします。

なるほど。ただ、8 月 23 日よりも前から、この施策は展開されていた気がしますが、なんでしょうね。

パディングされた状態なので、正式にアクセストークンのサイズが変わった感じもしないですし。

The access token size increase will only impact services that don’t conform to the access token size limits of 2048 bytes established on Google’s Developer guide and RFC 6749. If your service falls into this category, please continue reading and take action as outlined below.

アクセストークンサイズの増加は、GoogleのデベロッパーガイドとRFC 6749で確立された2048バイトのアクセストークンサイズ制限に準拠していないサービスにのみ影響します。サービスがこのカテゴリに該当する場合は、以下に概説するように読み続けてアクションを実行してください。

アクセストークンの文字数を制限していなければ、特に影響がなさそうなので大丈夫そうですね。

まとめ

Google の OAUTH2 で取得したアクセストークンについて調査しました。

結果、末尾に付与されるドット(ピリオド)の文字列は影響がないことがわかり一安心です。

ただ今回、この調査の過程で以下の問題を見つけました。

・ライブラリの最新バージョンで利用クラスが非推奨(1.31.5 ではそうなっている)
・アクセストークンのクエリパラメータ利用が非推奨(2021年6月)

前者は利用クラスの変更、後者はリクエストヘッダへの埋め込みが求められそうです。

Also, it is good REST practice to avoid creating unnecessary URI parameter names. Note that the query-string support will be deprecated on June 1st, 2021.

Send the access token to an API – Using OAuth 2.0 to Access Google APIs

っと、調査対象とは別の課題が出てきたので、この調査も無駄ではなかったということですね。

他社(外部)の API サービスやライブラリはとても便利ですが、仕様変更に追従していく必要があります。

いきなり利用できなくなるということがないように、定期的にチェックをしておきたいですね。