토큰

세션 vs 토큰

세션 기반 인증은 서버(혹은DB)에 유저정보를 담는 인증방식이다.
서버에서는 민감하거나 제한된 정보를 요청하는 메시지를 받을때마다 보안을 위해 요청메시지의 정보를 서버가 갖고 있는 세션값과 일치하는지 확인한 후 응답을 한다.

매 요청마다 DB를 살펴보는 작업이 반복되면 서버에 부하가 생길 수 있다.

토큰 기반 인증은 서버의 부하를 덜어줄 수 있다.

토큰

토큰은 클라이언트에서 인증 정보를 보관하는 방법이다.
클라이언트가 토큰을 가지고 있다면 토큰을 갖고 있지 않은 유저들과는 다르게 서버에서 제공하는 더 다양한 기능들을 요청할 수 있다.

그런데 클라이언트는 XSS,CSRF 공격에 노출될 위험이 있으니 민감한 정보를 담으면 안된다고 알고 있다.

하지만 토큰은 유저정보를 암호화한 상태로 담을 수 있기 때문에 안전하다.

 

그래도 비번같은것은 담지 말자

JWT

JWT(JSON Web Token)은 토큰 기반 인증 중 대표적인 방법중 하나이다.

1. Access Token
2. Refresh Token

Access Token

Access Token 은 보호된 정보들(유저의 개인정보 같은것들)에 접근할 수 있는 권한부여에 사용한다.

클라이언트가 처음 인증을 받게 될 때(로그인 시) access token, refresh token 두가지를 다 받지만,

실제로 권한을 얻는 데 사용하는 토큰은 access Token 이다.

하지만 access Token이 영원하다면 누군가 access Token의 정보를 알아냈을때, 언제든지 해킹할 수 있을것이다.
그래서 access Token에는 짧은 유효기간을 주어 금방 금방 수정되도록 한다.

Refresh Token

Refresh Token 은 Access Token의 유효기간이 만료되었을 때 Access Token을 재발급 해주는 역할을 한다.

 

Refresh Token이 탈취당하면 Access Token을 막 만들 수 있기 때문에 Refresh Token의 보안은 아주 중요하다.

 

유저의 편리함보다 보안에 더 초점을 맞추는 웹사이트들은 refresh token도 탈취당할 것을 우려해 다른 더 강력한 방법으로 정보를 숨긴다.

JWT 구조

1. header : 어떤 종류의 토큰인가? 어떤 알고리즘으로 암호화 하는가??

"alg":"HS256",
"typ":"JWT"

2. payload : 유저정보, 권한 부여 받았는가, 기타 필요한 정보(비번등 민감한 정보는 담지 않는다)

{
  "sub": "someInformation",
  "name": "phillip",
  "iat": 151623391
}

3. signature : header, payload를 base64인코딩한 값, salt 조합으로 암호화된값

HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);

토큰기반 인증 절차

 

코드스테이츠 자료

1. 클라이언트가 서버에 아이디/비밀번호를 담아 로그인 요청을 보낸다.
2. 아이디/비밀번호가 일치하는지 확인하고, 클라이언트에게 보낼 암호화된 토큰을 생성한다.
   • access/refresh 토큰을 모두 생성한다.
     • 토큰에 담길 정보(payload)는 유저를 식별할 정보, 권한이 부여된 카테고리(사진, 연락처, 기타등등)이 될 수 있다.
     • 두 종류의 토큰이 같은 정보를 담을 필요는 없다 
3. 토큰을 클라이언트에게 보내주면, 클라이언트는 토큰을 저장한다.
   • 저장하는 위치는 local storage, cookie, react의 state 등 다양하다. 하지만 보안상 local storage는 추천하지 않는다.
4. 클라이언트가 HTTP 헤더(authorization 헤더)에 토큰을 담아 보낸다.
   • bearer authentication을 이용한다. 참고 링크1(요약), 링크2(상세)
5. 서버는 토큰을 해독하여 "아 우리가 발급해준 토큰이 맞네!" 라는 판단이 될 경우, 클라이언트의 요청을 처리한 후 응답을 보내준다.

 

토큰기반 인증의 장점

 

1. Statelessness & Scalability (무상태성 & 확장성)

• 서버는 클라이언트에 대한 정보를 저장할 필요가 없다 (토큰 해독이 되는지만 판단)
• 클라이언트는 새로운 요청을 보낼때마다 토큰을 헤더에 포함시키면 된다. -> 서버가 여러개일때 같은 토큰으로 여러서버에서 인증 가능

2. 안전하다

• 암호화한 토큰을 사용하고 암호화 키를 노출할 필요가 없다.

3. 어디서나 생성 가능

• 토큰을 확인하는 서버가 토큰을 만들어야 하는 법이 없다.
• 토큰 생성용 서버를 만들거나, 다른 회사에서 토큰관련 작업을 맡기는 것 등 다양한 활용이 가능하다

4. 권한 부여에 용이하다.

• 토큰의 payload안에 어떤 정보에 접근 가능한지 정할 수 있다. (ex: 서비스의 사진과 연락처 권한만 부여)