一般的に使用されるいくつかの 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. リソース所有者のパスワード資格情報

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

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

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

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

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

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

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

認可: これは、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 の詳細については、次のブログを参照してください:

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 セキュリティ認証方法の紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。