Androidのアカウントマネージャー経由のOAuth2は本当にユーザーフレンドリーなのか?
先日、Androidのアカウントマネージャー経由のOAuth2で、複数スコープの指定をするとパスワードを求める画面になり、正しいパスワードを入力しても受け付けてもらえない問題があることがわかった。
琴線探査: AndroidのAccountManagerを使ったOAuth2認証は何だか怪しい
その後、ドキュメントをよくよく見ると、こんな記述を見つけた。
AccountManager.getAuthToken()
Googleでも、Gmailにアクセスする時とGoogleカレンダーにアクセスする時では、同じアカウントでも別のAuthTokenを使っているとのこと。つまり、どうやら一度に複数のスコープ指定ができないらしい。
試しに「プロフィール情報」と「Google AdSense」にアクセスする時にそれぞれ別のAuthTokenを使うようにしたテストアプリを作ってみたら、どちらにもアクセスできた。
AuthTokenをサービスごとに別にするなんて普通じゃない。考えもしなかった。ていうか、OAuth2で言うところの「AccessToken」と「AuthToken」は似たようなものだろうと思ってたけど全くの別物なのかも。
また、アカウントマネージャー経由でアクセス許可をもらった場合、ユーザーアカウントの許可アプリリストにこのように表示されることからも、アカウントマネージャ経由のOAuth2は特殊なOAuth2だと言えると思う。
許可アプリリストの出し方の参考:明日に向かって昇龍拳: Googleアカウントへ接続を許可したアプリを調べる
この許可アプリリストで「Android — Google Analytics」と表示される場合はどういうことを意味するかというと、アプリがAndroidのシステムで、接続許可サービスがAnalyticsということになる。
要するに、その端末上の何かのアプリでAnalyticsへのアクセスを許可した場合、次にAnalyticsへアクセスしようとしたアプリでは接続許可画面が出ず、即アクセスできるようになるということだ。
実際にアカウントマネージャ経由でAnalyticsにアクセスする複数のアプリを動作させたところ、接続許可を求められるのは初めに起動したアプリだけで、その後のアプリでは接続許可を求められなかった。
逆に言うと、許可アプリリストで「Android — Google Analytics」のアクセスを取り消すということは、そのAndroidの端末からAnalyticsへの接続を全て拒否するということだ。
つまり、アカウントマネージャー経由のOAuth2の問題点のひとつは、ユーザーがアプリごとに接続を許可したり拒否したりできないということだ。
アカウントマネージャーを使うと、確かにユーザーのIDとパスワードを入力してもらう手間を省くことができるので、一見ユーザーフレンドリーに見える。しかし、このような認証システムは本当にユーザーフレンドリーと言えるのだろうか。
一方、「Flipboard」はGoogleリーダーへのOAuth2認証をする時にアカウントマネージャーを使わずにWebViewを使って行う。WebViewでOAuth2認証をした場合、許可アプリリストではこのように表示される。
確かにIDとパスワードの入力は面倒だけど、認証時にそのアプリがどのようなアクセス権限を求めているのか簡単な説明文でわかる(アカウントマネージャーでは良くてサービス名、悪くするとURLそのまんま)し、上のように許可アプリリストにアプリ名がちゃんと出る。
さて、アカウントマネージャー経由とWebView経由、どちらが本当の意味でユーザーフレンドリーなのだろうか?
うーん。考えどころだ。
琴線探査: AndroidのAccountManagerを使ったOAuth2認証は何だか怪しい
その後、ドキュメントをよくよく見ると、こんな記述を見つけた。
AccountManager.getAuthToken()
・・・Some services use different token types to access different functionality -- for example, Google uses different auth tokens to access Gmail and Google Calendar for the same account.・・・
Googleでも、Gmailにアクセスする時とGoogleカレンダーにアクセスする時では、同じアカウントでも別のAuthTokenを使っているとのこと。つまり、どうやら一度に複数のスコープ指定ができないらしい。
試しに「プロフィール情報」と「Google AdSense」にアクセスする時にそれぞれ別のAuthTokenを使うようにしたテストアプリを作ってみたら、どちらにもアクセスできた。
AuthTokenをサービスごとに別にするなんて普通じゃない。考えもしなかった。ていうか、OAuth2で言うところの「AccessToken」と「AuthToken」は似たようなものだろうと思ってたけど全くの別物なのかも。
また、アカウントマネージャー経由でアクセス許可をもらった場合、ユーザーアカウントの許可アプリリストにこのように表示されることからも、アカウントマネージャ経由のOAuth2は特殊なOAuth2だと言えると思う。
許可アプリリストの出し方の参考:明日に向かって昇龍拳: Googleアカウントへ接続を許可したアプリを調べる
この許可アプリリストで「Android — Google Analytics」と表示される場合はどういうことを意味するかというと、アプリがAndroidのシステムで、接続許可サービスがAnalyticsということになる。
要するに、その端末上の何かのアプリでAnalyticsへのアクセスを許可した場合、次にAnalyticsへアクセスしようとしたアプリでは接続許可画面が出ず、即アクセスできるようになるということだ。
実際にアカウントマネージャ経由でAnalyticsにアクセスする複数のアプリを動作させたところ、接続許可を求められるのは初めに起動したアプリだけで、その後のアプリでは接続許可を求められなかった。
逆に言うと、許可アプリリストで「Android — Google Analytics」のアクセスを取り消すということは、そのAndroidの端末からAnalyticsへの接続を全て拒否するということだ。
つまり、アカウントマネージャー経由のOAuth2の問題点のひとつは、ユーザーがアプリごとに接続を許可したり拒否したりできないということだ。
アカウントマネージャーを使うと、確かにユーザーのIDとパスワードを入力してもらう手間を省くことができるので、一見ユーザーフレンドリーに見える。しかし、このような認証システムは本当にユーザーフレンドリーと言えるのだろうか。
一方、「Flipboard」はGoogleリーダーへのOAuth2認証をする時にアカウントマネージャーを使わずにWebViewを使って行う。WebViewでOAuth2認証をした場合、許可アプリリストではこのように表示される。
確かにIDとパスワードの入力は面倒だけど、認証時にそのアプリがどのようなアクセス権限を求めているのか簡単な説明文でわかる(アカウントマネージャーでは良くてサービス名、悪くするとURLそのまんま)し、上のように許可アプリリストにアプリ名がちゃんと出る。
さて、アカウントマネージャー経由とWebView経由、どちらが本当の意味でユーザーフレンドリーなのだろうか?
うーん。考えどころだ。
コメント
コメントを投稿