[JWT]JWT 설명 , JWT공식 홈페이지 참고한 내용 [번역]

이 글은 JWT공식 홈페이지의 소개 및 내용을 그대로 구글 번역기에 돌려서 만든 페이지입니다.

저처럼 보기 귀찮아하시는분들 계실까봐 한글로 그대로 옮겨봤습니다 . 

JWT 란  사이트 ( https://jwt.io/introduction/ )

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

JSON Web Token (JWT)은 JSON 객체로서 당사자간에 안전하게 정보를 전송할 수있는 작고 독립적 인 방법을 정의하는 공개 표준 (RFC 7519)입니다. 이 정보는 디지털로 서명 되었기 때문에 검증되고 신뢰할 수 있습니다. JWT는 RSA 또는 ECDSA를 사용하는 비밀 (HMAC 알고리즘 사용) 또는 공용 / 개인 키 쌍을 사용하여 서명 할 수 있습니다.

그렇다면 JWT는 언제 사용하나

Authorization: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.

인증  : JWT를 사용하는 가장 일반적인 시나리오입니다. 사용자가 로그인하면 각 후속 요청에 JWT가 포함되어 사용자가 해당 토큰으로 허용되는 경로, 서비스 및 리소스에 액세스 할 수 있습니다. 싱글 사인온 (Single Sign On)은 오버 헤드가 적고 다른 도메인에서 쉽게 사용할 수 있기 때문에 요즘 JWT를 널리 사용하는 기능입니다.

Information Exchange: JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.

정보 교환 : JSON 웹 토큰은 당사자간에 정보를 안전하게 전송하는 좋은 방법입니다. JWT는 서명 할 수 있기 때문에 (예 : 공개 키 / 개인 키 쌍을 사용하여) 발신자가 자신이 말하는 사람인지 확인할 수 있습니다. 또한 서명이 헤더와 페이로드를 사용하여 계산되므로 내용이 변조되지 않았는지 확인할 수도 있습니다.

Json Web Token 의 구조. 

Header , Payload , Signature 로 구성되어 있다 . 

Header 

The header typically consists of two parts: the type of the token, which is JWT, and the hashing algorithm being used, such as HMAC SHA256 or RSA.

헤더는 일반적으로 JWT 인 토큰 유형과 HMAC SHA256 또는 RSA와 같이 사용되는 해시 알고리즘의 두 부분으로 구성됩니다.

Then, this JSON is Base64Url encoded to form the first part of the JWT.

그런 다음이 JSON은 Base64Url로 인코딩되어 JWT의 첫 번째 부분을 구성합니다.

Payload

The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.)

토큰의 두 번째 부분은 클레임이 들어있는 페이로드입니다. 클레임은 엔티티 (일반적으로 사용자)와 추가 데이터에 대한 설명입니다. 소유권 주장에는 공개, 공개 및 민간 소유권 주장의 세 가지 유형이 있습니다.

Registered claims: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are: iss (issuer), exp (expiration time), sub (subject), aud(audience), and others.

등록 된 클레임 (Registered claims) : 유용하고 상호 운용 가능한 클레임 세트를 제공하기 위해 필수는 아니지만 권장되는 미리 정의 된 클레임 세트입니다. 그들 중 일부는 iss (발행자), exp (만료 시간), sub (주제), aud (잠재 고객) 등입니다.

Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.

공개 주장 : JWT를 사용하는 사람들이 자유롭게 정의 할 수 있습니다. 그러나 충돌을 피하기 위해 IANA JSON 웹 토큰 레지스트리에 정의되거나 충돌 방지 네임 스페이스가 포함 된 URI로 정의되어야합니다.

Private claims: These are the custom claims created to share information between parties that agree on using them and are neither registered or publicclaims.

비공개 소유권 주장 : 이는 소유권 주장이나 공개적 소유권 주장이 아닌 사용에 동의하는 당사자간에 정보를 공유하기 위해 만들어진 사용자 지정 소유권 주장입니다.

The payload is then Base64Url encoded to form the second part of the JSON Web Token.

페이로드는 Base64Url로 인코딩되어 JSON 웹 토큰의 두 번째 부분을 구성합니다.

Payload 작성시 주의사항 

Do note that for signed tokens this information, though protected against tampering, is readable by anyone. Do not put secret information in the payload or header elements of a JWT unless it is encrypted.

서명 된 토큰의 경우 이 정보는 변조되지 않도록 보호되지만 모든 사람이 읽을 수 있음을 유의하십시오. 암호화되지 않은 JWT의 페이로드 또는 헤더 요소에 비밀 정보를 넣지 마십시오.

Signature

To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

서명 부분을 만들려면 인코딩 된 헤더, 인코딩 된 페이로드, 암호, 헤더에 지정된 알고리즘을 서명해야합니다.

For example if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:

예를 들어 HMAC SHA256 알고리즘을 사용하려면 다음과 같은 방법으로 서명을 만듭니다.

The signature is used to verify the message wasn't changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.

서명은 그 과정에서 메시지가 변경되지 않았 음을 확인하는 데 사용되며 개인 키로 서명 된 토큰의 경우 JWT 발신자가 자신이 말하는 사람인지 확인할 수도 있습니다.

완성된 Json Web Token

