GoogleのCross-client Identity
https://developers.google.com/accounts/docs/CrossClientAuth
別件でGoogleのAPIを調べていたんだけど、Cross-Client Identityという仕組みができたらしい。
どうやらWebサーバーでOAuth認可認証を行うと、モバイル側ではユーザーに認可認証させなくてもよいらしい。
追記: これは逆でモバイルで認可を行うとWeb側でも認可する仕組みっぽい。やりたいのと逆。
ざくっと読んだ感じ。
ウェブアプリとクライアントアプリのクライアントID,シークレットを作成しておく。
ウェブアプリでOAuth2認可認証をさせておく。クライアントアプリで認可認証する際にclient_idやらscopeとアカウント(Googleアカウント)を指定してごにょごにょして送ると、タブレット側ではユーザーに認可認証させずに終わるらしい。
いくつか条件があってウェブ用とクライアント用のキーを同じプロジェクトで作成する。
クライアントアプリのスコープは、ウェブアプリのスコープのサブセットの様子。
これは実は使いたい。ウェブで認可認証させれば、クライアント側は認可認証させなくてもよいというのは便利。特にいまやっている製品は各タブレットでGoogleのOAuth認可認証させているのでセットアップが面倒くさい。
Google Driveで比較的わかりやすいわかりやすそうなデモがある。（まだ試していない)
https://github.com/googledrive/crossclientoauth2-android
追記:
id:ritouに解説記事書いてもらった。
http://d.hatena.ne.jp/ritou/20131215/1387114182
認証って書いてあるところを指摘されたので認可に修正した。
ちょっと実際の細かなフローとかまだよくわかっていないのでデモをちゃんと読んでみる必要あり。
私は「クライアント側ではAuthrization Codeもらって、それをバックエンドのWebサーバーに送ってそっちでやれ派」の立場をとっていましたが、それと同じ感じです。
ここがいちばんイメージがつきやすかった。
下記の文がなんなのかよくわかってなかったのだけど、
When it exchanges the code for tokens, it should not include the redirect_uri argument in the POST.
codeもらってサーバーに送るからredirect_uriを指定しないのね。
It is important that the Android app never attempt to exchange the code for a refresh token on its own. This would require that the app store the server's client ID and client secret. Since apps can be easily decomposed, including these in your app is insecure.
で、この部分も以降refreshするにはサーバーのクライアントIDとシークレットが必要だし、サーバーのシークレットをモバイルがもってるとすればそれは安全じゃないってことになるのかな。
refreshとかどうすんの?っておもったけど、それはサーバー側でやるらしい。
