一般的に使用されるいくつかの Web セキュリティ認証方法の紹介

この記事では、一般的に使用されており、一定の参考価値のある 5 つの Web セキュリティ認証方法を紹介します。

1. Http Basic Auth

これは最も古いセキュリティ認証方式で、API にアクセスする際にアクセスしたユーザー名とパスワードを入力するだけで情報が漏洩してしまうため、現在では、使用されることはますます少なくなり、より安全で機密性の高い認証方法が使用されるようになりましたが、一部の古いプラットフォームではまだ使用されている可能性があります。

下の図に示すように、ユーザー名とパスワードの入力を求めるボックスがポップアップ表示されます。これは Tomcat に付属する HTTPBasic 認証です。

これは、アプリケーションにアクセスするための資格情報です。xxxXXX 文字列は、暗号文であることを示すために私が作成したものです。これはどのような種類の暗号文ですか? ユーザー名とパスワードBase64 暗号化後に取得された暗号文です。盗むのが簡単すぎるため、新しいアプリケーションがこの方法を使用することはめったにありません。簡単ではありますが、セキュリティ レベルが低すぎます。

2. OAuth2

私の前回のブログでは、OAuth2 と、OAuth2 認証を実装するための Azure AD の使用について紹介しましたが、ここでは、誰もが要約して確認できるように、そのブログの内容の一部を抜粋します。

https://blog.csdn.net/aHardDreamer/article/details/88650939

OAuth とは: オープン認証 (オープン認証) ユーザー名とパスワードをサードパーティに提供せずに、サードパーティのアプリケーションが Web サイトに保存されているユーザーのプライベート リソースにアクセスできるようにするオープン スタンダードです。 。たとえば、私たちは QQ/WeChat/Weibo などを介してサードパーティのプラットフォームにログインすることに慣れています。 OAuth 1.0 バージョンのリリース後に多くのセキュリティ ホールがあったため、OAuth 1.0 は、クライアント開発者の簡素化に重点を置いた OAuth 2.0 で完全に廃止されるか、リソース所有者と HTTP サービス プロバイダーの間で承認された合意を通じて、完全に廃止されました。ユーザーに代わって、サードパーティのアプリケーションがユーザーに代わってアクセスできるようにします。読むと少し複雑ですが、原理は非常に簡単ですので、以下の説明をご覧ください。

1. まず、OAuth2 認証および認可プロセスにおける次の 3 つの役割を理解する必要があります:

1. サービス プロバイダー: 名前が示すように、ユーザーは保護されたサービスとリソースを提供します。たくさんのものがここに保管されています。

2. ユーザー: サービスプロバイダー上に物(写真、情報など)を保管している人。

3. クライアント: サービスの呼び出し元。サービス プロバイダーのリソースにアクセスしたい場合は、サービス プロバイダーに登録する必要があります。登録しないと、サービス プロバイダーはそれを受け入れません。

2. OAuth2 認証および認可プロセス:

1) ユーザーはサービス プロバイダーに保存されているリソースを操作したい;

2) ユーザーはクライアントにログインします。 、およびクライアント サービス プロバイダーは一時トークンを要求します;

3) サービス プロバイダーはクライアントの ID を確認した後、クライアントに一時トークンを与えます;

4) クライアントが一時トークンを取得した後トークンを使用すると、ユーザーがサービス プロバイダーの認証ページに誘導され、ユーザーの認証が要求されます。 (このプロセスでは、一時トークンとクライアントのコールバック リンク/インターフェイスがサービス プロバイダーに送信されます。当然、サービス プロバイダーはユーザーの認証と承認後にこのインターフェイスを呼び出すために戻ってきます)

5 )ユーザーはユーザー名とパスワードを入力してログインします。ログインに成功すると、クライアントはサービス プロバイダーのリソースへのアクセスを承認されます。

#6) 承認が成功すると、サービス プロバイダーはユーザーをクライアントのリソースに誘導します。 Web ページ (呼び出しステップ 4 内部のコールバック リンク/インターフェイス);

7) クライアントは、一時トークンに基づいてサービス プロバイダーから正式なアクセス トークンを取得します;

8) サービス プロバイダーは、一時トークンとユーザーの承認に基づく正式なアクセス トークン クライアントにはアクセス トークンが付与されます;

9) クライアントはアクセス トークンを使用して、サービス プロバイダーに保存されているユーザーの保護されたリソースにアクセスします。

3. アクセス トークン (許可タイプ) を取得するには 4 つの方法があり、それぞれに適用可能なアプリケーション シナリオがあります:

1. 認可コード (認可)コードモード)

通常のサーバーサイドアプリケーションと組み合わせて使用​​されます。

