ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • OAuth / JWT
    Programming/BackEnd 2020. 5. 11. 15:50

    JWT (JSON Web Token)

     

    JWT 구성

    • Header는 토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있습니다.
    • Payload는 claim 정보를 포함하고 있습니다. userId, expire, scope 등이 여기에 해당합니다.
    • 마지막으로 Signature는 secret key를 포함하여 암호화되어 있습니다. Base64 방식으로 인코딩한 Header, Payload, Secret Key를 더한 후 서명됩니다.
    • 최종적인 결과 : Encoded Header + . + Encoded Payload + . + Verify Signature

    Header, Payload는 인코딩될 뿐(16진수로 변경), 따로 암호화되지 않습니다. 따라서 JWT 토큰에서 Header, Payload는 누구나 디코딩하여 확인할 수 있습니다.

    하지만 Verify Signature는 SECRET KEY를 알지 못하면 복호화할 수 없습니다. 

    A 사용자가 토큰을 조작하여 B 사용자의 데이터를 훔쳐보고 싶다고 가정하겠습니다. 그래서 payload에 있던 A의 ID를 B의 ID로 바꿔서 다시 인코딩한 후 토큰을 서버로 보냈습니다. 그러면 서버는 처음에 암호화된 Verify Signature를 검사하게 됩니다. 여기서 Payload는 B사용자의 정보가 들어가 있으나 Verify Signature는 A의 Payload를 기반으로 암호화되었기 때문에 유효하지 않는 토큰으로 간주하게 됩니다. 여기서 A사용자는 SECRET KEY를 알지 못하는 이상 토큰을 조작할 수 없다는 걸 확인할 수 있습니다.

     

     

    JWT Process

    1. 클라이언트에서 사용자의 ID와 PW를 서버에게 보낸다.

    2. 서버는 요청을 확인하고 Secret Key를 통해 JWT를 발급(생성)한다.

    3. 클라이언트에게 JWT를 반환한다.

    4. 클라이언트는 인증헤더에 JWT를 담아서 서버에게 보낸다

    5. 클라이언트로부터 받은 JWT Signature를 검증(체크)한다.

    6. 클라이언트에게 응답을 보낸다.(데이터를 리턴한다)

     

    JWT와 OAuth

    JWT는 토근의 유형이고, OAuth는 토큰을 발급하고 인증하는 방법을 설명하는 일종의 프레임워크이다. 

    단, JWT는 토큰자체에 유저정보를 담아서 HTTP 헤더로 전달하기 때문에 유저 세션을 유지할 필요가 없고 가볍게 데이터를 주고 받을 수 있다는 장점이 있다.

     


    JSON Web Token

    • Claim based Token : 
      • Claim: 사용자에 대한 프로퍼티 / 속성
      • Self-contained : 자체포함. 토큰 자체가 정보
      • key : value
    • 두 개체에서 JSON 객체를 이용해 Self-contained 방식으로 정보를 안전하게 전달
    • 회원인증, 정보전달에 주로 사용,.

    Cookie와 Session의 차이점

    • 쿠키는 정보를 클라이언트에 저장하고
    • 세션은 정보를 서버에 저장한다.

    Session - Server Side Authorization

    세션과 쿠키의 문제점

    • 서버 확장 시 세션 정보 동기화의 문제
      • 서버 확장으로 서버가 여러개 생기면 각 서버마다 세션 정보가 저장된다.
      • 로그인 시(서버1), 새로고침(서버2)로 접근하면 서버는 인증아 안됐다고 판단한다.
      • 세션을 각 서버에 저장하지 않고 세션 전용 서버, DB에 저장해도 문제가 생긴다.
    • 웹/앱간의 상이한 쿠키-세션 처리로직
      • 웹/앱의 쿠키 처리 방법이 다르고 또 다른 클라이언트가 생겨나면 쿠키-세션에 맞게 처리해야 한다.
    • 이러한 문제를 해결하기 위해 '토큰'을 사용한다. 토큰은 서버의 상태를 저장하지 않는다. 토큰 자체로 정보를 가지고 있기 때문에 별도의 인증서버가 필요없다. 따라서 요청을 받을 서버 자체에서 인증 프로세스를 수행할 수 있다.

    JWT 구조

    • Header 
      • typ : 토큰의 타입.
      • alg : 해싱 알고리즘. 토큰 검증시 사용.
    • Payload
      • 실제 토큰으로 사용하려는 데이터가 담기는 부분. 각 데이터를 Claim 이라고 하며, 3가지 종류가 있다.
      • Reserved claims
      • Public claims
      • private claims (사용자 정의 )
    • Signature
      • Header와 Payload의 데이터 무결성과 변조 방지를 위한 서명.
      • Header와 Payload를 합친 후, Secret키와 함께 헤더의 해싱 알고리즘으로 인코딩

    JWT는 [Header Payload Signature] 각각 JSON 형태의 데이터를 base 64 인코딩 후 합친다.
    아래와 같은 순서로 . 을 이용해 합친다.
    최종적으로 만들어진 토큰은 HTTP 통신 간 이용되며, Authorization 이라는 key value로서 사용된다.



    출처: https://sanghaklee.tistory.com/47 [이상학의 개발블로그]

     

     


    1. 사용자가 로그인을 한다.

    2. 서버에서는 계정정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID값을 부여한 후, 기타 정보와 함께 Payload에 넣습니다.

    3. JWT 토큰의 유효기간을 설정합니다.

    4. 암호화할 SECRET KEY를 이용해 ACCESS TOKEN을 발급합니다.

    5. 사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 보냅니다.

    6. 서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효기간을 확인합니다.

    7. 검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져옵니다.  

     

    세션/쿠키 방식과 가장 큰 차이점은 세션/쿠키는 세션 저장소에 유저의 정보를 넣는 반면, JWT는 토큰 안에 유저의 정보들이 넣는다는 점입니다. 물론 클라이언트 입장에서는 HTTP 헤더에 세션ID나 토큰을 실어서 보내준다는 점에서는 동일하나, 서버 측에서는 인증을 위해 암호화를 하냐, 별도의 저장소를 이용하냐는 차이가 발생합니다.

     

    JWT 장점

    1. 간편합니다. 세션/쿠키는 별도의 저장소의 관리가 필요합니다. 그러나 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없습니다. 이는 Stateless 한 서버를 만드는 입장에서는 큰 강점입니다. 여기서 Stateless는 어떠한 별도의 저장소도 사용하지 않는, 즉 상태를 저장하지 않는 것을 의미합니다. 이는 서버를 확장하거나 유지,보수하는데 유리합니다.

    2. 확장성이 뛰어납니다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능합니다. 예를 들어 Facebook 로그인, Google 로그인 등은 모두 토큰을 기반으로 인증을 합니다. 이에 선택적으로 이름이나 이메일 등을 받을 수 있는 권한도 받을 수 있습니다. 

     

    여기까지의 글만 봤을 때는 JWT가 세션/쿠키 방식보다 더 효율적으로 보입니다. 하지만 JWT도 단점들이 존재합니다. 

    JWT 단점

    1. 이미 발급된 JWT에 대해서는 돌이킬 수 없습니다. 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버리면 됩니다. 하지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능합니다. 따라서 악의적인 사용자는 유효기간이 지나기 전까지 신나게 정보들을 털어갈 수 있습니다. 

    -> 해결책

    기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급합니다. 그렇게 되면 Access Token을 탈취당해도 상대적으로 피해를 줄일 수 있습니다. 이는 다음 포스팅에 나올 Oauth2에 더 자세히 다루도록 하겠습니다.

     

    2. Payload 정보가 제한적입니다. 위에서 언급했다시피 Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있습니다. (세션/쿠키 방식에서는 유저의 정보가 전부 서버의 저장소에 안전하게 보관됩니다) 따라서 유저의 중요한 정보들은 Payload에 넣을 수 없습니다.

     

    3. JWT의 길이입니다. 세션/쿠키 방식에 비해 JWT의 길이는 깁니다. 따라서 인증이 필요한 요청이 많아질 수록 서버의 자원낭비가 발생하게 됩니다.

     

    LOGIN (SESSION OAUTH JWT)

    PAGING

    3RD PARTY 

     

    프레임워크사용법 (컨트롤러,  pdo, index)

    path variable , query string, body

    jwt  발급과 검증

    'Programming > BackEnd' 카테고리의 다른 글

    개발환경 세팅  (0) 2020.05.13
    3. Backend Language, Restful, Framework  (0) 2020.05.11
    HTTP 패킷 / 메소드 / 상태코드와 메세지  (0) 2020.05.11
    2. DataBase  (2) 2020.05.05
    DBMS가 Sever-Client 구조를 취하게 된 이유  (0) 2020.05.03
Designed by Tistory.