多くのユーザーが、お気に入りのウェブサイトで使う支払い情報やパスワードを Google アカウントに保存して、簡単にアクセスできるようにしています。しかし最近まで、Chrome でこういった情報にアクセスするのは必ずしも簡単とは限りませんでした。たとえば、（ようやく）ぴったりのホリデーギフトを見つけて購入手続きを始めても、そのデバイスで Chrome の同期をオンにしていない限り、Password Manager に保存したログイン認証情報や、アカウントに追加した支払い方法を使うことはできませんでした。
昨年この点を変更し、Google アカウントの支払い方法に簡単にアクセスできるようにしました。その後も、Chrome から Google アカウントの情報に簡単かつ直感的にアクセスできるようにし、他の機能やユーザーに同じようなログイン体験を提供するための作業を懸命に進めています。そしてうれしいことに、今後の数週間から数か月間で、同期しているかどうかにかかわらず、ログインしているすべてのユーザーが支払いとパスワード管理をシームレスに利用できるようになることをお知らせします。
Android でのログインがさらに便利に
Google アカウントを最大限に活用してもらえるように、まもなく Android 版 Chrome でタップ 1 回でログインできるようになります。この機能は、同期を行っていない場合でも利用できます。Gmail などの Google のサービスにログインする場合は、1 回のタップで認証情報を再入力することなく、デバイスのいずれかの Google アカウントで Chrome にログインできるようになります。デバイスにアカウントを追加せずにログインしたい場合は、単純にダイアログを閉じることもできます。一時的なセッションでブラウジングしたい場合は、メニューからすばやくシークレット モードを開くことができます。
Google アカウントに保存したパスワードにもっと柔軟にアクセスしたいというフィードバックが寄せられています。そこで、今後数か月間で、デバイスを問わず、安全かつ簡単にパスワードにアクセスして管理できるようにします。これは、同期を有効にしているかどうかにかかわらず、Google アカウントにログインするだけで可能になります。アカウントにパスワードを保存してあるサイトでは、そのパスワードを自動入力できます。また、新しくパスワードを保存する場合、Chrome はデバイスと Google アカウントのどちらに保存するかを確認します。アカウントを選択すると、すべてのデバイスからアクセスできるようになります。
// this import should be first in order to load some required settings (like globals and reflect-metadata)
import { platformNativeScriptDynamic } from "nativescript-angular/platform";
import { AppModule } from "./app.module";
import { BackendService } from "./services/backend.service";
import firebase = require("nativescript-plugin-firebase");
firebase.init({
//persist should be set to false as otherwise numbers aren't returned during
livesync
persist: false,
storageBucket: 'gs://giftler-f48c4.appspot.com',
onAuthStateChanged: (data: any) => {
console.log(JSON.stringify(data))
if (data.loggedIn) {
BackendService.token = data.user.uid;
}
else {
BackendService.token = "";
}
}
}).then(
function (instance) {
console.log("firebase.init done");
},
function (error) {
console.log("firebase.init error: " + error);
}
);
platformNativeScriptDynamic().bootstrapModule(AppModule);
handleSnapshot(data: any) {
//empty array, then refill and filter
this._allItems = [];
if (data) {
for (let id in data) {
let result = (Object).assign({id: id}, data[id]);
if(BackendService.token === result.UID){
this._allItems.push(result);
}
}
this.publishUpdates();
}
return this._allItems;
}
Android スマートフォン、iPhone の両方のユーザーがシームレスな認証を行えるように、OAuth やワンクリック Google ログインのサポートが追加された API が新たに作成されました。Android Wear 向けの OAuth API を使うと、ユーザーが時計のボタンをタップしてスマートフォンの認証画面を開き、ウォッチアプリから直接サーバーサイドの API で認証できるようになります。Google ログインを使うと、この操作がさらに簡単になり、どのアカウントで認証するかを選択するだけで、ユーザーの認証が完了します。
スタンドアロンで動作しないウォッチアプリもあります。また、時計とスマートフォンの両方のアプリがインストールされている場合に、よりよいユーザー エクスペリエンスを提供できることもあります。Google は皆さんのフィードバックを入念にチェックし、ペア設定された端末で Play Store を開いてユーザーが簡単にアプリをインストールできるように、2 つの新しい API（PlayStoreAvailability と RemoteIntent）を追加しています。また、新しく追加された RemoteIntent API を使い、時計から操作してスマートフォンでカスタム URL を開くことができます。この操作には、追加のスマートフォン アプリやデータレイヤーは不要です。
// Check Play Store is available
int playStoreAvailabilityOnPhone =
PlayStoreAvailability.getPlayStoreAvailabilityOnPhone(getApplicationContext());
if (playStoreAvailabilityOnPhone == PlayStoreAvailability.PLAY_STORE_ON_PHONE_AVAILABLE) {
// To launch a web URL, setData to Uri.parse("https://g.co/wearpreview")
Intent intent =
new Intent(Intent.ACTION_VIEW)
.addCategory(Intent.CATEGORY_BROWSABLE)
.setData(Uri.parse("market://details?id=com.google.android.wearable.app"));
// mResultReceiver is optional; it can be null.
RemoteIntent.startRemoteActivity(this, intent, mResultReceiver);
}
スワイプで閉じる動作の復活
Android Wear 1.0 のスワイプで閉じる操作は、直感的で時間の節約になるという多くのフィードバックをいただきました。そこで、今回の Developer Preview リリースでは、以前の動作を復活させています。このリリースでスワイプで閉じる操作をサポートするために、次のプラットフォームと API の変更を行っています。
HashMap<string, string=""> validationObject = new HashMap<>();
validationObject.put("token", accessToken);
Response.Listener responseListener = new Response.Listener() {
@Override
public void onResponse(JSONObject response) {
// レスポンスから Firebase カスタム認証トークンを抽出
// ・・・
}
};
JsonObjectRequest fbTokenRequest = new JsonObjectRequest(
Request.Method.POST,
"https:///verifyToken",
new JSONObject(validationObject),
responseListener, errorListener);
NetworkSingleton.getInstance(activity).addToRequestQueue(fbTokenRequest);</string,>
LINE アクセス トークンと Firebase カスタム認証トークンの交換
LINE アクセス トークンを検証し、ユーザーに対応する Firebase カスタム認証トークンを生成するには、サーバーが必要になります。Firebase Node.js Server SDK と Express ウェブサーバーを使うと、シンプルなサーバーを構築できます。
まず、サーバーはユーザーの端末から LINE アクセス トークンを受信し、LINE Social Rest API を使ってそれを検証します。API のレスポンスで忘れずに channelId の値を確認し、アクセス トークンがアプリから発行されていることを検証してください。これは他のアプリやチャンネルのアクセス トークンを再利用してアプリにログインしようとするなりすまし攻撃を防ぐためです。
Instagram アプリの設定で、http://localhost:8080/instagram-callback（テスト用）と https:///instagram-callback（本番用ドメイン）を有効なリダイレクト URI としてホワイトリスト登録しておきます。次に、Instagram クライアント ID とクライアント シークレットをメモします。後でこれが必要になります。
「たった半日で認証を実装することができました。以前は、独自のソリューションの作成には何週間もかかり、プロバイダの API に変更が発生するたびにアップデートしなければなりませんでした」- Amine Laadhari, Fabulous CTO
Malang Studio が Firebase Authentication で商品化までの時間を月単位で短縮
Chu-Day（Android と iOS に対応）は、カップルが重要な日を忘れないようにするためのアプリケーションです。このアプリは、キャラクター中心のゲーム型ライフスタイル アプリケーションを開発している韓国企業 Malang Studio が作成しました。
一般的に、カウントダウンや記念日関係のアプリはユーザーのログインを要求しません。Malang Studio は、カップルをつないで特別な記念日をともにカウントダウンできるようにすることで、Chu-day を特別なアプリにして差別化を図りたいと考えました。しかしこれにはログイン機能が必要で、ユーザーの脱落を防ぐシームレスなログイン プロセスも必要でした。
Malang Studio は、Facebook や Google のログインを利用することで、 1 日で初回起動フローをアプリに組み込むことができました。サーバー側の開発やデータベースについて考える必要はなく、Firebase User Management Console を活用し、ログイン実装の開発やテスト、ユーザーの管理を行うこともできました。
「Firebase Authentication は最低限の設定しか必要としないので、短時間で簡単にソーシャル アカウントへのサインアップが実装できました。コンソールで提供されるユーザー管理機能もすばらしく、簡単に認証システムを実装できました」- Marc Yeongho Kim, Malang Studio CEO 兼 創立者
こんにちは。最近、Android の Google アカウントに関する質問がいくつか寄せられています。そこで、Google が勧めるベスト プラクティスのいくつかを記事にまとめて紹介いたします。今回は、Google Play 開発者サービスの統合によって簡単に実現できる Android ベースの認証に焦点を当てます。では、始めましょう。
表示やキャッシュのために E メールアドレスを保存することに問題はありませんが、ユーザーは、Google アカウントで自身のプライマリー E メール アドレスを変更する可能性があります。そういったことは様々なタイプのアカウントで起きますが、最も頻繁に発生するのが Google Apps For Work アカウントです。
では、デベロッパーはどうしたらよいのでしょうか。Google アカウントに関連付けられているアプリのデータをキーにするときは、アカウント名ではなく、Google アカウント ID を使用します。つまり、たいていのアプリでは、アカウント ID を保存して、onConnected コールバックが呼び出されるたびに、その値を比較するだけでよく、これによって、そのデータが現在ログインしているユーザーとローカルに合致しているかを確認します。API では、アカウント ID をアカウント名から取得できるメソッドを提供しています。参考用に、スニペット例を示します。
[Google Play 開発者サービスの以前のバージョン（クライアントをアップグレードしてください）]
Person currentUser = Plus.PeopleApi.getCurrentPerson(mGoogleApiClient);
String accountID = currentUser.getID();
createLocalAccount(accountID);
こうすることで、ローカルデータは Google アカウント ID と照合されることになります。アカウント ID は ユーザーが E メールアドレスを変更した後でも変わらない固有の識別子です。
よって、上述のケースでは、データが ID をキーとしていれば、ユーザーが E メールアドレスを変更したとしても心配する必要はないのです。ユーザーが再びログインするときも、同じ ID を取得しますので、皆さんの側で何らかのデータ処理をする必要はありません。
複数アカウント
アプリが複数のアカウントによる同時接続をサポートしている場合（たとえば、下に示す Gmail ユーザー インターフェースのようなケース）、GoogleApiClients 構築時には、setAccountName を GoogleApiClient.Builder に対して呼び出します。このとき、アプリ内にそのアカウント名と Google アカウント ID を保存する必要があります。しかし、保存したアカウント名は、ユーザーがプライマリー E メール アドレスを変更すると、違ってしまうことになります。これに対処する最も簡単な方法は、ユーザーに再ログインを促すことです。そしてログイン後に、onConnected がコールされたときにアカウント名を更新します。ログインのたびに、こういったコードを使ってアカウント ID を比較し、そのアカウント ID に対してローカルに保存されている E メールアドレスを更新します。
ウェブ サーバーから Google API コールを行わない場合は、上述の複数アカウントのサンプルコードで参照している updateLocalAccountName メソッドを実装する場合、プライマリー E メールアドレス変更をウェブ サーバーに通知するのは、Android 向けアプリケーションに任せることができるかもしれません。ウェブ サーバーから Google API のコールを行う場合は、おそらくそれはクロス クライアント認証を使って実装したものなので、ウェブ サーバー上の OAuth2 クライアント ライブラリまたは REST エンドポイントを介して変更を検出することもできます。
まとめ
アプリで Google アカウント認証を使用するとき、ユーザーのデータを識別するには、アカウント名ではなくアカウント IDを使うのがベストな方法です。この記事では、アプリを強化するために変更作業が必要となる 3 つのケースを紹介しました。Google for Work の利用が増加しているなか、ユーザーが E メール アドレスを変更しても、アカウント ID は同じまま維持するケースが増えてくると予想されます。よって、デベロッパーの皆さんには、できるだけ早急にコードの更新計画を立てることをお勧めいたします。
