「認証周りの設計が手戻りになった」手戻りにならないために認証で確認するべきこと

「認証周りの設計が手戻りになった」手戻りにならないために認証で確認するべきこと

タイトルは今入っている現場で実際に起きた事です。

Auth_APIのフローを作ったのですが、OKを貰った構成だとどう考えても『？』な画面デザインが上がってきました。
「これどういう事？」
大枠では似たような話をするチームメンバー。
でも状況を場合分けして「この画面って『A』の場合はこういう事だけど、『B』の場合だとこういう事になるよね」と詳細を詰めていこうとすると、メンバー間で認識が違うことが発覚しました。
企画側ではどう考えているんですか？と投げると超漠然とした答えが…。

手戻りは不徳の致すところですけど、漠然とした状態で作りながら考えるも良いけど、セキュリティも絡む認証くらいはしっかり詰めて考えようぜ。

認証の手戻りの原因は？

これはいくつかのパターンがあると思います。
そんなパターンをまとめてみます。

他にもコード間違えてるとかありますけど、そんなのは置いておきます。
これ、最初の段取りしっかりしていれば、大概の問題は解決できます。

Authに関係する登場人物（端末）を把握/理解する

Authに関係する登場人物とは端末も含みます。
例えば個人のスマホにAPI_Tokenを渡すとします。そのTokenに関係する人物と端末なので、関連する登場人物は下のようになります。

ここに、アプリを通してとなるともう一人増えます。

今回発生した問題はこの登場人物がチーム内でバラバラだった事に原因がありました。

この言葉で、私はアプリに対してTokenを渡すことをイメージし、別の方はユーザーに対してTokenを渡すことをイメージしてました。
で結果として発生したのが【Tokenを記載する画面があるPC向けページのデザイン】これを見て私が「なんじゃそりゃ」となった訳です。

5W1Hをしっかり追う

5W1Hってこれです。
2HにしてコストHow muchが入ることもありますが（課金の話が出ない限り）認証設計では1Hで良いと思います。

また、認証関連では5Wを6W【What to use（なにをつかって）：道具 追加】にして考えるとより良い答えに辿り着けます。
先程の「スマホでTokenを受け取り保存します」のケースで6W1Hを考えてみます。

私の発想

別の方の発想

私はTokenはスマホアプリ固有と考えていたので、ResponceでTokenを渡しサーバー側はハッシュ化して保存の予定でした。
PCで利用なんざ聞いてないし。

認識の差異が生まれた根本原因

５W1Hの確認で理解出来た事は、私と別の方の間には理解している登場人物に差があると言うこと。

私にはこれが見えていないので、私が絵を描こうとすれば無視されます。（感知していないので当然ですよね）
利用者の方が複数の端末でログインする事なんて想定する必要がなかった訳です。

私が考えたフローだと【アプリと関連づけたtoken】なので、再インストールするとアプリのイニシャルが変わるります。
再インストールするとガチャで当てたキャラが飛ぶスマホアプリと同じ構造ですね。
そのため、PCで使えるようにしたとしても、そもそものTokenが異なるのでデータ連携をしません。
まぁね、違う絵面を考えてた人（PCという登場人物を知っていた人）からすると、ダメ出しするよね。

手戻りにならないために認証で確認するべきこと

タイトル回収します。
認証周りを設計するときに、なにに気をつけるべきか。
私なりに取りまとめたのが下の9項目です。

「これだけ」と言えない程度に項目数も作業ボリュームもありますが、手戻りするよりよっぽど単納期で片付くはずです。

まとめ

手戻りは精神的にも辛いですよね。
こういった事を減らすには「1に確認、2に確認」です。

自分がプロジェクトリーダーであり、全ての決定権を持っていたとしても作業する部下はそうではありません。
決定した情報を確認できるスペースの確保は必須だと思います。
「〇〇だと思っていた」が一番NGです。
「〇〇だと知っている」と言える環境を作っていきましょう。

さぁ、手戻り箇所考え直すか。