인증과 인가

인증

• Authentication
• 로그인
• 놀이공원 입장

인가

• Authorization
• 사용자의 로그인 이후의 활동에 대한 서버의 허가
• 티켓을 보여주면 놀이기구를 탈 수 있음

🎫JWT(Jsno Web Token)

정보를 비밀리에 전달하거나 인증할 때 주로 사용하는 토큰으로, Json 객체를 이용한다.

JWT는 일반적으로 클라이언트와 서버 사이에서 통신할 때 권한을 위해 사용하는 토큰이다. 웹 상에서 정보를 Json 형태로 주고 받기 위해 표준규약에 따라 생성한 암호화된 토큰으로 복잡하고 읽을 수 없는 String 형태로 저장되어있다.

• 서비스에서 유저를 인증하고 식별하기 위한 Token(토큰) 기반 인증 방식
• 토큰은 세션과 달리 서버가 아닌 클라이언트에 저장된다.
• 인증에 필요한 정보들을 암호화 시킨 Json 형식의 토큰

JWT의 구성요소

JWT는 헤더(header), 페이로드(payload), 서명(signature) 세 파트로 나눠져 있으며, 아래와 같은 형태로 구성되어 있다.

- 헤더 (Header)

• 어떠한 알고리즘으로 암호화 할 것인지, 어떠한 토큰을 사용할 것인지에 대한 정보가 들어있다.

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

- 정보 (Payload)

• 전달하려는 정보(사용자 id 혹은 다른 데이터들 => 클레임이라고 부른다.)가 들어있다.
• payload에 있는 내용은 수정이 가능하여 더 많은 정보를 추가할 수 있다.
• 노출과 수정이 가능한 지점이기 때문에 인증이 필요한 최소한의 정보(아이디, 비밀번호 등과 같이 개인정보가 아닌 이 토큰을 가졌을 때 권한의 범위나 토큰의 발급일과 만료일자 등)만을 담아야 한다.

{
  "sub": "1234567890", 
  "name": "John Doe",
  "admin": true
}

- 서명 (Signature)

• 가장 중요한 부분으로 헤더와 정보를 합친 후 발급해준 서버가 저장한 secret key로 암호화 시켜 토큰을 변조하기 어렵게 만들어준다.
• 예를 들어 토큰이 발급된 후 누군가가 Payload의 정보를 수정하면 Payload에는 다른 누군가가 조작한 정보가 들어가 있지만 Signature에는 수정되기 전의 Payload 내용을 기반으로 이미 암호화 되어있는 결과가 저장되어 있기 때문에 조작 되어 있는 Payload와는 다른 결과값이 나오게 된다. 이러한 방식으로 비교하면 서버는 토큰이 조작 되었는지 아닌지를 쉽게 알 수 있고, 다른 누군가는 조작된 토큰을 악용하기가 어려워진다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

위의 헤더, 페이로드, 서명 등의 정보를 인코딩(Base64 URL-safe Encode)해 아래와 같은 형태로 클라이언트에게 발급한다.

JWT의 동작 원리

1. 사용자가 id와 password를 입력하여 로그인 요청을 한다.
2. 서버는 회원DB에 들어가있는 사용자인지 확인 한다.
3. 확인이 되면 서버는 로그인 요청 확인 후, secret key를 통해 토큰을 발급한다.
4. 이것을 클라이언트에 전달한다.
5. 서비스 요청과 권한을 확인하기 위해서 헤더에 데이터(JWT) 요청을 한다.
6. 데이터를 확인하고 JWT에서 사용자 정보를 확인한다.
7. 클라이언트 요청에 대한 응답과 요청한 데이터를 전달해준다.

이와 같이 토큰 기반 인증방식은 사용자의 인증이 완료된 이후에 토큰을 발급한다. 클라이언트쪽에서는 전달받은 토큰을 저장해두고 서버에 요청을 할 때마다 해당 토큰을 서버에 함께 전달한다. 그 이후 서버는 토큰을 검증하고 응답하는 방식으로 작동한다.

토큰의 진짜 목적은 정보 보호보다는 위조 방지이다.

JWT 장점

• 데이터의 위변조를 방지한다.
• JWT는 인증에 필요한 모든 정보를 담고 있기 때문에 인증을 위한 별도의 저장소가 없어도 된다.
• 세선(Stateful)과 다르게 서버는 무상태(Stateless)가 된다.

  무상태(Stateless)
  무상태 프로토콜은 서버가 복수의 요청 시간대에 각각의 통신 파트너에 대한 세션 정보나 상태 보관을 요구하지 않는다. 반면, 서버의 내부 상태 유지를 요구하는 프로토콜은 상태 프로토콜(stateful protocol)로 부른다. 결국은, Stateless는 서버에 세션 상태가 없는것이다.

• 확장성이 우수하다.
• 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.(쿠키와의 차이)
• OAuth의 경우 소셜 계정을 통해서 다른 웹서비스에 로그인 할 수 있다.
• 모바일에서도 잘 동작한다.(세션은 모바일 X)

  Tip
  서버에서 가장 피해야 할 것은 DB 조회이다.
  서버가 죽는 경우 중 대부분은 DB가 터져서 서버도 같이 죽는 경우이다.
  이와 관련해서 JWT는 DB조회가 필요없다는 장점을 가지고 있다.

JWT 단점

• 쿠키/세션과 다르게 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.
• Payload 자체는 암호화가 되지 않아 중요하고 민감한 정보는 담을 수 없다.
• 토큰을 탈취 당하면 대처가 매우 어렵다.