1) ユーザーがクライアントにアクセスし、クライアントがクライアントを認証サーバーに誘導します。ユーザーが認可したと仮定すると、認証サーバーはユーザーを、「リダイレクト URI」(リダイレクト URI) に誘導します。クライアントによって事前に送信され、認証コードが添付されます。

2) クライアントは認証コードを受け取り、以前の「リダイレクト URI」を添付し、認証サーバーからのトークンを申請します: GET /oauth/token?response_type=code&client_id=test&redirect_uri=リダイレクト ページ リンク。リクエストはコード認証コードを正常に返します。このコードは通常 10 分間有効です。

3) 認証サーバーは認可コードとリダイレクトURIをチェックし、正しいことを確認した上で、アクセストークン(アクセストークン)とリフレッシュトークン(リフレッシュトークン)をクライアントに送信します。 POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=ページ リンクをリダイレクトします。リクエストはアクセス トークンとリフレッシュ トークンを正常に返します。

(無料の学習ビデオ共有: php ビデオ チュートリアル )

2. 暗黙的 (簡易モード)

モバイル アプリケーションまたは Web アプリと組み合わせて使用​​します。

アクセス トークンは認可サーバーから直接返されます (フロントエンド チャネルのみ)

リフレッシュ トークンはサポートされていません

リソース所有者とパブリック クライアント アプリケーションが同じデバイス上

セキュリティ攻撃に対して最も脆弱です

3. リソース所有者のパスワード資格情報

信頼できるクライアント アプリケーションに適用されます。同じ組織内の内部または外部アプリケーション 外部アプリケーション。

ユーザー名とパスワードを使用してログインするアプリ (デスクトップ アプリなど)

ユーザー名/パスワードを認証方法として使用して、認証サーバーからアクセス トークンを取得します

一般的には、リフレッシュ トークンはサポートされていません

リソース所有者とパブリック クライアントが同じデバイス上にあると仮定します

#4. クライアント資格情報

メイン サービス API タイプ アプリケーションを呼び出すクライアントに適用されます (Baidu API ストア、異なるプロジェクト間のマイクロサービスが相互に呼び出すなど)

#バックエンド チャネルのみ、顧客の資格情報を使用してアクセス トークンを取得します

顧客の認証情報は対称暗号化または非対称暗号化にできるため、この方法では共有パスワードまたは証明書がサポートされます

3. Cookie セッション認証

Cookie セッション認証J2EEを初めて学んだ時に仕組みを比較しました リクエスト認証はサーバー側でSessionオブジェクトを作成し、クライアントのブラウザ側でCookieオブジェクトを作成することが多く、クライアントが持ってきたCookieオブジェクトをクライアントに持ち込むことで状態管理を実現しますサーバー側のセッション オブジェクトと一致します。デフォルトでは、Cookie はブラウザを閉じると削除されます。ただし、Cookie の有効期限を変更することで、Cookie を一定期間有効にすることができます。

ただし、この Cookie セッションベースの認証では、アプリケーション自体の拡張が困難になります。異なるクライアント ユーザー、独立 サーバーはこれ以上のユーザーをホストできなくなり、この時点でセッション ベースの認証アプリケーションの問題が露呈します。

セッション認証に基づく問題:

1) セッションが増加するとサーバーのオーバーヘッドが増加します

各ユーザーがアプリケーションによって認証された後、アプリケーションはサーバーでレコードを作成する必要があります。ユーザーの次のリクエストの識別を容易にするためです。一般に、セッションはメモリに保存されます。認証されたユーザーの数が増えると、サーバーのオーバーヘッドが大幅に増加します。

2) 分散環境またはマルチサーバー環境での適応性の低さ

ユーザー認証後、サーバーは認証レコードを作成します。認証レコードがメモリに保存されている場合、これはユーザーが次のリクエストを行うことを意味します。許可されたリソースを取得できるように、このサーバー上にロード バランサを作成する必要があるため、分散アプリケーションにおけるロード バランサの機能が制限されます。これは、アプリケーションのスケーラビリティが制限されることも意味します。ただし、一部のサーバーでは、スティッキー セッションを設定することで各サーバー間でセッションを共有できるようになりました。

3) CSRF 攻撃に対して脆弱です

ユーザー識別は Cookie に基づいているため、Cookie が傍受されると、ユーザーはクロスサイト リクエスト フォージェリ攻撃に対して脆弱になります

4. トークン認証

トークンベースの認証メカニズムは http プロトコルに似ておりステートレスであり、サーバー上にユーザーの認証情報やセッション情報を保持する必要がありません。つまり、トークン認証メカニズムに基づくアプリケーションでは、ユーザーがどのサーバーにログインするかを考慮する必要がなく、アプリケーションの拡張が容易になります。

