Weekly I Learned 1 - JWT, API

Keyword 1. JWT

• JWT(Json Web Token) : Json 형식으로 사용자에 대한 속성을 저장하는 웹토큰.
• 구조 : Header, Payload, Signature의 세 부분으로 이루어짐.
  • 각 부분은 Base64로 인코딩 되어 표현 
    • Header   { "alg": "HS256", "typ": JWT } 
      • alg : 알고리즘 방식을 지정. 서명(signature)/토큰 검증에 사용
      • typ : 토큰의 타입
    • Payload : 토큰에서 사용할 정보의 조각들(claim)이 담긴다.
      • 클레임의 종류 3 가지
        • 등록된 클레임 : 토큰 정보 표현을 위한 정해진 종류의 데이터. 선택적 작성 가능
        • 공개 클레임 : 사용자 정의 클레임이자 공개용 정보 저장, 충돌방지를 위해 URI 포맷 사용
        • 비공개 클레임 : 사용자 정의 클레임이자 비공개용 정보 저장
    • Signature : 토큰 인코딩 / 유효성 검증에 사용되는 암호화 코드
      • 헤더와 페이로드의 값을 Base64로 인코딩하고
      • 인코딩한 값을 secret key를 이용해 헤더에 정의된 알고리즘(alg)으로 해싱하고,
      • 그 값을 다시 Base64로 인코딩해서 생성.
• JWT의 단점
  • JWT는 서버 측에서 통제할 수 없다. 즉 상태를 저장/관리할 수 없어 Stateless하다고 하는데, 그렇기에 이미 발급된 토큰은 삭제할 수가 없다. 그래서 만료시간이 지정된다.
• JWT의 장점
  • 토큰방식과 비교할 수 있는 사용자 인증/인가 방식은 서버(세션) 기반의 인증이다. 서버 기반 시스템에서는 사용자가 인증할 때 정보를 세션(session)에 저장한다. 이는 메모리에 저장되거나 또는 데이터베이스에 저장되어야 하므로 서버나 데이터베이스에 부담이 된다. 토큰은 그런 정보 저장/관리가 필요하지 않으니 부담도 없다.
• 작은 느낌
  • 이전에 로그인이라는 걸 처음 구현할 때는 세션을 활용했었다. 그런데 이번에 토큰 방식으로 하려다보니 굉장히 신기하고도 낯설었다. 서버에서 마음대로 사용자 로그아웃을 시킬 수 없다니..? 이런 점들이 얼마나 다른지 느낄 수 있었고 솔직히 불편하다는 느낌도 있었지만..! 세션을 이용하면 서버에 부담이 간다고 하니까. 좀 더 공부해보면서 어떤 상황에는 어떤 방식의 인증/인가 방식을 택하는 것이 좋은지 더 공부해봐야겠다.

Keyword 2. API

• API(Application Programming Interface)
  • UI(User Interface)는 일반 사용자가 화면이나 키보드 등을 통해 시스템과 상호작용하기 위한 규칙/루틴 같은 것이라면,
  • API는 이런 UI처럼, 심층(?)의  프로그램이나 다른 프로그램 같은 것들을 활용하거나 소통하기 위한 규칙/루틴들이다.
  • Database에 접근하여 정보를 이렇게 저렇게 사용하는 규칙이라든지, 서버와 클라이언트가 상호작용하는 방식이라든지 등을 표준화해두는 규격/규칙/루틴이라고 할 수 있지 않을까 싶다. 
  • 지금도 잘은 모르지만, 이전에 오픈 API 이런 이야기 들을 때는 일종의 정보 제공 창구 정도인가 싶었을 정도로 정말 몰랐다.
  • 물론 그런 역할도 수행할 수야 있겠지만 API는 타 프로그램,서비스 같은 것과 소통하기 위한 창구이자, 그 창구의 사용규칙/루틴 등을 의미한다고 볼 수 있을 것 같다.
• 작은 느낌
  • 이번에 항해99 1주차 미니 프로젝트를 하면서도, 코딩에 들어가기 앞서서 우리에게 필요한 API들을 약속해두었다. 물론 작은 범위와 규모에서의 오고 감이었지만, html-python 파일을 오고가는 나의 작은 움직임 속에서도 약속된 API는 중요한 역할을 하는 것을 느낄 수 있었다(고 하기 조금 많이 민망하지만 어쨌든 그렇다!ㅎㅎ)