🔍 Token

세션 기반 인증은 서버(or DB)에 유저 정보를 담는 방식으로, 매 요청마다 DB를 살펴보는 것이 불편하고 서버에 부담을 준다.
따라서 서버 부담을 줄이기 위해 고안한 방법으로, 대표적인 토큰 기반 인증은 JWT(JSON Web Token)이 있다.

토큰은 암호화된 상태의 유저 정보를 가지며, 암호화했기때문에 클라이언트에 담을 수 있다. 따라서, 클라이언트에서 인증 정보를 보관한다.

👀 JWT

Json Web Token의 약자로, Json 포맷으로 사용자에 대한 속성을 저장하는 웹 토큰을 의미한다.

엑세스 토큰(Access Token) 과 리프레시 토큰(Refresh Token) 을 필요에 맞게 이용해 인증을 구현하는데, 권한을 부여 받는데에는 엑세스 토큰만 가지고 있으면 되고, 정보를 지키는 것이 중요한 웹사이트의 경우, 리프레시 토큰을 사용하지 않는다.

권한 부여에 굉장히 유용하다.
예를들어 A앱에서 Gmail과 연동되어 이메일을 읽어와야한다면, 유저가 Gmail 인증 서버에 로그인 정보를 제공했을 때, JWT를 발급받고, A앱은 JWT를 사용해 유저의 Gmail 이메일을 읽을 수 있게되는 것이다.

✔ JWT 구조

세 부분 모두 base64 방식으로 인코딩된다.

• Header
  
  어떤 종류의 토큰인지, 어떤 알고리즘으로 시그니처를 암호화(sign)할 것인지 JSON 형태로 명시되어 있다.

• Payload
  
  서버에서 활용할 수 있는 유저의 정보가 담겨 있다. 시그니처를 통해 유효성 검증이 되지만, 디코딩이 쉽기 때문에 민감한 정보는 담지 않는 것이 좋다.

• Signature
  
  서버의 비밀 키와 헤더에서 지정한 알고리즘을 사용하여 암호화한다.
  앞의 Header와 payload와는 다르게 비밀키를 사용해 암호화한 값이므로, 보안성이 높다.

👀 토큰 기반 인증 과정

1. Client -> Server : ID/password를 담아 로그인 요청

2. Server : ID/password 확인 후, Client에 보낼 암호화된 토큰 생성(access, refresh 모두 생성)

3. Server -> Client : 토큰 전송

4. Client : 토큰 저장(in Local Storage, Session Storage, Cookie 등)

5. Client -> Server : HTTP Header(Authentication Header) 또는 쿠키에 토큰을 담아서 전송(ex. Cookie에는 refresh 토큰, body에는 access 토큰 담아서 전송), Authentication Header 사용 시 Bearer Authentication을 이용.

6. Server : 토큰 해독, 발급해준 토큰이 맞다면 Client의 요청을 처리 후 응답 전송

✔ 장점

• 무상태성 & 확장성(Statelessness & Scalability)
  서버는 클라이언트의 정보를 저장할 필요가 없고, 클라이언트는 요청을 보낼때 마다 토큰을 헤더에 포함시키면 된다.
  
  

• 암호화한 토큰을 사용하고, 암호화 키를 노출할 필요가 없기때문에 안전하다.
  
  

• 어느 서버에서나 생성이 가능하다.
  
  

• 권한 부여에 유용하다.
  payload 안에 어떤 정보에 접근 가능한 지 정할 수 있다.

Reference: 코드스테이츠
https://hackernoon.com/using-session-cookies-vs-jwt-for-authentication-sd2v3vci