プロセス:

ユーザーはユーザー名とパスワードを使用してサーバーに要求します

サーバーはユーザーの情報を検証します

サーバーはユーザーにトークンを送信します検証を通じて

クライアントはトークンを保存し、トークン値を各リクエストに添付します。

サーバーはトークン値を検証し、データを返します。

このトークンを含める必要があります各リクエストで. サーバーに渡されると、リクエスト ヘッダーに保存される必要があります. さらに、サーバーは CORS (Cross-Origin Resource Sharing) ポリシーをサポートする必要があります. 通常、これはサーバー上で実行できます: Access-Control-許可元。

5. JWT 認証メカニズム (Json Web Token)

オープン標準 (RFC 7519) として、JWT はシンプルでカスタマイズ可能なメソッドを定義します。 Json オブジェクトの形式で通信当事者間で情報を安全に転送するために使用されます。デジタル署名が存在するため、この情報には信頼性があり、HMAC アルゴリズムまたは RSA 公開鍵と秘密鍵のペアを使用して JWT に署名できます。

シンプルさ

データ量が少なく通信速度が速いため、URL、POSTパラメータ、またはHTTPヘッダーで送信可能

自己完結型

ペイロードにはすべてのユーザーが必要とする情報が含まれているため、データベースへの複数のクエリを回避できます

次のシナリオでは JSON Web トークンを使用すると非常に便利です:

認可: これは、JWT を使用する最も一般的なシナリオです。ユーザーがログインすると、後続の各リクエストには JWT が含まれ、ユーザーはそのトークンで許可されたルート、サービス、リソースにアクセスできるようになります。シングル サインオンは、オーバーヘッドが少なく、ドメイン間で簡単に使用できるため、現在広く使用されている JWT の機能です。

情報交換: JSON Web トークンは、当事者間で情報を安全に送信するための優れた方法であることは間違いありません。 JWT は公開鍵と秘密鍵のペアなどを使用して署名できるため、送信者が本人であることを確信できます。また、ヘッダーとペイロードを用いて署名を計算するため、内容が改ざんされていないことも検証できます。

JWT の構造:

この図を見ると、JWT の構造が 3 つの部分に分かれており、それらが「」で接続されていることがわかります。 " :

ヘッダー:

ヘッダーは通常、トークン タイプ (「JWT」) とアルゴリズム名 (HMAC SHA256 や RSA など) の 2 つの部分で構成されます。

例:

次に、Base64 を使用してこの JSON をエンコードし、JWT

ペイロードの最初の部分を取得します:

JWT の 2 番目の部分はペイロードであり、クレーム (要件) が含まれています。クレームは、エンティティ (通常はユーザー) およびその他のデータに関するステートメントです。宣言には、登録済み、パブリック、プライベートの 3 つのタイプがあります。

登録済みクレーム: ここでは事前定義済みクレームのセットを示します。これらは必須ではありませんが、推奨されます。例: iss (発行者)、exp (有効期限)、sub (件名)、aud (対象者) など。

パブリック クレーム : 自由に定義できます。

プライベート クレーム : 使用に同意した当事者間で情報を共有するために使用されるクレームであり、登録または公開されていません。

以下は例です:

ペイロードを Base64 エンコードして、JWT の 2 番目の部分を取得します。

注、含めないでください。 JWT に含める 暗号化されていない限り、機密情報をペイロードまたはヘッダーに含めます。

署名:

署名部分を取得するには、エンコードされたヘッダー、エンコードされたペイロード、秘密鍵が必要です。署名アルゴリズムはヘッダーで指定されているものです。署名してください。

例:

HMACSHA256(base64UrlEncode(header) "."base64UrlEncode(payload), secret)

署名は、メッセージが実行中に変更されたかどうかを検証するために使用されます。配信プロセス、さらに秘密鍵で署名されたトークンの場合は、JWT の送信者が本人であるかどうかを検証することもできます。

##JWT トークンに遭遇したら、JWT 公式 Web サイトにアクセスして復号化できます。公式 Web サイトで復号化されたデータは次のとおりです。その 3 つの部分がはっきりとわかります:

#JWT の詳細については、次のブログを参照してください:

https://www.cnblogs.com/cjsblog/p/9277677.html

リファレンス:

https://www.jianshu.com/p/f8c43dcd8b69

https://blog.csdn.net/alan_liuyue/article/details/88183267

https ://www .cnblogs.com/cjsblog/p/9277677.html

関連する推奨事項:

Web サーバーのセキュリティ

以上が一般的に使用されるいくつかの Web セキュリティ認証方法の紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。