[Web] JWT를 통한 인증 과정 알아보기

🌱 들어가기 전

마찬가지로 테코톡에서 진행했던 발표 자료를 바탕으로 글을 작성하였습니다!

인증과 인가, 쿠키 / 세션 방식에 대해서는 이전 포스팅에서 작성하였습니다.

[Web] 인증과 인가란? - 쿠키와 세션에 대해서 알아보자!

 

---

 

4. 효율적으로 인증하기

지난 포스팅에서는 세션을 통해서 안전하게 인증하는 방법을 알아보았다.

하지만, 세션 방식의 가장 큰 문제점은 서버도, 클라이언트도, 그리고 세션 스토리지까지 사용자의 정보를 관리하는 주체가 너무 다양하다는 것이다. 이러한 문제점을 해결하기 위해서, 상태를 관리하는 것을 따로 두지 않고 요청과 응답 내부에서 처리하는 것이 토큰 인증 방식이다.

 

+) 세션 기반 인증 방식에서 토큰 인증 방식이 나온 이유 중에 하나가 DB에 인증 정보를 저장하지 않아서 서버에 대한 부하를 줄이는 것도 있다고 많이들 말한다. 암호화된 인증 정보를 클라이언트가 관리함으로서 부하를 줄인다고는 하지만... 사실 보안 측면으로 보면 JWT 역시 DB를 사용하게 되다 보니까 이런 관점에서는 크게 좋은지 잘 모르겠다. (개인적인 의견)

 

토큰 방식으로는 대표적으로  'JWT (Json Web Token)'가 존재한다.

JWT는 정보를 Json 객체를 통해 안전하게 전송하기 위한 간결하고, 독립적인 방법을 정의하는 개방형 표준이다. (RFC 7519)

기본적으로 HMAC 알고리즘을 통해 암호화가 되어 있으며, RSA나 ECDSA를 사용하는 공개-개인키 쌍을 통해 서명할 수 있다.

 

JWT는 크게 헤더, 페이로드, 그리고 시그니처로 이루어져 있다.

 

 

💬 Header

헤더는 일반적으로 토큰 유형과 서명 알고리즘 2가지가 포함되어 있다.

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

만약 이런 식으로 구성되어 있다면, 이는 현재 타입은 JWT, 서명 알고리즘으로 HS256을 사용했음을 나타낸다.

이 정보를 Base64로 인코딩하게 되면 JWT의 헤더 부분이 완성된다.

 

 

💬 Payload

payload은 claim 정보가 포함되며, claim은 entity에 대한 내용이 들어간다. (사용자에 대한 정보)

인증에 필요한 정보가 보통 이곳에 들어가지만, 민감한 정보는 넣지 않는 것이 좋다.

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

마찬가지로 위에 대한 정보를 base64로 인코딩하면 payload에 대한 정보가 들어간다.

 

 

💬 Signature

인코딩된 헤더 및 인코딩된 페이로드, secret (비밀 키 정보), 헤더에 지정된 알고리즘을 사용하여 서명할 수 있다.

만약 HMAC SHA256 알고리즘을 사용한다면 아래와 같이 서명이 가능하다.

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

시그니처 정보는 도중에 변경되지 않았는지 확인하는데 사용되며, 개인키로 서명된 토큰이라면 JWT의 발신자가 본인이 맞는지 확인하는데도 사용된다.

 

그래서 결과적으로 JWT는 .으로 구분된 3개의 Base64로 인코딩된 문자열의 합으로 이루어져 있다.

보통 우리가 코드에서 활용할 때에는 'Bearer' 라는 prefix를 사용하여 Authorization 헤더에 넣는 것이 일반적이다.

Authorization: Bearer <token>

참고로, 나중에 실제 클라이언트와 통신할 때 CORS 문제를 겪을 수 있기 때문에 서버측에서 exposedHeader 값으로 Authroization 헤더를 허용해줘야 한다. (이거는 다음에 포스팅을 따로 해보겠다 ㅎㅎ)

 

실제로 학습 테스트에서 살펴보았던 토큰 생성 코드를 확인해보자.

public String createToken(String payload) {
    Claims claims = Jwts.claims().setSubject(payload);
    Date now = new Date();
    Date validity = new Date(now.getTime() + validityInMilliseconds);

    return Jwts.builder()
            .setClaims(claims)
            .setIssuedAt(now)
            .setExpiration(validity)
            .signWith(SignatureAlgorithm.HS256, secretKey)
            .compact();
}

코드를 각각 분석해보면 위와 같이 claim을 통한 사용자 정보 지정 및 만료 시간, 그리고 시크릿키를 통한 암호화를 하는 것을 볼 수 있다.

 

그리고, 해당 토큰을 다시 해독할 때는 서버 내에서 관리하는 시크릿키를 통해서 해독한다.

