TIL 57: [인증/보안] 기초 - 토큰(Token)

다음 주에 큰 시험 두 개가 겹치고 이동시간이 길어지다보니 블로그 관리하는데 정신이 없네요🥲 최대한 밀리지 않고 정리해보려도록 하겠습니다!

 

세션 기반 인증은 서버 혹은 DB에 유저 정보를 담는 인증 방식으로, 매 요청마다 서버에만 부담이 가중되는 인증 방식입니다. 서버 부담을 줄이기 위해 토큰 기반 인증이 나오게 되었고, 그 중 가장 대표적인 인증 방식은 JWT(JSON Web Token)입니다. 클라이언트에 암호화한 유저 정보를 보관하는 방법입니다. 

JWT의 종류

Access Token은 보호된 정보들(유저의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한부여에 사용합니다. 클라이언트가 처음 인증을 받게 될 때(로그인), access와 refresh token 두가지를 다 받지만, access token은 실제로 권한을 얻는데 사용하는 토큰으로 비교적 짧은 유효기간을 주어 탈취되더라도 오랫동안 사용할 수 없도록 합니다. access token의 유효기간이 만료된다면 refresh token을 사용하여 새로운 access token을 발급받음으로서 유저는 다시 로그인할 필요가 없습니다. 물론 refresh token 마저 탈취당할 수도 있습니다. 따라서 유저의 편의보다 정보를 지키는 것이 더 중요한 웹사이트들은 refresh token을 잘 사용하지 않습니다.

 

JWT 구조

Header

Header는 어떤 알고리즘으로 암호화한 어떤 종류의 토큰인지가 적혀 있습니다.

{ "alg": "HS256", "typ": "JWT" }

 

Payload

접근 권한, 유저 이름 등 필요한 데이터를 담아 암호화한 것입니다. 암호화가 되긴 했지만 되도록 민감한 정보는 담지 않는 것이 좋습니다.

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

 

Signature

원하는 비밀키를 사용하여 암호화합니다. 만약 HMAC SHA256 알고리즘을 사용한다면 아래와 같이 signature를 생성할 수 있습니다.

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

 

토큰 기반 인증 절차

클라이언트에서 토큰이 저장되는 위치는 local storage, cookie, react의 state 등 다양합니다.

클라이언트가 HTTP 헤더(authorization 헤더)에 토큰을 담아보낼 때 bearer authentication을 이용합니다.

 

 

토큰기반 인증의 장점

Statelesness & Scalability (무상태성 & 확장성)

서버는 클라이언트에 대한 정보를 저장할 필요가 없습니다. 클라이언트는 새로운 요청을 보낼 때마다 토큰을 헤더에 포함시키면 됩니다. 따라서 서버를 여러개 가지고 있는 서비스일 수록 토큰의 장점이 더 부각됩니다.

 

Safety (안정성)

암호화한 토큰을 사용하고, 암호화 키를 노출할 필요가 없기 때문에 클라이언트에 인증을 저장해도 안전합니다.

 

Convenience (편리성)

어디서나 토큰을 생성할 수 있습니다. 토큰 생성용 서버를 만들거나, 다른 회사에서 토큰 관련 작업을 맡기는 다양하게 생성할 수 있습니다. 또한 payload를 통해 어떤 정보에 접근 가능한지 권한을 간편하게 정할 수 있습니다.