농부지기

[ Nexacro.Component - 콤보에 대한 모든 속성 조회 ]

[ JWT.json web token-기본 개념  ]

1. 표준규약

   - SON Web Token (JWT) 은 웹표준 (RFC 7519) 으로서 두 개체에서 JSON 객체를 사용하여
      가볍고 자가수용적인 (self-contained) 방식으로 정보를 안전성 있게 전달해 준다.

2. 지원언어

   - Java, Python, C++, R, C#, PHP, JavaScript, Ruby, Go, Swift 등

3. 자가 수용적 (self-contained) 

   - JWT 는 필요한 모든 정보를 자체적으로 지니고 있다. 

      JWT 시스템에서 발급된 토큰은, 토큰에 대한 기본정보, 

      전달 할 정보 (로그인시스템에서는 유저 정보를 나타냄) 

      그리고 토큰이 검증됐다는것을 증명해주는 signature 를 포함하고 있다.

4. 각 Layer간 전달방식 두 가지

    - 참고, 자구용적으로 두 개체 사이에서 손쉽게 전달 가능.

    1. HTTP 헤어에 넣어서 전달 가능

    2. URL의 파라미터로 전달 가능

5. 안드로이드 보안

   1. 세션과 쿠키는 모바일 어플리캐이션에서 make sense하지 않다. 

      서버에서 생성된 세션과 쿠키를 모바일 클라이언트에서는 공유할 수 없다.

   2. 현재 어플리케이션에서 렌더링된 HTML이 반환되었다. 

      모바일 클라이언트에서는 JSON 또는 XML와 같은 포맷의 응답이 필요하다.

   3. 위 두 가지 사유로 안드로이드 보안은 JWT가 좋다.

6. JWT 생성 및 사용방법

   1. Client : 사용자가 Login

   2. Server : 유저의 정보를 기반으로 토큰을 발급하여 Client에 전달.

   3. Client : 각 업무화면에서 서버에 정보요청 할 때 마다 JWT를 포함하여 전달.

   4. Server : Client에게서 요청을 받을 때 맏, JWT 토큰이 유효하고 인증됐는지 검증

                업무요청단계부터는 JWT를 client전달할 필요 없고

                요청한 업무자료만 넘겨주면 됨

   - 이방식으로하면 서버에서는 Session관리가 필요 없어 자원을 많이 아낄 수 있다.

7. JWT 구조

   1. 항목 : 헤더(header),   내용(payload),  서명(signature)

   2. 구조 예) 헤더(header) . 내용(payload) . 서명(signature)

                 - 각 항목별로 중간에 (.)을 이용해서 결합

8. JWT-헤더(header)

   1. 존재이유 : ???

   2. 항목 : typ, alg

   3. typ - 존재 이유 : ??

          - 정의 :   토큰 타입을 지정   (예, JWT)

      alg - 존재 이유 : ?? 

          - 정의 : 해싱 알고리즘을 지정

                   해싱 알고리즘이란 보통 'HMAC SHA256' 혹은 'RSA'가 사용되며,

                   이 알고리즘은, 토큰을 검증 할 때 사용되는 signatur부분에서 사용됨

   4. 예) 

9. JWT-내용(payload)

   1. 존재이유 : ???

   2. 정보 : 토큰에 담을 정보. 이 정보의 한 '조각'을 클레임(claim)이라고 한다.

             이 claim은  name/value의 한 쌍으로 이뤄져 있고 여러개 넣을 수 있다.

   3. 항목 - 등록된 (registered) 클레임,

              공개 (public) 클레임,

              비공개 (private) 클레임

   4. 등록된 (registered) 클레임

      a. 정의 : 등록된 클레임들은 서비스에서 필요한 정보들이 아닌, 

                토큰에 대한 정보들을 담기위하여 이름이 이미 정해진 클레임들이다. 

                등록된 클레임의 사용은 모두 선택적 (optional)이다.

      b. 항목 : iss,  sub,  aud,    exp,    nbf,   iat,    jti

      c. 항목 정의

   4. 공개 (public) 클레임

      a. 정의 : 공개 클레임들은 충돌이 방지된 (collision-resistant) 이름을 가지고 있어야 한다.

         그래서 보통 클레임 이름을 URI(도메인) 형식으로 짓는다.

      b. 예)

   5. 비공개 (private) 클레임

      a. 정의 : 등록된 클레임도아니고, 공개된 클레임들도 아니다.

                양 측간에 (보통 클라이언트 <->서버) 협의하에 사용되는 클레임 이름들이다. 

                공개 클레임과는 달리 이름이 중복되어 충돌이 될 수 있으니 사용할때에 유의해야한다.

      b. 예)

11. JWT-서명(signature)

   1. 존재이유 : ???

    2. 정의 : 이 서명은 헤더의 인코딩값과, 정보의 인코딩값을 합친 후 주어진 비밀키로 해쉬를 하여 생성한다.

              서명 부분을 만드는 슈도코드(pseudocode)의 구조는 다음과 같다.

              이렇게 만든 해쉬를, base64 형태로 나타내면 된다.

              (문자열을 인코딩 하는게 아닌 hex → base64 인코딩을 해야한다.)

[ jwt. 참고 URL ]