public String getPayload(String token) {
    return Jwts.parser()
        .setSigningKey(secretKey)
        .parseClaimsJws(token)
        .getBody()
        .getSubject();
}

💡 여기서 한 가지 주목할 점이 있다.
parseClaimsJws()라는 메서드를 사용하고 있는 걸 볼 수 있는데, 이거 대신에 parseClaimsJwt()를 사용하면 오류가 발생한다.
이는, 우리가 처음에 토큰을 생성할 때 signWith을 통해서 서명을 진행했기 때문에 복호화 시에도 서명에 대한 검증을 진행해야 하기 때문이다. (Jwt()의 경우 서명 검증 없이 단순히 헤더와 클레임만 추출함)
parseClaimsJwt()을 사용하고 싶다면 토큰 생성 시에 signWith을 통해서 서명에 대한 정보를 넘겨주지 않으면 된다.

 

 

💬 동작 방식 알아보기

토큰 기반 인증 방식은 아래와 같이 동작할 수 있다.

클라이언트에게 생성된 토큰을 내려주는 방식은 다양한데, 나는 위와 같이 Authorization 헤더에 담아서 내려줬다.

클라이언트는 해당 값을 받아서 다음 요청 시 Authorization 헤더에 JWT 정보를 함께 넣어서 보내는데, 서버는 해당 키를 생성할 때 사용하였던 시크릿키 정보를 활용하여 다시 디코딩 후에 내부에 있는 사용자 정보를 바탕으로 인증을 진행한다.

 

 

💬 장점 / 단점

토큰 기반 인증 방식의 경우 서버 측에서 따로 저장할 필요가 없으며, 클라이언트가 요청에 대해 헤더 값에 함께 포함시켜 보내주면 된다.

또한, MSA 같은 구조나 서버가 여러 대인 상황이라면 같은 토큰을 통해 여러 서버에서 인증이 가능하기 때문에 더 효율적이다.

(이전에 봤던 세션 인증 방식에서는 세션 스토리지 같은 것을 두었었는데, 이런 점에서는 좋다 ㅎㅎ)

 

하지만, JWT의 경우 탈취 당한다면 해당 사용자의 권한을 그대로 가지게 된다.

탈취당한 JWT의 경우 유효 기간이 지나기 전까지는 강제로 만료시킬 수 없기 때문에, 정보를 바로 제거할 수 있는 세션에 비해서는 보안적 측면에서는 떨어진다고 볼 수 있다. (물론, 해당 토큰의 claim 정보가 악성 사용자임을 확실하게 나타낼 수 있다면, 해당 사용자의 요청은 차단하는 형태로는 만들 수 있을 것 같다.) 그래서 은행 같은 보안이 중요한 시스템에서는 세션을 많이 사용하는 것으로 알고 있다. (뇌피셜)

 

 

💬 Refresh Token

보통 탈취 문제로 인해서 JWT (이제는 'access token'이라고 부르겠다.)의 유효 기간을 짧게 가져가는 편이며 (30분 정도), 기한이 짧으면 요청에 대해서 새롭게 발급받아야 하는 횟수가 늘어나기 때문에 이를 방지하기 위해 'refresh token'이라는 것을 따로 두기도 한다.

access token에 대한 재발급 기능을 책임지는 token이며,  기본적으로 서버에 저장할 수 있고 (세션에 저장하거나 쿠키에 저장하는 방법도 있지만, in-memory db에 저장하는 것이 일반적), 탈취를 당하더라도 해당 사용자의 refresh token을 강제로 제거하여 보안에 대해서도 안정성이 높은 토큰이다.

 

보통 refresh token의 경우 유효 기간을 일주일~이주일 정도로 만들어둔다.

사실 이에 대해 어떻게 활용하는지는 개발자에 따라서 다르지만, 보통 이런 방식을 많이 사용한다. 위에서 작성한 그림과 이어진다고 생각하자.

 

여기서 받은 토큰 정보에 따라서 요청을 처리하는 스텝이 나누어지는데, 보통 아래와 같은 케이스들로 나뉜다.

 

 

물론 여기서 다른 방식으로 처리해도 무방하다.

로직이 상당히 복잡해졌지만, access token의 단점을 그나마 보완할 수 있기 때문에 많이 사용하는 방법이다.

 

짧은 access token의 유효시간에 대처하기 위한 다른 방법으로 sliding session이라는 친구도 있다.

사용자가 계속해서 서비스를 이용하고 있다면 (JS의 이벤트 핸들러로 감지) access token이 만료되기 전에 새로운 access token을 발급받아 자동으로 갱신한 토큰을 받아오는 것이다. 이건 구현해본 적이 없어서 잘 모르겠지만... 아무래도 클라이언트 측에서 계속 확인해야 할 것 같다.