토큰 기반 인증 (Token-based Authentication)에 대하여

세션 기반 인증은 서버/DB에 유저 정보를 담는 방식이었다.

매번 서버에 민감한 정보를 요청할 때 마다, 서버에서는 올바른 접근인지를 확인하는 과정이 필요하고, 이는 서버에 부하를 줄 수 있다.
🚋 때문에, 하나의 서버에서 인증 정보를 관리하게 되고 이는 하나의 서버에 큰 부담을 주게 된다.

토큰 기반 인증은 서버의 인증 정보를 클라이언트에 저장하는 방법이다.

클라이언트가 토큰을 가지고 있다면, 서버의 민감한 정보에 접근할 수 있다.
🗺 서버에 요청을 보낼 때 마다 토큰을 보내어 유효한지 확인한 뒤에 response를 받을 수 있다.

🍟 토큰은 유저의 민감한 정보를 암호화했기에 안전하게 클라이언트에 저장할 수 있다.

JWT (JSON Web Token)

JWT에는 두 가지 종류의 토큰이 있다.
🍔 Access Token, Refresh Token

Access Token을 통해서 민감한 정보에 접근할 수 있다.
두 가지 토큰중에서 실제 권한에 접근하는 토큰이다.
짧은 유효기간을 가진다.

Refresh Token을 통해서 만료된 Access Token을 발급받을 수 있다.
Access Token보다 긴 유효기간을 가진다.
🧁 이때, 유저는 다시 로그인하지 않아도 된다. Access Token을 통해 요청에 실패했을 때, Refresh Token으로 다시 Access Token을 발급받고, 이를 통해서 다시 로그인을 할 수 있다.

Refresh Token이 탈취당하면, 위험하기에 정보에 민감한 사이트는 Refresh Token를 사용하지 않을 수도 있다.
🎡 보안을 위해서 클라이언트는 Access Token과 Refresh Token을 다른 저장공간에 보관하는 것이 좋다.

JWT의 구조는 Header.Payload.Signature 로 이루어져 있다.

• Header에는 어떤 종류의 토큰인지와 어떻게 암호화(sign)할지가 적혀있다.
• Payload에는 정보가 담겨있다. 데이터나 권한에 대한 정보가 담길 수 있다. 이 정보는 암호화된다.
• Signature에서 원하는 비밀키(salt)를 사용하여 암호화한다.

토큰 기반 인증의 절차

클라이언트가 서버에 아이디와 비밀번호를 담아 로그인 요청을 보낸다.

아이디와 비밀번호가 일치하는지 확인한 뒤에 클라이언트에 보낼 access와 refresh 두 가지 토큰을 만든다.
🌭 이 두 토큰에 담길 정보(payload)는 같을 필요는 없다.

토큰을 클라이언트에 보내고, 클라이언트는 토큰을 저장한다.
🍻 저장위치 : 쿠키, state, local storage 등

클라이언트가 민감한 정보에 대한 요청을 보낼 때, HTTP의 req.headers.authorization 에 토큰을 담아 보낸다.

서버가 토큰을 해독하여 유효한 토큰이면 클라이언트의 요청을 처리한 뒤에 응답을 보낸다.
유효하지 않은 토큰이라면 에러가 발생한다.

토큰 기반 인증의 장점

🥛 Statelessness & Scalability (무상태성 & 확장성)

• 서버는 클라이언트의 정보를 저장하지 않아도 된다.
• 클라이언트는 새로운 요청을 보낼 때 마다 헤더에 토큰을 담아 보내면 된다.
• 만약, 여러개의 서버를 가진 서비스라면 클라이언트가 가진 하나의 토큰으로 여러개의 서버에 인증을 할 수 있기에 편리하다.

🍶 암호화한 토큰을 사용하고, 암호화 키를 노출할 필요가 없어서 안전하다.

🍯 토큰을 확인하는 서버가 토큰을 만들 필요는 없기에 어디에서나 토큰을 만들 수 있다.

• 토큰용 서버를 만들 수 있고, 다른 회사에 토큰과 관련된 작업을 맡길 수도 있다.

🍈 권한을 부여하는데 용이하다.

• 토큰의 payload안에 어떤 정보에 접근할 수 있는지 정할 수 있다.

🍥 node.js의 환경에서 jsonwebtoken 라이브러리를 사용하여 토큰을 생성할 수 있다.