ASP.NETコアJWTベースの認証（A）

ASP.NETコア  ベースのJWTの認定（A）を

ウェブトークンJSON  （ JWT）、オープンな標準JSON（（に基づいてネットワークアプリケーション実行環境の間を通過するために、文です RFC 7519）。トークンは、特にシングル分散サイトのため、コンパクトで安全であるように設計されてサインオン（ SSO）のシナリオ。 JWTの一般的に使用されている文は、サーバからのリソースへのアクセスを容易との間の同一で認証されたユーザID情報提供者とサービス・プロバイダーを渡すために、あなたもでなければならないいくつかの余分な他のビジネス・ロジックを追加することができます、ステートメント情報トークンは直接認証に使用することができますが、暗号化することができます。

私たちは、知っているHTTPプロトコル自体はステートレスなプロトコル、およびユーザは、ユーザ認証のための我々のアプリケーションへのユーザー名とパスワードを提供する場合は、次回の要求は、ユーザーが再び前にユーザー認証を行う必要があることを、この手段であり、 OK、によると、理由はHTTPプロトコル、我々はリクエストが送信されたユーザーを知ることができないので、私たちのアプリケーションを作るために要求が発行されたユーザーを識別することができ、我々はサーバーのユーザーログインのコピーを保存することができます情報、このログイン情報応じてブラウザに渡されます、保存するためにそれを教えてくれたクッキーを、アプリケーションが私たちの要求に送信される次回ので、当社のアプリケーションは、どのユーザからの要求を識別することができるようになりますように、、。

いくつかの一般的な従来の認証メカニズム

HTTP基本認証

HTTP基本認証の簡単な説明はポイントがユーザーたびAPI要求を提供することをされたユーザー名とパスワードを、簡単に言えば、基本認証は、に沿ったものであるRESTfulなAPI  を使用する最も簡単な認証方法、ユーザー名のみのパスワードを提供する必要がありますが、理由ユーザー名とパスワードが少なくなり、本番環境で使用されているサードパーティクライアントの危険にさらされています。そのため、オープンの開発にRESTfulなAPI、使って回避しようとHTTP基本認証を。

OAuthの

OAuthの（オープン認証）は、ユーザーがユーザー名とパスワードを必要とせずにWebサービスへのユーザーに保存されている（たとえば、写真、ビデオ、連絡先リストなど）にアクセスプライベートリソースへのサードパーティ製のアプリケーションを許可することを可能にするオープンスタンダードの認証でありますサードパーティのアプリケーションに。

OAuthのは、ユーザーが特定のサービスプロバイダに保存されたデータにアクセスするためのユーザー名とパスワードの代わりにトークンを提供することができます。各トークンは、時間の特定の期間（例えば、単にビデオアルバム）内の特定のリソースへの（例えば、ビデオ編集、ウェブサイト）（例えば、次の2時間以内）にアクセスの特定のサードパーティシステムを許可されています。このように、OAuthのは、ユーザーがアクセスを、彼らは別のサービスプロバイダに格納特定の情報ではなく、すべてのコンテンツを、サードパーティのWebサイトを認証することができます。

クッキー認証

クッキー認証メカニズムは、サーバー側の作成に最初の要求の認証にあるセッションは、ブラウザクライアントで作成しながら、オブジェクトをクッキーがオブジェクト;にもたらすクライアントでクッキーオブジェクトとサーバー側のセッション状態管理を実装するためのオブジェクトが一致。私たちは、ブラウザの時間を閉じたときに、デフォルトで、クッキーは削除されます。しかし、それを変更することができますクッキーを時間期限切れにすることをクッキーは一定の期間内に有効です。

トークンの プロフィール

JWT  （ JSONウェブトークンは）ネットワークアプリケーション実行環境とJSONベースのオープンスタンダードの間を通過するために宣言されています。

JWTの文は、一般的に、サーバーからリソースを取得するために、アイデンティティで利用者識別情報を認証し者とサービスプロバイダ間の転送を提供するために使用されます。たとえば、ユーザーのログイン時に使用。

一部の人々は、私が唯一の署名キャッシュまたはデータベースのレコードをログに記録する必要があると思うかもしれまたはクッキーをすることができ、なぜ使用JWTそれ？私たちは、データベースやソフトウェアは、時間のロスが私たちの最大の場所であることを知っている  I / O（通常は、入力と出力の読み取りと書き込みのハードディスクを参照）私たちはHS256一度デコードすることを選んだので、今すぐ強力なコンピューティングパワーとするために、言葉、ディスクアクセス時間よりHS256ソリューションは、はるかに高速になると。

