ユーザー認証の仕組みを簡単にする4つの方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Oktaでは、さまざまな認証に関するソリューションを提供しています。Oktaのフリートライアルはこちらからご覧ください。