[プロジェクトレベルの面接の質問] フロントエンド認証について詳しく話していただけますか?

「あなたは何年も開発を続けてきましたが、フロントエンド認証について詳しく話してもらえますか?」と尋ねられた場合は、どう答えるべきか、頭の中に完全なアイデアはありますか?

トークン、クッキー、セッション、JWT、シングルサインオンなどの概念とその機能、応用シナリオ、使い方や保存方法、セキュリティの確保方法などを扱えますか？

デジタル管理プラットフォーム
Vue3+Vite+VueRouter+Pinia+Axios+ElementPlus
個人ブログ

もう一つの例は、認証、認可、認証、権限制御とそれらの関係ですが、本当に理解していますか？

1. 認証、認可、認証、権限制御

1.1 認証とは何ですか?

认证(Identification)宣言者に固有の識別情報に基づいて宣言者の身元を確認することを指します。

この言葉の意味は次のとおりです你需要用身份证证明你自己是你自己。

たとえば、当社の一般的な認証テクノロジーは次のとおりです。

• IDカード
• ユーザー名とパスワード
• ユーザーの携帯電話: SMS、携帯電話の QR コード スキャン、ジェスチャー パスワード
• ユーザーのメールアドレス
• ユーザーの生体認証: 指紋、声、目の虹彩
• ビッグデータによるユーザーの識別
• 等

1.2 認可とは何ですか?

授权(Authorization): 情報セキュリティの分野では、リソースに対して関連する操作を実行するために、指定された範囲でリソースの操作権限を付与する资源所有者委任を指します。执行者执行者

実生活の分野では、たとえば、キャッシュ カード (銀行が発行)、アクセス コントロール カード (不動産管理局が発行)、鍵 (家主が発行)、これらが実生活における承認の実現です。

例えば、インターネットの分野では、 Webサーバーのセッション機構、WebブラウザのCookie機構、認可トークン（トークン）の発行などもすべて認可機構です。

1.3 認証とは何ですか?

鉴权(Authentication)情報セキュリティの分野では、宣言者によって宣言されたアイデンティティ権の信頼性を識別および確認するプロセスを指します。

認可から始めると認証が理解しやすくなります。認可と認証は、上流と下流の 2 つの一致関係であり、最初に認可、次に認証です。

実生活の分野では、アクセス制御カードはアクセス制御カード認識装置を通過する必要があり、銀行カードは銀行カード認識装置を通過する必要があります。

インターネット分野:セッション/Cookie/トークンの正当性と有効性を検証する

鉴权これは前と次の間のリンクであり、上流は許可された出力を受け入れ、その信頼性を検証し、許可 (許可) を取得して、許可制御の次のステップに備えることができます。

1.4 権限制御とは何ですか?

权限控制(Access/Permission Control)実行可能な操作を権限リストとして定義し、操作の許可/禁止を決定

パーミッション制御は、パーミッションとコントロールの 2 つの部分に分けて理解できます。許可は抽象的な論理概念ですが、制御は具体的な実装です。

実生活の分野:アクセス コントロール カードの権限の実装を例に挙げます。アクセス コントロール カードには会社のすべてのドアを開ける権限があり、アクセス コントロール カードには管理者ロールの権限があるため、会社のすべてのドアを開けてください。

インターネットの分野: Web バックエンド サービスを通じて、インターフェイス アクセスを制御し、アクセス要求を許可または拒否します。

1.5 認証、認可、認証と権限制御の関係は何ですか?

认证これを見ると、 、授权、鉴权および权限控制これら 4 つのリンクが 1 つであり、関連前后依次发生していることが理解できるはずです上下游。

これら 4 つのリンクは同時に発生する場合があることに注意してください。たとえば、次のシナリオの場合:

• アクセス制御カードを使用してドアを開きます。認証、認可、認証、権限制御の 4 つのリンクが一度に完了し、瞬時に同時に実行されます。
• ユーザーの Web サイトへのログイン:ユーザーがユーザー名とパスワードでログインすると、認証と許可が同時に完了しますが、商品の購入や支払いなど、その後のアクセス要求では認証と許可の制御が行われます。

2. フロントエンド認証方式

2.1 HTTP基本認証

HTTP では、基本认证方案（Basic Access Authentication)クライアント (通常は Web ブラウザを指します) が、要求時にユーザー名とパスワードを提供することでユーザーの身元を確認できるようにします。

1. 認証フローチャート

