「いくつもある認証方式のどれを採用したら良いのかわからない…」「Eメールアドレスとパスワードだけでは足りないの？」といった疑問を持たれている方は多いのではないかと思います。
そんな方に向けて、メジャーもしくは少しマイナーだけど知っているとアイデアの可能性を広げてくれるかもしれない認証方式をまとめてご紹介します。
想定読者 – 企業のDXの活動において、社内もしくは顧客向けのウェブサービスを展開しようと推進/企画されている方
目次
ユーザーIDとパスワードによる認証
ユーザーID(e.g. ランダムな文字列, Eメールアドレス, ニックネーム)とパスワードを入力する方式。
ウェブサイトにユーザーがログインして情報を更新したりする機能が広く普及し始めた1990年代には、通信径路上のパスワードが第三者に見えていたり、データベース上に平文(もしくは簡易なハッシュ化)で保存されていたり、現在では考えられないほど簡素な仕組みで認証の仕組みが実装されていました。当時から20年以上経った現在(2022年)にも、パスワードを忘れたと問い合わせたらサポートの人がパスワードを閲覧できる状態のウェブサービスが発見され話題になることがあります。そうなるとウェブサービスを運営している会社の信頼も当然落ちてしまいます。
また、ユーザーが覚えやすいパスワードを設定してしまう問題があります。例えば「英数字、記号を最低1つ、8〜16文字」のような制約を設けたとしても、多くの人は自分が覚えやすいようなもの、例えば記念日のようなもの、を含めてパスワードを作成して情報量が落ちてしまったり、メモ帳に書いていたりすることで悪意のある人に特定されてしまうリスクがあります。そのため、パスワードとワンタイムトークンといった複数の情報を組み合わせてリスクを低減するMFA(多要素認証)が普及しています。
ワンタイムトークン認証
携帯電話のショートメッセージやEメール等にワンタイムトークンを送信し、ウェブサービスで入力する方式。
ワンタイムトークンがウェブサービスを閲覧しているデバイス(e.g. PC)とは異なるデバイス(e.g. 携帯電話)に送信されることと、ワンタイムトークンの有効期限は数十秒から数分と短いことで、パスワードに比べれば悪意あるユーザーのなりすましを防ぐことができます。
ですが、携帯端末が盗まれる可能性がないと言い切れないためこれ一つでは不安が残るかもしれません。また、全ての人が携帯端末を持っているとは限らないため、要件によってはバックアップとして他の方式を用意しておく必要があります。
URL認証
Eメール等に一定期間有効なURLを送信し、それをウェブブラウザで開くと認証が完了する方式。
ワンタイムトークンに比べるとユーザーの手間は減る一方、送られてきたURLをクリックするのはリスクがあり、この方式が広く広まった場合に、なんの疑念もなくURLをクリックしてしまうユーザーが増えてしまうのではないかと想像するとオススメはできません。
携帯端末上のアプリを経由した認証
ユーザーがPCからウェブサービスにログインしようとしたタイミングで、ユーザーの持つ携帯端末に事前にインストールされた専用のアプリケーションが開き操作(e.g. ボタンのクリック)を要求する方式。
ワンタイムトークン同様、携帯端末を紛失した場合にウェブサービスにログインできなくなってしまうため、要件によってはバックアップ方式の用意が必要です。
ICカード等のハードウェアを利用した認証
ユーザーがPCからウェブサービスにログインしようとしたタイミングで、事前に設定されたICカードリーダーにICカードを読み込ませる方式。
一昔前までは、ウェブブラウザが直接ICカードリーダーにアクセスすることはセキュリティ上許可されなかったのですが、ここ数年で規格が整備され利用可能になりました(WebAuthn)。ICカードの発行コスト、ユーザーの手間は他の方式に比べて高いですが、逆にそれだけ手間をかけないとログインさせたくないといった要件にはマッチするかもしれません。
生体情報を利用した認証
指紋や虹彩で個人を識別する方式。
ICカード同様、WebAuthnを利用して生体情報読み取り用デバイス経由で生体情報を取得します。
携帯端末よりも紛失や盗難の可能性が低いですが、ログインのハードルが上がるためユーザーの利用頻度が落ちてしまうリスクがあります。
他サービスを経由した認証(ソーシャルログイン)
ユーザーがウェブサービスにログインしようとしたタイミングで、他サービス(e.g. LINEやTwitter)に遷移し、他サービス側に認証を委ねる方式。
自前で認証の仕組みを持たない分、低コストで認証が実現できます。ただし、ユーザーが他サービスのアカウントを持っていることが前提になります。また、その外部サービスが停止した場合には連動してログインができなくなるリスクがあるため、要件によってはバックアップ方式の用意が必要です。
IDaaSを経由した認証
ユーザーがウェブサービスにログインしようとしたタイミングで、IDaaS(e.g. Okta, Auth0)に遷移、もしくはユーザーに見えない形で内部的にIDaaSと通信し、IDaaSに認証を委ねる方式。
IDaaSはID管理(e.g. 認証, 認可)に特化したサービスのため、高いセキュリティ要件の実装、安定した稼働、新しい認証方式への追随を外部に委ねることができます。
社内IDプロバイダーを経由した認証
ユーザーがウェブサービスにログインしようとしたタイミングで、社内IDプロバイダーに遷移、もしくはユーザーに見えない形で内部的にIDプロバイダーと通信し、IDプロバイダーに認証を委ねる方式。
社内でIDプロバイダーを運用している場合、第一に検討すべきは社内IDプロバイダーの利用と考えます。さらに作りたいサービスがインターネットに公開出来ない社内用のものだとすると、このIDプロバイダーを利用することになる可能性が高いでしょう。
番外編
定期的なパスワード変更
一昔前は定期的なパスワード変更を良しとする風習がありましたが、現在は定期的なパスワード変更は要求すべきでないとされています。
ボット防止機能
ログイン時に「私はロボットではありません」といったチェックボックスやパズルを解かせる仕組みがありますが、これらは機械的なウェブサイトへのアクセスによるシステムへの負荷、悪意のある操作を防ぐといった目的で設置されています。この仕組みはほとんどのサービスで必要にならない上にUXを損なうため、必要になった段階での導入が良いでしょう。またIDaaSには、セキュリティ上リスクがあると動的に判断し必要なタイミングでこれらを要求するといった仕組みが用意されています。
パスワード強度
パスワードは意味の無い文字列で長ければ長い程良いとされていますが、ユーザーが覚えられずにノートにメモしてしまうのでは本末転倒です。要件によってはMFA、パスワードレスの検討も必要です。ITリテラシーの高いユーザーや、1Passwordのようなツールを利用するユーザーのために、最大パスワード長は可能な限り長くしておくことをおすすめします。
相関図
上述した認証方式を「信用度」「UX」「開発コスト」の観点で1枚にまとめました。
認証方式を決めるためにはこれ以外にも多くの判断材料が必要ですが、あくまでも主観的な図とお断りさせていただいた上で、方針決めの参考になれば嬉しいです。
Contributed by Yuki Sanada
TC3について
Okta、Auth0、AWS Cognitoを多数のウェブサービスに導入、既存社内IDプロバイダーとのシングルサインオン連携、またプライベートクラウド向けのIDプロバイダー(Keycloak)の実装/運用といったウェブアプリケーション/ウェブサービスの認証認可を得意としています。また、KeycloakのようなOSSが出る以前にIDプロバイダーのスクラッチ実装の実績がある社員も在籍しております。
ご検討の段階から、どのようにIDaaS/EIAM/CIAMを導入するかについてもサポートさせていただきますので、お気軽にお問い合わせください。詳しくは『デジタル顧客接点トータルサービス』をご覧ください。
ご紹介資料は以下からもダウンロードいただけます。
