[3] AccountService (1) 설계

1. Api 설계

• /account/signup : 회원 가입 API
• /account/login : 로그인 API
• /account/logout : 로그아웃 API
• /account/withdraw : 회원 탈퇴 API
• /account/reissue : AccessToken 재발급 API

2. Api FlowChart

3. 인증/인가

Session vs Token

HTTP는 Stateless하기 때문에 매 요청은 Client의 정보를 가지고 있지 않습니다.

사용자가 기능을 하나씩 사용할 때 마다 인증을 해야하는 것은 정말 번거로운 일입니다.

Server가 User를 특정하기 위해 사용하기 위해 Session과 Token을 사용합니다.

 

Sesison vs Token

 

Token 방식을 선택하게 된 이유는 인증/인가를 하는 과정에 있습니다.

 

1. Sesison 방식

세션 방식은 인증/인가가 필요한 요청을 보낼 때 마다 Server 측에 저장된 Session 정보를 확인해야 합니다.

 

2. Jwt Token 방식

 JwtToken 방식은 Header_PayLoad_Signature 구조로 이루어져 있습니다.

사용자의 정보가 담긴 PayLoad와 PayLoad의 정보가 암호화된 Signature의 비교로 인증/인가로 진행합니다.

 

JWT Token을 사용한 이유

- 매 요청마다 DB에 접근하는 세션과는 달리 Application Layer에서 인증/인가가 가능하여 속도가 빠르다고 판단

- RefreshToken도 DataBase에 저장하여 사용하지만 토큰 재발급시에만 접근하므로 DB의 트래픽 부담이 적다고 판단

- Netflix처럼 사용자의 수를 제한하는 비즈니스 요구사항이 있다면 Login 정보를 Server에 저장하는 Session 사용을 고려했을 테지만 다중 사이트의 Login이 가능한 비즈니스 요구사항으로 프로젝트를 진행하였음

- RefreshToken, Session 정보를 저장해둔 DB Server가 장애가 생겼다고 가정했을 때, Session 방식은 인증/인가가 필요한 기능 요청을 할 수 없지만 RefreshToken은 리프레시 토큰 자체를 DB에 저장하지 못하더라도 발급된 AccessToken을 통하여 인증/인가를 진행할 수 있을 것이라 판단했다.

 

JWT token의 단점도 알아보자

 

https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens

게시물에 따르면, JWT Token의 길이가 304Byte가 나왔지만, 세션 ID는 6바이트를 사용하여 트래픽을 사용할 때 비효율이 생긴다고 한다. 나의 JWT token은 180Byte 정도가 나와서 30배 정도이다. 매번 DB에서 확인하는 작업이 더 부하가 생기는지, Byte 차이에서 생기는 비효율이 더 부하가 생기는지 테스트할 예정이다. 

 

그 외의 이야기

보통 Session과 Token에 대해서 이야기 할 때, Session의 문제로 확장성을 꼽는다.

A 서버에서 로그인한 User는 A Server에 Session Data가 저장되어 있기 때문에 A Server에서만 인증/인가가 가능하다 라는 점이다.

( 참고 url : https://hudi.blog/session-consistency-issue/ )

하지만 Session 정보를 Server Session 저장소가 아니라 공용으로 사용할 수 있는 저장소에 저장하면 확장성이 해결된다고 생각한다. (ex_Redis)

이 프로젝트에서 JwtToken을 사용할 때도 Refresh Token을 사용하기 위해서 Redis Server에 저장하였다.

똑같이 Redis Storage에 저장하는 점에서 확장성 문제로 Session, Token을 방식을 선택하는 것에는 중요도가 덜 한 것 같다.