この記事は個人の見解であり、所属する組織の公式見解ではありません。

辛い思い出ありますので言えますが、ユーザー認証はクライアント側のパスワード保存に依存してはいけません ^^; 通常認証に使わなくても、IDFVとかのバックアップ用端末->アカウント紐付き情報を取ってね。

数千人、数万人のクライアント側パスワード情報がバグによって同時に消えることありますので^^

ゲーム滅亡を避けましょう^^

実際にあった話

うちのチームのローンチ時に起きました。

数千人のクライアント側パスワード情報が同時に消されました。

IDFV情報を持っていたおかげでユーザーログインに影響なかったですが、その情報がなかったら数千人がCSに連絡するor二度とプレイできません。ゲームの規模がより大きくて数万人、数十万人の被害者が出た場合、地獄を想像します ^^;

##滅亡の作り方

名前/PWがないとユーザー認証できない仕組み

クライアント端末とサーバーアカウントを紐づけるのは、クライアント側のキーチェインに保存するユーザー名とパスワード。のみ。IDFVとははサーバーが保存しません。

//サーバー側のユーザー情報でPWを保存しますが、IDFVとかを保存しません
CREATE TABLE `USER_INFO` (
  `USER_ID` varchar(32) NOT NULL COMMENT 'ユーザーID',
  `PASSWORD` varchar(32) NOT NULL COMMENT 'パスワード',
  //...
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='ユーザー情報';

###クライアント側名前/PWリセットロジック
クライアント側に「ユーザー情報がサーバーにない場合、クライアント側ユーザー名とパスワード情報をリセット（==削除）する」ロジックを置きます。

こんなロジックは珍しくないです - 開発環境等でたまたまDBがリセットされていますので、デザイナーとテスターから「簡単にクライアントをリセットさせて」の要望がよく来ます。

//ログインAPIを叩いてみる
error_message = login_to_server();
//サーバーにユーザーが存在しない場合...
if(error_message == USER_NOT_FOUND) {
     delete_password_from_keychain(); //...認証用名前/PWを削除
}

サーバー側バグ（一つ）

負荷とかによってサーバーがDBに繋がれない時、例外とかじゃなくてUSER_NOT_FOUNDレスポンスを返します。

//ユーザーIDからユーザー情報を取得
try {
     $user = get_user_info($user_id);
} catch (Exception $e) { //<-- バグはここ - 例外種類を確認ぜす、どんな例外でもUSER_NOT_FOUNDを返す
     return new Response(USER_NOT_FOUND);
}

##滅亡への流れ

本番が公開されて、最初の日から人気
人気なので、負荷でDBが落ちてしまう
DBが落ちたせいで、ログインAPIはUSER_NOT_FOUNDレスポンスを返す
クライアント側がユーザーの名前とパスワードを削除する
数分に数千、数万人がログインAPIを叩いてパスワードをなくす
滅亡

「実際の話」は他のゲームでも意外と起きられる理由

「実際の話」系現象は、うちと関係ないチームでもまた起きたらしいです - 間違いなくバグですが、初心者チームで負荷時レスポンスは確認されない時が多いです（別な話ですが、負荷テストが大事！）

なお、「実際の話」より恐ろしいなのは、上記以外のバグもpw削除を呼び起こせます。クライアント側ロジックミス、pw上書きなど。特定なシチュエーションで潜んだバグが動き始める場合、同時に数万人のpwが消える結果は同じです。

#対策

こちらの対策として、端末に保存するもの以外の緊急紐付きを用意する - IDFVとか、Facebookアカウントとか。

IDFVも100%信頼できません。どんなIDでも、事情によって問題が起きるかもしれません（数年前の例ですがいきなりAppleがAdvertising IDの利用を禁止にしました - 間違って認証内でAdvertising IDを使っていたゲームはいきなり申請通らなくなりました）。ですが、重要なのは、IDFVとキーチェインデータの両方が同時に使えなくなる可能性はかなり低いです。（と信じたい ^^; ）問題があったら、どれかから復活でるはずです。（と信じたい ^^; ）

あと、まあ負荷テストは大事ですね^^