- JWT소개
1-1 JWT란?
Json Web Token의 약자이다.
JSON 객체를 사용하여 가볍고 자가수용적인 (self-contained) 방식으로 정보를 안전성 있게 전달해주기 위한 토큰입니다.
1-2 JWT 구조
1)HEADER: 사용한 해쉬알고리즘
서명(id,password)에 해당하는 부분을 암호화 시킬 필요가 있는데 해독 알고리즘 정보가 담겨있다.
2)PAYLOAD: 담을 내용
3)SIGNATURE: 서명 (ID+PASSWORD)
1-3 JWT 사용과정
1.브라우저의 로그인과정에서 회원정보를 입력합니다.(ID,PASSWORD)
2.서버는 JWT를 만듭니다.
3.서버는 브라우저에게 JWT를 보냅니다.
4.브라우저는 JWT를 가지고 서버에게 데이터를 요청합니다.
5.서버는 서명을 확인하고 유저 정보를 클라이언트에게 제공합니다.
1-4 JWT의 사용목적
회원인증: JWT를 이용해서 회원정보를 주고 받게 되면 유저의 정보를 세션에 유지할 필요가 없게 됩니다. 즉 stateless 한 서버를 만들 수 있게 도와줍니다. 이전방식은 브라우저와 서버의 세션영역에 로그인 정보가 저장되어있는 Statefull한 서버였습니다.
정보교류: 데이터를 주고받을때 안정성있게 정보 교환할 수 있게 도와줍니다.
1-5 저장방식
Session or Local :
특징 : statefull
필수 데이터, 세션 / 사용자 ID의 일부만 포함하고 나머지는 서버 측에 저장되는 토큰입니다.
이 솔루션은 토큰을 예측할 수없고 공격자가 검색 할 수 없 다는 점을 고려하여 기본적으로 CSRF 공격으로부터 애플리케이션을 보호합니다
확장성에 제한이 있습니다.
Cookie:
특징: stateless
백엔드에서 표현이 필요하지 않은 자체 포함 토큰입니다.
브라우저의 쿠키에 저장되면 "HttpOnly"플래그 (및 "Secure")를 설정하여 XSS 공격의 경우 토큰 도난으로부터 보호 할 수 있습니다. 이 구현의 단점은 토큰에서 CSRF 보호를 기대할 수 없다는 것입니다. 실제로 토큰은 쿠키와 함께 자동으로 전송됩니다(CSRF).
이러한 구현은 "Stateless"으로 유지되지만 서로 다른 도메인의 서로 다른 응용 프로그램간에 원활한 통합을 제공하지 않습니다. 쿠키는 도메인 (또는 하위 도메인)에 연결되며 다른 도메인에서 호스팅되는 다른 응용 프로그램에서 사용할 수 없습니다.
1-6 활용
JWT 인증은 오늘날 인증을위한 업계 표준 프로토콜 인 OAuth2 로 수행됩니다.
Service to Service인증: 예를 들어 Login with Google , Login with Facebook 과 같은 로그인 옵션이 제공 됩니다. 이것들은 모두 JWT 인증의 적용입니다 .
1-7 단점
사용자 계정을 차단하거나 비활성화해야하는 경우 응용 프로그램은 잠금이 완전히 적용되도록 토큰이 만료 될 때까지 기다려야합니다
사용자가 비밀번호를 변경해야하는 경우 (예 : 계정 도용의 경우) 사전에 인증을 수행 한 경우 이전 비밀번호로 생성 된 토큰은 만료 될 때까지 유효합니다.
표준 구현에서는 "새로 고침"토큰을 지정하지 않습니다. 따라서 만료시 사용자는 다시 인증해야합니다.
JWT 토큰의 "상태 비 저장"측면을 위반하지 않고는 토큰을 파기 할 수 없습니다. 토큰이 브라우저에서 삭제 되더라도 만료 될 때까지 유효하므로 실제 로그 아웃이 불가능합니다.
참고자료
[Learn how JSON Web Tokens (JWT) works] https://medium.com/@dleroari/learn-the-basics-of-json-web-tokens-jwt-and-how-it-works-in-practice-8b3b14cbe0f9
[JWT tokens and security – working principles and use cases] https://www.vaadata.com/blog/jwt-tokens-and-security-working-principles-and-use-cases/
[Session vs Token Based Authentication] https://medium.com/@sherryhsu/session-vs-token-based-authentication-11a6c5ac45e4
[JSON Web Tokens vs. Session Cookies] https://ponyfoo.com/articles/json-web-tokens-vs-session-cookies
API
API 개념과 장점
흔히 API를 레스토랑에 빗대어 표현하기도 한다. 손님(내가 만드는 프로그램)이 자리에 앉아 웨이터(API)에게 주문을 한다. 그럼 웨이터는 내 주문 내역을 주방(API 제공자. 기상청, 공공포탈 등)에 갖다준다. 주방에서 요리를 해 웨이터에게 주면 웨이터가 다시 나에게 음식을 가져다준다. 웨이터가 손님의 주문을 주방으로 전달하는 매개체 역할을 하는 것이다.
여기서 손님은 주방에서 무슨 일이 일어나는지 잘 모른다. 대개는 관심도 없으며 관심을 가질 필요도 딱히 없다. 이것이 API의 장점이다. 내가 가져다쓰려는 API의 기능을 어떻게 구현하는지 몰라도 되고 난 그저 API가 갖다주는 걸 사용만 하면 된다(식사한다)는 것이다. 시간과 노력을 동시에 아낄 수 있다. 이처럼 API는 처음부터 개발하거나 유지 보수할 필요가 없는 외부 데이터와 기능에 접속할 수 있게 해준다.
API는 문서 공개 없으면 쓸 수 없다
아까도 설명했듯이 API는 프로그램과 프로그램 간 다리, 프로그램을 위한 인터페이스이다. 조금 더 자세하게 설명하자면 데이터를 주고 받기 위한 방법과 그 규격을 뜻한다고도 할 수 있다. 무슨 데이터? 환율 정보, 미세먼지 정보, 날씨 정보가 바로 그것이다.
API는 public, protected, private API 등으로 나뉘어 있는데 public은 우리가 다 알고 쓰는 그 공공 포탈 API다. 공공 포탈이 아니더라도 개발자 등록을 하고 키를 받아서 얼마간 무료로 쓸 수 있는 건 거의 다 public이라고 보면 된다. 이에 반해 private은 API 제공자가 API를 공개하지 않은 것이다. 쉽게 말하면 사용법을 알려주지 않아서 쓸 수가 없어서 개발자가 그 제공자의 API를 쓸 수 없다. API 문서가 바로 이 사용법과 규격을 제공하는 문서이다. 이 사용법이 제공되어 있지 않다면 private이다. 보통 API 제공자들은 DB, 기능을 모듈화해서 인증받은 사용자(개발자 키가 있는 사람들)에게 규격화된 명령으로 데이터를 가져갈 수 있게 한다.
참고자료
https://dydrlaks.medium.com/api-%EB%9E%80-c0fd6222d34c
https://velog.io/@geunwoobaek/JWT%EB%9E%80
