ウェブサイトの様々な「認証方式」を一緒に比較した結果がこれ – GIGAZINE

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

Web認証方法の比較| 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：トークンベースの認証
機密情報を扱う場合：使い捨てパスワードを追加