토큰이란 통행증과 같은 개념이다.
클라이언트로 로그인할 시 서버에서 인증을 거친 다음 토큰을 내어주는 방식으로 다음 부터 서버에 요청시 토큰을 같이 보내어 인증을 가진다.
토큰 기반 인증은 왜, 그리고 언제 쓸까요?
세션 기반 인증은 서버(혹은 DB)에 유저 정보를 담는 인증 방식이었습니다.
매 요청마다 데이터베이스를 살펴보는 것이 불편하고, 이 부담을 덜어내고 싶다면 어떤 방법이 있을까요?
이럴 때 사용할 수 있는 토큰 기반 인증 중 대표적인 JWT (JSON Web Token)에 대해서 알아봅시다.
클라이언트에서 인증 정보 보관
클라이언트가 토큰을 가지고 있다면 보통의 다른(돈을 내지 않은) 유저들과는 다르게 서버에서 제공하는 다양한, 더 프리미엄한 기능을 요청할 수 있을 것입니다.
토큰을 클라이언트에 저장해도 정말 괜찮은 걸까요?
토큰은 유저 정보를 암호화한 상태로 담을 수 있고, 암호화했기 때문에 클라이언트에 담을 수 있습니다.
JWT의 종류
1. Access Token: 짧아야 한다.(짧은 유효기간)
-> 권한을 가질 수 있게 해주는 부여에 사용
-> 클라이언트가 처음 인증을 받게 될 때(로그인 시),
access, refresh token 두가지를 다 받지만, 실제로 권한을 얻는 데 사용하는 토큰은 access token이다.
2.Refresh Token: 길어야함(기간)
-> 만료되면 로그인 풀림
->액세스 토큰을 새로 발급시켜준다.
->이때, 유저는 다시 로그인할 필요가 없다.
토큰기반 인증의 장점
1. Statelessness & Scalability (무상태성 & 확장성)
- 서버는 클라이언트에 대한 정보를 저장할 필요 없다.(토큰 해독이 되는지만 판단한다.)
- 클라이언트는 새로운 요청을 보낼때마다 토큰을 헤더에 포함시키면 된다.
- 서버를 여러개 가지고 있는 서비스라면 더더욱 빛을 발휘한다. (같은 토큰으로 여러 서버에서 인증 가능)
2. 안전하다
- 암호화 한 토큰을 사용하고, 암호화 키를 노출 할 필요가 없기 때문에 안전하다
3. 어디서나 생성 가능하다
- 토큰을 확인하는 서버가 토큰을 만들어야 하는 법이 없다.
- 토큰 생성용 서버를 만들거나, 다른 회사에서 토큰관련 작업을 맡기는 것 등 다양한 활용이 가능하다.
4. 권한 부여에 용이하다
- 토큰의 payload(내용물) 안에 어떤 정보에 접근 가능한지 정할 수 있다.(서비스의 사진과 연락처 사용권한만 부여할 수 있음)
JWT의 구조
Header
Header는 이것이 어떤 종류의 토큰인지(지금의 경우엔 JWT), 어떤 알고리즘으로 sign(암호화) 할지가 적혀있다.
JSON Web Token 이라는 이름에 걸맞게 JSON형태로 이런 형태를 볼 수 있다.
{
"alg": "HS256",
"typ": "JWT"
}
Payload
Payload에는 정보가 담겨 있다.
어떤 정보에 접근 가능한지에 대한 권한을 담을 수도 있고, 사용자의 유저 이름 등 필요한 데이터는 이곳에 담아 암호화 시킨다.
물론 암호화(헤더에서 정의한)가 될 정보지만, 민감한 정보는 되도록 담지 않는 것이 좋다.
{
"sub": "someInformation",
"name": "phillip",
"iat": 151623391
}
Signature
base64로 인코딩된 첫번째, 그리고 두번째 부분이 완성 되었다면, 원하는 비밀 키(암호화에 추가할 salt)를 사용하여 암호화한다.
HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);JWT 사용 흐름
- 클라이언트가 아이디와 비밀번호를 담아 서버에 로그인 요청을 보낸다.
- 아이디/비밀번호 확인 후 일치하면 클라이언트에게 암호화된 토큰을 생성한다.(access/refresh)
- 토큰을 클라이언트에게 보내주면 클라이언트는 토큰을 저장한다.
- 저장하는 위치는 local storage, cookie, react의 state등 다양함
- 클라이언트가 http header에 토큰을 담아 보낸다.
- 서버는 토큰을 해독하여, "우리가 발급해준 토큰이네" 라고 판단되면, 클라이언트의 요청을 처리하여 응답한다.