2. 認証ステップの分析

   • クライアント (ブラウザなど):サーバーからリクエストを送信します受限的列表数据或资源。たとえば、フィールドは次のとおりです。

     GET /list/ HTTP/1.1 Host: www.baidu.com Authorization: Basic aHR0cHdhdGNoOmY=

   • サーバー: こんにちは、クライアント。このリソースはセキュリティ ゾーン baidu.com にあります。これは制限されたリソースであり、基本認証が必要です。

     そして、401 ステータス コード (Unauthorized は許可されていません) をクライアントに返し、www-Authenticate: Basic realm=”baidu.com”認証を要求するための認証ドメインを提供します。

     その中にはBasic検証モードがあり、realm="baidu.com"クライアントは他のドメインではなく、このセキュリティ ドメインのユーザー名とパスワードを入力する必要があることを意味します。

     HTTP/1.1 401 Unauthorizedwww-Authenticate: Basic realm= "baidu.com"

   • クライアント:サーバー、ユーザー名とパスワードを持ってきましたので、ご覧ください; (注: クライアントがブラウザーの場合、この時点でポップアップ ウィンドウが自動的に表示され、ユーザーはユーザー名とパスワードを入力できます)パスワード）;

     ユーザー名とパスワードを入力すると、クライアントはユーザー名とパスワードを Base64 暗号化でサーバーに送信します。

     送信フォーマットは次のとおりです（Basic の内容は、ユーザー名:ase64 形式のパスワード）。

     GET /list/ HTTP/1.1Authorization: Basic Ksid2FuZzp3YW5n==

   • サーバー:Authorizationこんにちはクライアント。フィールドでユーザー名とパスワードを確認しました。それらは正しいです。これが必要なリソースです。

     HTTP/1.1 200 OK ...

3. アドバンテージ

   シンプルで、基本的にすべての一般的なブラウザがサポートされています

4. 欠点がある

   • 危険な：

     HTTP通信をベースとしているため、ネットワーク上にストリーキングに近い状態でエンコードにBase64を使用していますが、このエンコードは簡単にデコードできます。

     認証内容を元のユーザー名とパスワードに復号できなくても安全ではなく、悪意のあるユーザーが認証内容を取得した後、継続的共有サーバーを使用してリクエストを開始する可能性があり、これがいわゆるリプレイ攻撃です。

   • アクティブにログアウトできません:

     HTTP プロトコルには、タブまたはブラウザを閉じるか、ユーザーが履歴をクリアしない限り、ブラウザ内の基本認証情報をクリアするメカニズムが提供されていないためです。

5. 使用するシーン

   内部ネットワーク、または高度なセキュリティ要件が要求されていないネットワーク。

ほとんどすべてのオンライン Web サイトはこの認証スキームを使用しないため、誰もがこのスキームを理解できます。

2.2 セッション Cookie 認証

• Session-Cookie認証とは、サーバー側ではセッション（セッション） 、ブラウザ（クライアント側）ではCookieを利用して実現されるフロントエンドおよびバックエンドの通信認証モードです。

• 什么是 Cookieこの文を理解する前に、と什么是 Session?を簡単に理解しましょう。

