ユーザーの認証操作を簡素化する 4 つの方法

アプリケーションのユーザーにとって、認証ほど面倒な操作は他にあまりありません。認証にまつわるアプリケーションの使いにくさがあると、製品の導入が滞ったり、サポート担当者や製品管理者の負荷が増大したり、場合によっては、セキュリティが低下するおそれがあります。

Okta は、多大な時間をかけて開発者と協力し、より優れた認証フローの設計と構築に努めています。その結果、ユーザーが目的の作業に着手するまでの時間を短縮するのに役立ち、今すぐに実装できるいくつかのシンプルなパターンを発見しました。それでは、ユーザーの認証操作をもっと簡単にするための 4 つの方法をご紹介します。

1) フェデレーションでパスワード入力を減らす

パスワードだけが不満の原因ではないものの、かなり大きな悩みの種です。事実、パスワードリセットとアカウント復元の依頼は、多くのカスタマーサービスデスクで最も多い業務となっています。安全なパスワードは覚えにくいものですが、アプリケーションごとにそれが要求されてはなおさらです。パスワードの使い回しは、攻撃に対する脆弱性を高めます。その一方で、パスワードの使い回しを避けようとするユーザーは、途方もない記憶力を求められてます。

このようなパスワードの問題を解決する優れた方法が、フェデレーションです。フェデレーションでは、Facebook のようなソーシャルアイデンティティプロバイダーやユーザーの所属組織が所有するエンタープライズアイデンティティプロバイダーなどの、ユーザーが信頼するサービスに認証処理をアウトソーシングします。

フェデレーションのログインフローの最適化

多くのアプリケーションは、フェデレーションエクスペリエンスを完全に合理化するレベルには達していません。フェデレーション認証をできるだけ簡単にする鍵は、ユーザーが認証用のアイデンティティプロバイダーからアプリケーションにシームレスに戻れるようにすることです。

消費者の場合は通常、数多くのソーシャル ID を持っているものです。そのため、ユーザーが自分のアカウントの作成に使用した ID を思い出せるように助けることが重要です。ここで効果的なのが、ユーザーのメールアドレスを最初に要求する方法です。ユーザーがメールアドレスを入力すると、自分が登録されているアイデンティティプロバイダーについてのヒントが表示されるか、ユーザーのドメインに基づいた適切な選択肢にサインアップするように促されます。提示されたアイデンティティプロバイダーをクリックすると、そのプロバイダーにログインする操作に進みます。さらに望ましいのは、そのプロバイダーのセッションにユーザーがすでにアクセスしたことがある場合は、以前に作成したアカウントまたはその場で作成したアカウントで直接作業を続行できるようにすることです。

登録に使用したものとは異なるソーシャルアイデンティティプロバイダーでサインインすると、アカウントリンク手順でユーザーが両方の ID を持っていることを確定でき、両方でサインインできるようになります。これは、サインインする際に、必要な情報を思い出そうとする不便さを軽減することになります。

ビジネスの場合でも同様のニーズがあり、「最初にメールアドレス」アプローチはここでも有効です。ユーザーが自分のアドレスを入力すると、認証のためのアイデンティティプロバイダーにリダイレクトされ、ユーザー名とパスワードを何回も入力する必要はありません。

多くの場合、必要のないログイン手順を要求するアプリケーションを目にします。たとえば、ブラウザでユーザーに資格情報の入力を許可する前に「シングルサインオン」ボタンが表示されるというミスがよく見られます。アプリケーションに課せられているのは、ユーザーを適切なアイデンティティプロバイダーに転送する処理です。

フェデレーションに関連する問題点の多くを解決する、この「最初にメールアドレス」パターンの実装をご検討ください。

2) 製品エクスペリエンス全体を 1 つの ID で統一する

アプリケーションは急速にモジュール化しており、製品コンポーネントを組み合わせてエクスペリエンスを構築する開発元が増えています。たとえば、カスタマーサービスには Zendesk や Service Cloud、オンラインのユーザー/カスタマーコミュニティには Jive、Lithium、Salesforce Communities という具合です。多くの場合、1 つの製品は異なるアプリケーションの組み合わせで構成されており、各アプリケーションは別々のチームが開発しています。

製品のコンポーネントごとにユーザーのサインインを要求すると、それだけユーザーが覚えるべき資格情報が増えます。さらに、製品の開発元は通常、各コンポーネントが製品としてシームレスに見えるように、製品の共通ブランドイメージを植え付けようと多大な努力を行っています。ユーザーにとっては、資格情報を求めているのが製品のどの部分なのか混乱するのも当然です。

モジュール型のシナリオでは、要素間で一貫してユーザーのコンテキストを伝えることも重要です。権利、アクセスポリシーなどのプロファイル主導型のコンテキストは、製品全体を通じて同一である必要があります。

シングルサインオンは、アプリケーションのすべての構成要素を 1 つのログイン認証手順および 1 つのセッションに統合するのに役立ちます。アイデンティティプロバイダーが、ユーザーにとって唯一の信頼できる情報(プロファイル情報、アクセス権など)の供給源となります。この情報が、製品の各部分にアクセスする際に渡されます。

3) モバイルプッシュで多要素認証を合理化する

ワンタイムパスワードは、おそらく最も普及した多要素認証の方法です。ユーザーが自分の携帯電話にアプリケーションをインストールするか、ユーザーに時間ベースコードの生成デバイスが支給されます。サインインする際は、短い有効期限内にこのコードを入力する必要があります。

しかし、この方法では、エクスペリエンス面で多くの不便さが残ります。ユーザーはせわしなく視線を行き来させながら、ログイン画面で一度に 2、3 個の数字を入力する操作を時間内に完了させるよう追い立てられるという課題が残ります。

スマートフォンの普及によって有力な代替手段になってきたのが、モバイルプッシュです。インストールすると、最初のログイン時にアプリケーションからユーザーのデバイスに通知を送信できます。ユーザーは自分の携帯電話やスマートウォッチで 1 回タップして、その要求を承認または拒否できます。

4) パスワードレス認証を導入する

パスワードをまったく使わない新しいアプローチに適したアプリケーションもあります。パスワードレス認証では、ユーザーが識別子を入力すると、メールまたは SMS 経由でワンタイムトークンが送付されます。ユーザーはそのトークンの有効期限が切れる前に一度だけサインインできます。

この設計の優れたところは、資格情報を発行して管理する代わりに、簡略化してアカウント復元プロセスを用いる点にあります。これによって、プロセスでパスワードを設定したり更新したりする面倒な手順を不要にできます。めったに使用しないアプリケーションの資格情報は特に忘れがちですが、パスワードレス認証はそのような場合に最適です。

ログイン連携機能の導入から考える、明るい将来

これらのアイデアは、ユーザーの業務をすぐに改善するのに役立つでしょう。現時点ではまだパスワードをすべて廃止できる段階には至っていませんが、今後の可能性については期待できます。モバイルデバイスと TouchID のような生体認証が広く導入されることによって、ログインユーザーエクスペリエンスは大きく進歩します。たとえば、ユーザーの場所、行動、生体情報に関するコンテキストをもっと取り入れて、リソースへのアクセスをシームレスにするか、さらに複雑または面倒な認証手順を要求するかを状況によって使い分ける、適応型リスクベースモデルを開発できます。この分野に注目していてください。