토큰을 쓰는 이유
세션 기반 인증은 서버에 유저정보를 담는 인증 방식이었다
서버에서는 제한된 정보를 유저가 요청할 때마다 정보를 줘도 되는지 확인하기 위해서 서버가 가지고 있는 세션 값과 일치하는지 확인해야 했다
이 확인 작업을 덜어 줄 수 있는 것이 토큰이다
토큰 기반 인증 중 대표적인 JWT (JSON Web Token)을 배워보자
클라이언트에 인증 정보 보관 -> 안전한가?
클라이언트에서 인증 정보를 보관하는 방법으로 토큰 기반 인증이 만들어 졌다
그런데 클라이언트는 XSS, CSRF 공격에 노출이 될 위험이 있으니 민감한 정보를 담고 있어서는 안된다고 배웠다
인증에 사용되는 토큰을 클라이언트에 담아도 되나? 라는 의문이 들 수 있다
토큰은 유저 정보를 암호화한 상태로 담을 수 있고, 암호화했기 때문에 클라이언트에 담을 수 있다
JWT의 종류
두가지의 토큰이 존재한다
1.Access Token
2. Refresh Token
Access token은 보호된 정보(유저의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한부여에 사용한다
클라이언트가 처음 인증을 받게 될 때(로그인 시), access, refresh token 두 가지를 다 받지만, 실제로 권한을 얻는 데 사용하는 토큰은 access token이다
권한을 부여받을 때 access token만 있으면 되기 때문에
만약에 access token이 해킹당한다면 서버에 나인 것 처럼 해커가 요청을 보낼 수 있다
그래서 access token에 짧은 유효기간을 줘서 탈취되더라도 오래 사용 할 수 없도록 하고 access token의 유효기간이 만료되면
refresh token으로 새로운 access token을 발급받아서 사용 하도록 한다 이때 다시 로그인 할 필요는 없다
JWT의 구조
JWT는 위 그림과 같이 . 으로 나누어진 3부분이 존재한다
1) Header
Header는 어떤 종류의 토큰인지(지금은 JWT), 어떤 알고리즘으로 sign할지가 적혀있다
JSON Web Token이라는 이름에 맞게 JSON 형태로 작성된다
{
"alg": "HS256",
"typ": "JWT"
}JSON 객체를 base64 방식으로 인코딩하면 JWT의 첫 번째 부분이 완성된다
2) Payload
Payload에는 정보가 담겨 있다
어떤 정보에 접근 가능한지에 대한 권한을 담거나 사용자의 유저 이름 등 필요한 데이터는 이곳에 담아 Sign 시킨다
Payload 에는 민감한 정보는 되도록 담지 않는 것이 좋다
{
"sub": "someInformation",
"name": "phillip",
"iat": 151623391
}JSON 객체를 base64로 인코딩하면 JWT의 두 번째 블록이 완성된다
3) Signature
base64로 인코딩된 첫 번째, 두 번째 부분이 완성되면
원하는 비밀 키(암호화에 추가할 salt)를 사용하여 암호화한다
HMAC SHA256 알고리즘(암호화 방법)을 사용하면 signature는 아래와 같은 방식으로 생성됩니다.
HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);
토큰기반 인증 절차
- 클라이언트가 서버에 아이디/비밀번호를 담아 로그인 요청을 보낸다
- 아이디/비밀번호가 일치하는지 확인하고, 클라이언트에게 보낼 Signature 된 토큰을 생성한다
2-1. access/refresh 토큰을 모두 생성한다
토큰에 담길 정보(payload)는 유저를 식별할 정보, 권한이 부여된 카테고리(사진, 연락처, 기타 등등)이 될 수 있다
두 종류의 토큰이 같은 정보를 담을 필요는 없다 (이 스프린트에서는 같은 정보를 담아준다)- 토큰을 클라이언트에게 보내주면, 클라이언트는 토큰을 저장한다
- 클라이언트가 HTTP 헤더(authorization 헤더)에 토큰을 담아 보낸다
4-1. bearer authentication을 이용한다. 참고 링크1(요약), 링크2(상세)- 서버는 토큰을 해독해서 발급해준 토큰이 맞다면 클라이언트의 요청을 처리한 후에 응답을 보내준다
토큰기반 인증의 장점
-
Statelessness & Scalability (무상태성 & 확장성)
서버는 클라이언트에 대한 정보를 저장할 필요가 없다 (토큰 해독이 되는지만 판단하면 된다)
클라이언트는 새로운 요청을 보낼 때마다 토큰을 헤더에 포함시키면 된다
서버를 여러 개 가지고 있는 서비스라면 같은 토큰으로 여러 서버에서 인증이 가능하기 때문에 더 편리하다 -
안전하다
signature을 받은 토큰을 사용하고, 암호화 키를 노출할 필요가 없기 때문에 안전하다 -
권한 부여가 쉽다
토큰의 payload(내용물) 안에 어떤 정보에 접근 가능한지 정할 수 있다
ex) 서비스의 사진 사용 권한만 부여
토큰기반 인증의 단점
JWT토큰의 단점은 용량이 크다는 것이다
내용물이 들어있기 때문에 랜덤한 토큰을 사용 할 때보다 용량이 크다
요청을 할 때마다 토큰이 오고 가므로 데이터양이 증가한다
랜덤스트링을 사용해서 매번 사용자 정보를 조회하는 작업의 비용과
내용물이 들어있는 jwt토큰을 사용해서 발생하는 데이터 비용 중 어떤 것이 더 큰지에 따라 사용하면 된다