• 1. クッキーとは何ですか

     ご存知のとおり、HTTP 是无状态的协议(トランザクション処理用のメモリ機能はなく、サーバーはクライアントとサーバーのセッションが完了するたびにセッション情報を保存しません)。

     したがって、サーバーが異なるクライアントを区別するには、前後の 2 つのリクエストが同じブラウザからのものであるかどうかをサーバーに通知するために使用される状態をアクティブに維持する必要があります。そして、この状態はCookie行くことで達成できます。

     特徴：

     • Cookie はクライアント側に保存され、自由に改ざんできるため安全ではありません。

     • サイズ制限あり（最大4kb）

     • Cookie の数には制限があり、通常、ブラウザは Web サイトに対して 20 Cookie までしか保存できず、ブラウザは通常 300 Cookie までしか保存できません。

     • Android と IOS は Cookie を十分にサポートしていません

     • Cookie はクロスドメインではありませんが、第 1 レベルのドメイン名と第 2 レベルのドメイン名は共有できます (ドメインによって異なります)。

  2. セッションとは

     1. セッションの抽象概念はセッションです。セッションは、ステートレス プロトコル通信プロセス中の中断/継続操作を実現するためのユーザーとサーバー間の対話を抽象化したものです。

     2. 具体的には、サーバーによって生成されるセッション構造であり、メモリ、データベース、ファイルなど、さまざまな方法で保存できます。大規模な Web サイトには通常、ユーザー セッションを保存するための専用のセッション サーバー クラスターがあります。

     3. 原則的なプロセス:

     4. 1. クライアント:ユーザーが初めてサーバーにリクエストを送信します。
        2. サーバー:データを受信し、ユーザーを識別し、ユーザーの現在のセッション プロセスを追跡するために、ユーザーの特定のセッション/セッション ID を自動的に作成します。
        3. クライアント:ブラウザはセッション情報を取得するための応答を受信し、次のリクエストでセッション/セッション ID を取得します。
        4. サーバー:抽出後、サーバーはそれをローカルに保存されたセッション ID と比較して、特定のユーザーのセッションを見つけ、セッションのステータスを取得します。
        5. これまでのところ、クライアントとサーバー間の通信はステートフル通信になっています。

     5. 特徴：

     6. • セッションはサーバーに保存されます。
        • サーバーに付属の暗号化プロトコルを使用します。

     7. クッキーとの違い:

     8. • セキュリティ: Cookie はクライアント側に保存されるため、自由に改ざんできますが、セッションはサーバー側に別の方法で保存され、偽造できないため、セッションはより安全です。
        • アクセス値の種類は異なります。Cookieは文字列データのみをサポートし、Session は任意のデータ型を保存できます。
        • 有効期間は異なります。Cookieは長期間保持するように設定できますが、セッションの有効期限は一般に短くなります。
        • ストレージ サイズが異なります。Cookieによって保存されるデータは 4K を超えることはできません。

     9. これを見て、これはクライアントに保存されているSession-Cookieだけなのではないか、と思った学生もいるかもしれません。SessionCookie

        ビンゴ、そうだね、次へ進みましょう

  3. セッション Cookie 認証のフローチャート

4. セッション Cookie 認証ステップ分析

   • クライアント:ログイン情報のユーザー名/パスワードをサーバーに送信して、ログイン検証を要求します。

   • サーバー:ログイン情報を検証し、検証に合格した後にセッションを自動的に作成し (セッションをメモリまたは Redis に保存し)、このセッション用の一意の識別文字列セッション ID 資格情報 (一般に と呼ばれる) を生成し、設定しsession_idます。sid応答ヘッダーSet-Cookie内のこの一意の識別子。

     注: 署名を使用して をsid暗号化すると、サーバーがsecret対応するキーに従って暗号化を復号化します (必須の手順ではありません)。

   • クライアント:サーバーから応答を受信した後、応答ヘッダーを解析してsidローカル Cookie に自動的に保存し、ブラウザーはドメイン名の Cookie 情報を次の HTTP リクエストの要求ヘッダーに自動的に添付します。

   • サーバー:クライアントからリクエストを受信すると、リクエストのヘッダーにある Cookie を解析し、sidこれに基づいてsidサーバーによって保存されたクライアントにアクセスしsid、リクエストが正当であるかどうかを判断します。

5. セッション Cookie の利点

6. • クッキーは使いやすいです
   • セッション データはサーバー側に保存されるため、JWT よりも管理が簡単です。つまり、ユーザーがログインしてアクティブにログアウトするときに、対応するセッションを追加および削除するだけで済み、管理に便利です。
   • バックエンドの操作のみが必要で、フロントエンドは何の意味もなく操作できます。

7. セッション Cookie の欠点

8. • ユーザーがブラウザ側で Cookie を無効にしたら、GG Smecta に依存します。
   • 非常に安全ではなく、Cookie はデータをブラウザに公開し、データ盗難のリスクを高めます (CSRF による攻撃を受けやすくなります)。
   • セッションはサーバー側に保存されるため、サーバー側のオーバーヘッドが増加し、ユーザー数が多い場合にはサーバーのパフォーマンスが大幅に低下します。
   • モバイルサポートには不向きです。

9. 使用するシーン

10. • 一般的に、中規模および大規模な Web サイトが適用されます (APP モバイル端末を除く)。
    • 一般的なセッションはメモリ サーバー (Redis など) に集中的に保存する必要があるため、サーバーの予算が増加します。そのため、予算が十分でない場合は慎重に選択してください。

11. フロントエンドで一般的に使用される推奨セッション ライブラリ

12. • 使用 express：express-session[1]
    • こちらも使用: koa-session [2]