認証の仕事が間もなく来る時、私はJWTを勉強して、いくつかの良い資料が整理を勉強します.

intro to JWTs: https://jwt.io/introduction

mozilla guidelines on OIDC https://infosec.mozilla.org/guidelines/iam/openid_connect.html

JWT validation in the context of krakend https://www.krakend.io/docs/authorization/jwt-validation/

example integration of krakend with keycloak: https://github.com/xyder/example-krakend-keycloak

https://meetup.toast.com/posts/239

What is JWT

JWTは主に授権と情報交換に用いられる.特定の情報を暗号化された文字列として表し、その文字列を送信および受信しながら、復号化によって受信された要求であるか否かを確認するために使用される.この文字列の利点は、その設計がURLの任意の位置とは無関係であるため、URLまたはHeaderの任意の位置とは無関係であることである.暗号化などの重要な情報を正常に伝えるには、どのような情報を暗号化しますか?構造を掘り起こしましょう.

Structure of JWT

HEADER.PAYLOAD.SIGNATURE

JWTは大きく3つの部分に分かれている.例を挙げて、誰もがどのような情報を持っているかを判断しましょう.

1. Header

{
  "typ": "JWT",
  "alg": "HS256"
}

Headerの場合の大部分は2つの大きな部分として表現される.
1. the type of token, actually JWT2. the signing algorithm being used such as HMAC , SHA256 , or RSA .

2. Payload

PayloadにはClaimsが含まれています.Claimとは、JWTのコンテンツ(トークン作成者(クライアント)に関する情報、作成時間等)やクライアントとサーバとの間で交換される値からなる.Claimの種類は3種類ありますregistered, public, and private.

Registered Claim

必要ではありませんが、提供すると良いものが含まれています.誰がやったのか、いつやったのか、誰が聞いたのかなど、次の命令があります.( リファレンス )

"iss"(Issuer) Claim

"sub"(Subject) Claim

"aud"(Audience) Claim

"exp"(Expiration Time) Claim

"nbf"(Not Before) Claim

"iat"(Issued At) Claim

"jti"(JWT ID) Claim

Public Claim

これらはJWTを使用する人が自由に作成できる属性です.しかし、IANA JWT RegistryまたはURIで必要とされる競合は避けたほうがよい.

Private Claim

Party内で共有するプロトコルの内容です.登録と公開のすべてではありません.

Warning

署名されたタグの場合、この情報は改ざんによって保護されますが、誰でも読むことができます.暗号化されていない場合は、JWTのペイロードまたはヘッダ要素に機密情報を入れないでください.

3. Signature

署名は,前の情報を秘密暗号化して生成した文字列である.署名が「この書類が正しいことを保証する」という意味だと考えれば便利です.後でこの情報を利用して正確に判断します.

4. Debugger

jwt.io Debuggerを通じて前の内容を学ぶことができます!

How does JWT work?

認証プロセスはcredentialによって認証に成功した後、JWTに戻る.返されるTokenは認証に成功した情報であるため、セキュリティ上の問題に非常に注意しなければならない.ユーザは、返されたJWTを使用してサーバにライセンスを要求できるようになりました.主にAuthorization headerにBearschemaを読み込みJWTを送信します.( What is Bearer? )

Authorization: Bearer <JSON Web Token or OAuth Token>

ヘッダにメッセージを送信する場合は、クッキーを使用していないため、CORSの問題を心配する必要はありません.

Authorization flow using JWT

ユーザーはauthサーバに認証を要求します.(この部分は他のauthflowとは違うそうですが、他の内容が分からないのでオリジナルを添付します.)=>This is performed through one of the different authorization flows. For example, a typical OpenID Connect compliant web application will go through the /oauth/authorize endpoint using the authorization code flow .

ライセンスがある場合、auth severはtokenを返します.

Tokenを使用して保護されたリソースにアクセスします.