JWT 인증과 세션인증

인증 you are who you say you are

사용자 인증이란 서버로부터 더 많은 정보에 접근하고자 할 때, 사용자가 본인을 인증하는 과정을 얘기합니다. 보통은 현재 자원에 접근하고자 하는 클라이언트(=사용자)가 '누구'인지 '증명'하는 과정으로 진행됩니다.

1. Someting you know
   : 가장 많이 사용하는 인증 방식입니다. ID와 비밀번호 혹은 PIN 을 입력하는 방식입니다. 비밀번호는 다른 사람은 모르고 사용자만 알고 있는 정보입니다.
2. Something you have
   : 토큰이나 ID 카드같은 사용자가 지니고 있는 정보로 인증하는 방식입니다. 토큰을 발급은 크게 두 가지 기준으로 분리됩니다. HOTP(HMAC-based One-Time Password) 토큰은 발급 이후 사용자가 사용하지 않을 때까지 토큰이 갱신되지 않고, TOTP(Time-based One-Time Password) 토큰은 매 30초마다 갱신됩니다. 사용자가 30초(및 정해진 시간) 내에 사용하지 않으면 자동으로 갱신됩니다.
3. Something you are
   : 지문 인증 및 얼굴 인증과 같은 방식입니다. unique 한 정보 기반 인증으로 개인 식별이 원활하지만, 추가적인 장치나 하드웨어가 욕됩니다.
4. Somewhere you are
   : 위치 기반으로 정보에 접근이 가능합니다. 예를 들면, 출근시 회사 근처 50m내에서만 출근이 인정되는 예를 들 수 있습니다.
5. Something you do
   : 제일 드문 방식 중 하나입니다. 사용자 개별 습관 등을 기반으로 인증합니다. (예. 목소리 패턴 혹은 서명, 필체 등)

서버에서 인증이 성공적으로 끝난 후에, 사용자가 자원 접근시에 이 사용자가 인증이 된 사용자인지 구분하는 방법은 크게 세션과 토큰 방식으로 나눌 수 있다.

---

세션과 쿠키

세션 인증 과정

1. 클라이언트가 서버에 로그인한다.
2. 서버는 DB에서 id와 password 정보가 유효한지 확인한다.
3. 서버는 인증 성공시 session정보를 session DB에 저장한 후, 클라이언트에게 세션 정보를 보내준다. 보통 쿠키로 전달하며 http-only(해당하는 쿠키는 브라우저에 의해서만 볼 수 있습니다. 즉, 클라이언트에서 자바스크립트나 프로그램 내에서 볼 수 없다.)옵션과 함께 준다.
4. Cookie 정보는 클라이언트가 request 시, 브라우저에서 자동으로 포함해 준다. 따라서, 요청시 서버는 클라이언트의 쿠키 정보를 session DB와 비교하여 요청이 가능한지 분별한다.

장점

1. session DB에 유효한 정보만을 보관할 수 있으므로 신뢰 가능합니다.
2. 쿠키를 사용하기 때문에, 클라이언트에서 별도의 추가 로직 없이 브라우저가 자동으로 넣어주는 쿠키로 심플하게 인증 가능합니다. 더불어서, http only 옵션일 경우 안전하여 보안성을 높입니다.
3. 쿠키에는 세션 ID정보를 보내므로 사용자의 다른 개인 정보를 주고받지 않아서 안전합니다.

단점

1. stateful: 서버에서 시사각각 변하는 세션 정보를 보관합니다. 만약, 여러개의 서버에서 동작하거나 MSA 서비스에서 사용할 때, 이 세션 정보를 얻으려면 Session DB 정보와 비교해아하며, 이를 위해서는 무조건 네트워크 요청을 해야합니다. 때문에, 분산형 서비스로 디자인이 잘 되었지만, session 정보 비교와 같이 네트워크 요청이 많이 늘어나게 되어 성능이 좋지 않을 수 있습니다.
   

---

JWT

JWT란?

1. Json Web Token의 약자로, JSON을 이용해서 web token을 주고받는 것을 말합니다.
2. JSON Web Token Structure: Header, Payload, Signature 세가지 부분으로 나뉩니다.
   • Header: 토큰의 종류에 대한 메타데이터, 알고리즘 정보를 지니고 있습니다.
   • Payload(set of claims): 사용자 ID 및 허용된 권한과 같은 보안 관련 정보를 지니고 있습니다.
   • Signature: 토큰 검증시 사용됩니다. '인코딩된 header, payload의 정보 + 서버의 비밀키'를 header의 명시된 알고리즘으로 해싱한 정보입니다.
3. 만약, payload를 변경하여 서버의 요청을 하여을 때, signatrue를 통해서 변경된지 안된지 검증이 가능합니다. (secret 정보를 포함해서 인코딩하기 때문에 정보의 유효성을 확인 할 수 있습니다.)
4. 모든 api 요청에 대해서 발급받은 token을 header에 포함해서 보내게 되면, jwt가 유효한지 유효하지 않은지 만료되었는지 등을 확인 할 수 있다.

장점

1. 서버의 state가 없습니다. 한번 json 으로 만들어서 클라이언트에 보내주고 검증만 하면 되기 때문에 상태를 필요로 하지 않습니다. -> 분산된 서버 환경에서 동일한 secret키만 가지고 있으면 되므로, 분산환경에서 사용하기 좋다.

단점

1. jwt 자체가 단점이 될 수 있습니다. 서버와 클라이언트 간에 jwt 정보를 그대로 가져와서 약용할 수 있기 때문에, 보안에 유의해야 합니다.
   

---

bcrypt

bcrypt란?

1. 패스워드를 해싱하는 알고리즘을 말합니다.
2. 만약, 입력한 아이디와 패스워드를 서버에 그대로 저장하고 있을 경우에 해커가 데이터베이스 정보를 그대로 훔쳐갈 수 있고, 악용할 수 있습니다. 따라서, bcrypt 를 이용해서 암호화 알고리즘을 이용하여 해싱하고, 암호화된 패스워드를 데이터베이스에 저장해야 합니다.
3. bcrypt 구조: Alg(알고리즘 식별자) + Cost(얼마나 많은 복잡도) + Salt(암호화 복잡하게 만드는 salt) + 암호화된 비밀번호
4. 암호화를 하는데만 이용이 가능하다. 만들어진 해시를 가지고 다시 비밀번호로 변환할 수 없다. 암호화된 결과물을 이용해서 다시 패스워드로 변환할 수 없다.
5. 해커들은 문자열에 대한 해싱 값을 지니는 해싱 테이블을 가지고 있을 수 있습니다. 따라서, salt를 사용하게 되면, 해커가 가져야할 테이블 길이가 기하 급수적으로 늘어나게 됩니다. 다만, salt 길이가 늘어날 수록 비밀번호를 bcrypt하는데 시간이 많이 걸리기 때문에 적정한 글자수를 정해야 합니다.

bcryp 참고자료

1. Salt 길이별로 성능 측정
2. 노드 bcyrpt lib