The output is three Base64-URL strings separated by dots that can be easily passed in HTML and HTTP environments, while being more compact when compared to XML-based standards such as SAML. 

출력은 HTML 및 HTTP 환경에서 쉽게 전달할 수있는 점으로 구분 된 세 개의 Base64-URL 문자열이며 SAML과 같은 XML 기반 표준과 비교할 때보다 컴팩트합니다.

How do JSON Web Tokens work?

In authentication, when the user successfully logs in using their credentials, a JSON Web Token will be returned. Since tokens are credentials, great care must be taken to prevent security issues. In general, you should not keep tokens longer than required.

Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization header using the Bearer schema. The content of the header should look like the following:

인증에서 사용자가 자격 증명을 사용하여 성공적으로 로그인하면 JSON 웹 토큰이 반환됩니다. 토큰은 자격 증명이므로 보안 문제를 방지하려면 세심한주의를 기울여야합니다. 일반적으로 필요한 것보다 오래 토큰을 보관하지 않아야합니다.

사용자가 보호 된 경로 또는 자원에 액세스하기를 원할 때마다 사용자 에이전트는 일반적으로 Bearer 스키마를 사용하여 Authorization 헤더에 JWT를 보내야합니다. 헤더의 내용은 다음과 같아야합니다.

This can be, in certain cases, a stateless authorization mechanism. The server's protected routes will check for a valid JWT in the Authorization header, and if it's present, the user will be allowed to access protected resources. If the JWT contains the necessary data, the need to query the database for certain operations may be reduced, though this may not always be the case.

어떤 경우에는 상태 비 승인 메커니즘 일 수 있습니다. 서버의 보호 된 라우트는 Authorization 헤더에서 유효한 JWT를 확인하고, 존재하는 경우 사용자는 보호 된 자원에 액세스 할 수 있습니다. JWT에 필요한 데이터가 포함되어 있으면 특정 작업에 대해 데이터베이스를 쿼리해야 할 필요성이 줄어들 수도 있지만 항상 그렇지는 않습니다.

If the token is sent in the Authorization header, Cross-Origin Resource Sharing (CORS) won't be an issue as it doesn't use cookies.

The following diagram shows how a JWT is obtained and used to access APIs or resources:

토큰이 Authorization 헤더로 전송되면 CORS (Cross-Origin Resource Sharing)는 쿠키를 사용하지 않으므로 문제가되지 않습니다.

다음 다이어그램은 JWT가 획득되어 API 또는 자원에 액세스하는 방법을 보여줍니다.

JWT 홈페이지에 나와있는 이미지를 그대로 가져왔습니다 .  내용을 살펴 보겠습니다.

1. 어플리케이션 또는 클라이언트가 권한 서버에 권한을 요청합니다. 이것은 다른 권한 부여 플로우 중 하나를 통해 수행됩니다. 예를 들어, 일반적인 OpenID Connect 호환 웹 응용 프로그램은 인증 코드 흐름을 사용하여 / oauth / authorize 끝점을 통과합니다.

1. 권한 부여가 승인되면 권한 서버는 응용 프로그램에 액세스 토큰을 리턴합니다.

1. 응용 프로그램은 액세스 토큰을 사용하여 보호 된 리소스 (예 : API)에 액세스합니다.

주의 사항

Do note that with signed tokens, all the information contained within the token is exposed to users or other parties, even though they are unable to change it. This means you should not put secret information within the token.

서명 된 토큰을 사용하면 토큰에 포함 된 모든 정보가 변경 될 수는 없지만 사용자 또는 다른 당사자에게 노출된다는 점에 유의하십시오. 즉, 토큰 내에 비밀 정보를 넣으면 안됩니다.

Why should we use JSON Web Tokens?

JSON Web Token을 사용해야하는 이유는 무엇입니까?

Let's talk about the benefits of JSON Web Tokens (JWT) when compared to Simple Web Tokens (SWT) and Security Assertion Markup Language Tokens (SAML).

SWT (Simple Web Tokens) 및 SAML (Security Assertion Markup Language Token)과 비교할 때 JSON Web Token (JWT)의 이점에 대해 이야기 해 보겠습니다.

As JSON is less verbose than XML, when it is encoded its size is also smaller, making JWT more compact than SAML. This makes JWT a good choice to be passed in HTML and HTTP environments.

JSON은 XML보다 덜 장황하기 때문에 인코딩 할 때 크기가 작아 져서 JWT가 SAML보다 작아집니다. 따라서 JWT는 HTML 및 HTTP 환경에서 전달하기에 좋은 선택입니다.

Security-wise, SWT can only be symmetrically signed by a shared secret using the HMAC algorithm. However, JWT and SAML tokens can use a public/private key pair in the form of a X.509 certificate for signing. Signing XML with XML Digital Signature without introducing obscure security holes is very difficult when compared to the simplicity of signing JSON.

보안 측면에서 볼 때, SWT는 HMAC 알고리즘을 사용하여 공유 암호로만 대칭으로 서명 할 수 있습니다. 그러나 JWT 및 SAML 토큰은 공개 / 개인 키 쌍을 X.509 인증서 형식으로 서명에 사용할 수 있습니다. 불명확 한 보안 허점을주지 않으면 서 XML 서명으로 XML 서명하기 JSON 서명의 단순성과 비교할 때 매우 어렵습니다.