이번주는 4일동안 웹사이트를 만드는 미니 프로젝트를 진행하고 배포까지 해봤다.
막히는 부분도 많았지만 팀원들이 서로서로 도와가며 완성했습니다.
협업을 위한 깃 사용에서 문제가 많았는데 깃은 앞으로 틈틈히 공부해놔야 할거 같습니다.
프로젝트를 진행하며 알게된 JWT, API를 정리해 보려한다.
JWT(Json Web Token)
정보를 비밀리에 전달하거나 인증할 때 주로 사용하는 토큰으로, Json객체를 이용한다.
JWT는 Json Web Token의 약자로 일반적으로 클라이언트와 서버 사이에서 통신할 때 권한을 위해 사용하는 토큰이다. 웹 상에서 정보를 Json형태로 주고 받기 위해 표준규약에 따라 생성한 암호화된 토큰으로 복잡하고 읽을 수 없는 string 형태로 저장되어있다.
JWT의 구성요소
- 헤더 (Header)
어떠한 알고리즘으로 암호화 할 것인지, 어떠한 토큰을 사용할 것 인지에 대한 정보가 들어있다. - 정보 (Payload)
전달하려는 정보(사용자 id나 다른 데이터들, 이것들을 클레임이라고 부른다)가 들어있다.
payload에 있는 내용은 수정이 가능하여 더 많은 정보를 추가할 수 있다. 그러나 노출과 수정이 가능한 지점이기 때문에 인증이 필요한 최소한의 정보(아이디, 비밀번호 등 개인정보가 아닌 이 토큰을 가졌을 때 권한의 범위나 토큰의 발급일과 만료일자 등)만을 담아야한다. - 서명 (Signature)
가장 중요한 부분으로 헤더와 정보를 합친 후 발급해준 서버가 지정한 secret key로 암호화 시켜 토큰을 변조하기 어렵게 만들어준다.
한가지 예를 들어보자면 토큰이 발급된 후 누군가가 Payload의 정보를 수정하면 Payload에는 다른 누군가가 조작된 정보가 들어가 있지만 Signatute에는 수정되기 전의 Payload 내용을 기반으로 이미 암호화 되어있는 결과가 저장되어 있기 때문에 조작되어있는 Payload와는 다른 결과값이 나오게 된다.
이러한 방식으로 비교하면 서버는 토큰이 조작되었는지 아닌지를 쉽게 알 수 있고, 다른 누군가는 조작된 토큰을 악용하기가 어려워진다.
JWT의 장단점
- JWT의 장점
- 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요 없습니다.
- 쿠키를 전달하지 않아도 되므로 쿠키를 사용함으로써 발생하는 취약점이 사라집니다. 하지만, 토큰을 사용하는 환경에서의 취약점에 대비해야 합니다.
- 트래픽 대한 부담이 낮음
- JWT의 단점
- 이미 발급된 JWT를 돌이킬 수 없다. 서버 기반 인증 시스템처럼 저장소를 사용하는 경우에는 해당 세션이 악의적으로 사용될 경우 지워버리면 되지만, JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하다.
- JWT의 길이가 길다. 인증이 필요한 요청이 많아질수록 서버의 자원 낭비가 발생한다.
이번 프로젝트에서 JWT를 사용한 로그인구현을 내가 맡아서 하진 않아서 공부가 덜되어 있습니다. 항해 99측에서 제공하는 JWT에 대한 강의와 예제를 보면서 조금 더 공부해야겠습니다.
API
API란 Application Programming Interface의 약자로,
한 프로그램에서 다른 프로그램으로 데이터를 주고받기 위한 방법 이다.
API 역할
1 . API는 서버와 데이터베이스에 대한 출입구 역할을 한다.
- 데이터베이스에는 정보들이 저장되므로 모든 사람들이 데이터베이스에 접근할 수 있으면 안된다. API는 이를 방지하기 위해 여러분이 가진 서버와 데이터베이스에 대한 출입구 역할을 하며, 허용된 사람들에게만 접근할 수있게 해줍니다.
2 . API는 어플리케이션과 기기가 원활하게 통신할 수 있도록 한다.
- API는 어플리케이션과 기기가 데이터를 원활히 주고받을 수 있도록 돕는 역할을 한다.
3 . API는 모든 접속을 표준화한다.
- API는 어플리케이션과 기기가 데이터를 원활히 주고받을 수 있도록 돕는 역할을 한다.
이번 프로젝트에서 게시판 구현하는 부분을맡아서 api에 대한 개념은 좀 잡히고 많이 익숙해진거 같다. 그래도 많이 어려워서 계속공부해 나가야 할 것 같습니다.
