ウェブサイトのさまざまな「認証方式」をまとめて比較した結果がコレ

ユーザーごとに異なるデータを提供するため、ログイン機能を搭載しているウェブサイトは多数存在します。しかし、ユーザー側はウェブサイトに搭載されたログイン機能の「認証方式」まで気にすることはあまりないはず。そんなウェブサイトの認証方式について、代表的な6つの方式をエンジニアのAmal Shaji氏が解説しています。

Web Authentication Methods Compared | TestDriven.io
https://testdriven.io/blog/web-authentication-methods/

◆ベーシック認証
HTTPの中に組み込まれているベーシック認証は、最も基本的な認証方式です。ベーシック認証に暗号化機能はなく、Base64でエンコードされたユーザーIDとパスワードをクライアントからサーバーに送信するとのこと。

認証フローはこんな感じ。まずクライアントはサーバーに未認証のリクエストを送り、サーバーは401エラーを返答します。その後クライアントがユーザーIDとパスワードを送信すると、サーバーにアクセスできるようになります。

ベーシック認証のメリットとしては、実装が容易な点や多くのブラウザが対応している点などがあげられます。反対に、暗号化に非対応である点、リクエストごとに毎回認証を行う必要がある点などがデメリットであるとのこと。

◆Digest認証
Digest認証はベーシック認証と同じくHTTPに組み込まれていますが、パスワードをMD5でハッシュ化するため、ベーシック認証よりも高いセキュリティを実現できるとShaji氏は説明。認証フローはベーシック認証とほぼ同じですが、MD5によるパスワードのハッシュ化に利用されるノンスをサーバーとクライアントでやり取りしている点が異なります。

Digest認証はベーシック認証の利点に加えて、MD5のハッシュ化によるセキュリティ向上がメリット。しかし、リクエストごとに認証を行う必要がある点はベーシック認証と変わらず、さらにサーバー側のユーザーIDとパスワードは平文で保存されているため、サーバー側のセキュリティはベーシック認証に劣るとのこと。また、中間者攻撃にも脆弱(ぜいじゃく)であると説明されています。

◆セッションベース認証
セッションベース認証はCookieを用いて行う認証方式で、ベーシック認証やDigest認証のようにリクエストのたびにユーザーIDとパスワードを送受信する必要がありません。認証フローとしては、最初にクライアントからサーバーに認証情報を送信し、サーバー側で正しく認証されればサーバー側でセッションを生成。サーバーはクライアントにセッションCookieを送信し、クライアントはそのCookieとともにリクエストを送る限りは、サーバーにアクセスすることが可能です。

セッションベース認証のメリットは、リクエストのたびに認証情報を送る必要がないため、ログイン後の処理が高速である点。また、豊富なフレームワークが存在するため、実装が容易である点もメリットとしてあげられています。デメリットはサーバー側で認証情報を保持したままである点、認証が必要なくてもCookieをリクエスト毎に送信する必要がある点、クロスサイトリクエストフォージェリに弱い点があるとのこと。

◆トークンベース認証
トークンベース認証は、先ほどのセッションベース認証で用いていたCookieの代わりに、トークンを利用します。トークンはサーバーの秘密鍵で署名されており、クライアントはサーバーから受け取ったトークンとともにリクエストを送信するという認証フローになっています。サーバーは署名が正しいかどうかを確認するだけでよいため、認証情報をサーバー側で保持する必要がないとのこと。

トークンベース認証は、サーバー側で認証情報を保持しないステートレスな認証方式であるため、高速な通信を実現できるとShaji氏は説明。マイクロサービスとも相性がよいとのこと。

トークンベース認証のデメリットとしては、クライアントの情報保持の方法によってはクロスサイトスクリプティングやクロスサイトリクエストフォージェリの被害を受ける可能性がある点、トークンは有効期限が過ぎるまでは削除できないため、もしトークンが漏えいした場合は攻撃者が悪用できる点があるとShaji氏は語っています。

◆ワンタイムパスワード
ログインを行う際、一度だけ利用できるパスワードを発行するのがワンタイムパスワードです。ワンタイムパスワードは、メールアドレスや電話番号など、「確実にアカウント所有者だけが利用できる」と信頼できるシステムを利用し、セキュリティの層をひとつ追加できる点が特徴。オンラインバンキングなどでも利用されるほど高いセキュリティがメリットですが、信頼できるシステムが故障やバッテリー切れで利用できなくなった場合、認証できなくなるといったデメリットもあります。

◆OAuth・OpenID
OAuthやOpenIDといった認証プロトコル標準は、「クライアントが誰か」といった認証機能の他にも、「クライアントに何を許可するか」という権限管理機能も持っています。また、GoogleやTwitter、FacebookなどのSNSアカウントを利用したログイン機能を実装することも可能であり、パスワードを保持せず高いセキュリティを実現することができるとのこと。

OAuthやOpenIDによる認証のメリットとして、Shaji氏は高いセキュリティや新しくアカウントを作成する必要がない点、パスワードを保有しないため、第三者からの攻撃を受けても無害である点を列挙。デメリットとしては他のシステムに頼る部分が生じてしまう点、権限の確認がユーザー側で見過ごされやすい点、SNSアカウントを持っていない人は利用できない点があげられています。

また、Shaji氏は採用する認証方式を決める際には、以下の基準に従えばよいと語っています。

・サーバーサイドのテンプレートを利用するアプリケーション：セッションベース認証。OAuthやOpenIDを追加するのもよい
・REST API：トークンベース認証
・高度な機密情報を扱う場合：ワンタイムパスワードを追加