1주차 WIL

1. JWT

 

이번주차에서는, 특히나 내가 로그인 기능 구현을 담당했기 때문에, JWT에 대해서 짚고 넘어가지 않을수 없을 것 같다.

 

Token 인증

 

• 토큰 기반 인증 시스템은 클라이언트가 서버에 접속을 하면 해당 클라이언트에게 인증되었다는 의미로 토큰을 부여한다.
• 이 토큰은 유일하며 토큰을 발급받은 클라이언트는 또 다시 서버에 요청을 보낼 때 요청 헤더에 토큰을 심어서 보낸다.
• 그러면 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치 여부를 체크하여 인증 과정을 처리하게 된다.

 

JWT이란?

 

JWT는 JSON Web Token의 약자로서, 인증에 필요한 정보들을 암호화 시킨 JSON 토큰을 의미한다.

JWT는 정보전달할때에 있어서, header, payload, signature로 나누어 전달한다.

 

header는 토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있다.

payload는 토큰에 담을 정보가 들어있다. 여기에 담은 정보의 한조각을 클레임이라고 부르고 이는 name:value 한쌍으로

이루어져 있다. 클레임은 등록된 클레임과 공개클레임, 비공개 클래임으로 나뉘어 진다.

signature(서명)은  헤더 base64 + 페이로드 base64 + SECRET_KEY ] 를 사용하여 JWT 백엔드에서 발행된다.
헤더 또는 페이로드의 정보가 클라이언트에 의해 변경된 경우 서명이 무효화된다.

 

JWT의 장점

 

• 무상태,확장성이 있다. 기존의 서버에 세션을 저장하는 방식에서는 서버 여러대를 사용하여 요청을 분산한다면 어떤 유저가 로그인 했을 때 그 유저는 처음 로그인한 서버에만 요청을 내보내도록 설정해야한다. 하지만 토큰은 토큰값만 알고 있다면 어떤 서버로 요청이 들어가던 상관이 없다.
• 보안성 쿠키를 전달할 필요가 없으므로 쿠키를 사용함으로써 생기는 단점이 상쇄된다.
• 여러 플랫폼, 어플리케이션 등의 규모가 커지면 그에 맞춰 여러 디바이스를 호환 시키고 더 많은 종류의 서비스를 제공한다. 토큰을 사용한다면 그 어떤 디바이스에서도 그 어떤 도메인에서도 토큰만 유효하다면 요청이 정상처리 된다.

 

JWT의 단점

 

• 길이 claim에 넣는 데이터가 많아질 수록 JWT 토큰이 길어진다.  API 호출시 매 호출마다 토큰 데이터를 전달 해야 하는데 길이가 길다는 것은 그만큼 네트워크의 대역폭 낭비가 심할 수 있다는 것.
• 보안 JWT는 기본적으로 payload에 대한 정보를 암호화 하지 않기 때문에 중간에 패킷을 가로채거나 토큰을 취득했다면, 디코딩을 통해 데이터를 볼 수 있다. 따라서 중요 정보는 payload에 넣지 말아야 한다.

 

2.Github

 

프로젝트하는 과정에서 Github 사용법에 대해 익혔다.

지금은 프로젝트를 진행할 수 있는 최소한의 지식만 갖춘 상태이다.

당연하게도 github를 능숙하게 다룰 줄 알아야겠다는 생각이 들었다.

주말을 활용해 남은 강의를 듣고 포스팅할 예정이다.

 

 3.협업과정에서 배운점

 

API를 구하는 과정에서 그리고 구해온 API를 뿌려주는 과정에서 차질이 생겼었다,

오픈소스를 구하는 것도 일이였고, 받아온 API를 원하는대로 뿌려주는 것도 일이였다.

실전에서나 겪을 수 있는 문제상황이였고 이 부분을 맡으신 팀원분이 결국 잘 해결해 주셨지만,

이러한 곤란했던 점들에 대해 더 공부가 필요하다고 생각이 들었다.

위와 같은 위기상황을 마주하고, 팀원분들과 논의하면서 많은 것을 배울 수 있었다.

 

CSS가 계속 충돌하는 문제가 발생했는데, 이 때문에 사전에 팀원분들과 

class명이나 id명을 협의해야겠다고 느꼈다. 협의할 시간이 없다면 주석이라도 잘 달아야 겠다고 생각했다.