HTTPプロトコルと同様に、ユーザの認証情報やセッション情報を保持するサーバを必要としないステートレストークンベースの認証機構です。拡張子のアプリケーションを容易にしたトークン認証メカニズムに基づいたアプリケーションは、ユーザーがログインしているサーバーを検討する必要がないことを、この手段。
プロセスはこれです：

• サーバ要求にユーザ名とパスワードのユーザー
• ユーザーの情報を確認するために、サーバー
• サーバーは、トークンを検証することにより、ユーザに送信します
• クライアントトークンメモリ、およびこのトークン値に含まれる各リクエスト
• サーバー認証トークン、およびデータを返します。

このトークンは、加えて、サーバがCORS（クロスオリジンリソースの共有）戦略をサポートする必要があり、それは事前にリクエストに保管しなければならない、サーバーへの要求ごとに渡さなければならない、我々は通常、サーバアクセス制御にそれを行います-allow-起源：*。
だから我々は戻ってJWTの話題になりました。

JWTの 構図

で見てみましょうJWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

私たちは、文字列の2つが含まれていることを見ることができますよく見て  。「」これら二つを  。「」JWTは 3分割、我々は頭、負荷情報、ビザ情報になることでした。だから、労働の三部部門がそれをある何ですか？

ヘッダ

JWTのヘッドは、二つの情報を運びます

• JWTの宣言型、それはJWTです
• 暗号化アルゴリズム、一般SHA256、HS256を使用

完全な頭部は、このようなJSONでなければなりません

{
   ' 標準'：' JWT ' 、
   ' ALG '：' HS256 ' 
}

ヘッドJSON BE base64で暗号GET私たちの最初の部分

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

ペイロード

第二部は、負荷情報、ペイロードである、あなたが私たちの理解することができJWTは大きな倉庫で、ヘッドは倉庫番号やその他の基本的な情報の名前の最初の部分で、負荷情報倉庫自体は、倉庫内のすべての商品が含まれています。順番にこの情報は、以下の3つの部分から構成されています。

• 標準的な登録届出書
• 公式声明
• Privateステートメント

標準的な登録届出書（推奨しますが、使用に必須ではありません）  ：

• ISS：JWTの発行者

• サブ：ユーザーのためのJWT

• AUD：受信側JWT

• EXP：JWT有効期限、有効期限は、時間の問題よりも大きくなければなりません。

• NBF：JWTの前に定義されてどのような時間は利用できません。

• IAT：時間の問題JWT

• JTI：JWT独自のアイデンティティは、主にリプレイ攻撃を避けるために、ワンタイムトークンとして使用されています。

公共の声明：

公共の宣言は、必要な情報やその他のビジネスニーズを追加するために、ユーザーに関する一般的な情報を任意の情報を追加することができます。しかし、クライアントが解読できるので、部分的には、機密情報を追加することは推奨されません。

Privateステートメント：

Privateステートメントは、共通の定義としての文の提供者と消費者であるbase64では、情報の一部はプレーンテキストとして分類することができることを意味し、対称復号化されているので、一般的に、機密情報を保存することは推奨されません。

実際には、我々は、対称暗号文を解読されることができるので、機密情報を格納しないでくださいヘッダとペイロードbase64で暗号化に基づいています。

ペイロードを定義します。

{
   " サブ"：" 1234567890 " 、
   " 名前"：" ジョン・ドウ" 、
   " 管理者"：真
}

base64で暗号化した後、私たちは私たちの第二部を得ました

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

署名

JWT第三の部分はビザ情報であり、このビザ情報は、3つの部分からなります：

• （BASE64後）ヘッダ
• ペイロード（BASE64後）
• 秘密

これは、検査の前部分の一部として理解することができる、ことにより暗号化された暗号文の最初の2つの部分ヘッダの暗号化は、プライマリ暗号化キーに渡されるサーバと、定義された場合、情報の最初の2つの部分改ざんされて、確かにビザチェックの最後の部分を渡します。したがって、この方法で確実にJWTのセキュリティを。

したがって、私たちの良い保存して非表示に暗号鍵が漏洩し、それは誰でも簡単にキーを知ることができることを意味することを想定し、非常に重要であるJWT自己署名と検証を。

オリジナルリンク：https://www.cnblogs.com/WarrenRyan/p/10426204.html