인증(Authentication)

• 사용자의 신원을 확인하는 과정
• 예시) 로그인 시 아이디와 비밀번호를 입력하거나, 생체인식(지문, 얼굴 인식)을 사용하는 것
• "누구인가?"를 확인

인가 (Authorization)

• 인증된 사용자가 어떤 리소스에 접근할 수 있는 권한이 있는지 확인하는 과정입니다.
• 즉, 사용자가 특정 작업이나 데이터에 접근할 수 있는지를 결정
• 예시) 은행 앱에서 계좌 조회는 가능하지만, 다른 사람의 계좌는 볼 수 없는 경우
• "무엇을 할 수 있는가?"를 결정

📚 JWT(Json Web Token)

인증(Authentication) 및 인가(Authorization)에 필요한 정보들을 암호화 시킨 JSON 토큰을 의미한다.

📌 JWT 구조

1) Header

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

• typ : 토큰 유형
• alg : 서명 암호화 알고리즘(HMAC-SHA256,RSA)

2) Payload

클레임(claims)을 포함한다. 클레임(claims)은 key-value 형식으로 이루어진 한 쌍의 정보

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

페이로드는 정해진 데이터 타입이 없다. 대표적으로 등록된 클레임, 공개 클레임, 비공개 클레임 이 존재한다.

Registed claims(등록된 클레임)

• iss(issuer)(발행자)
• exp(expireation time)(만료 시간)
• sub(subject)(제목)
• iat(issued At)(발행 시간)
• jti(JWI ID)

Public claims(공개 클레임)

• 사용자가 정의 가능한 클레임 공개용 정보 전달을 위해 사용

Private claims(비공개 클레임)

• 해당하는 당사자들 간에 정보를 공유하기 위해 만들어진 사용자 지정 클레임, 외부에 공개 가능하지만 해당 사용자를 특정할 수 있는 정보를 담음

3) Signature

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

• Signature 에서 사용하는 알고리즘은 헤더에 정의한 알고리즘(alg)를 활용
• Signature의 구조는 (Header + payload) 와 서버가 갖고 있는 유일한 ket(시크릿 키)값을 합친 것을 Header에서 정의한 alg 알고리즘으로 암호화 한다.

Signature = Base64Url(Header) +.+ Base64Url(Payload) + 서버의 유일한 키(Secret Key)

🤔 Header와 payload는 제 3자가 복호화 및 조작 가능성 있지만 Secret key를 모르면 복호화 및 조작이 불가능하다. - > 따라서 Signature는 토큰의 위변조 여부를 확인하는데 사용

📌 JWT 작동 방식

• Access Token : 클라이언트가 갖고있는 실제로 유저의 정보가 담긴 토큰으로, 클라이언트에서 요청이 오면 서버에서 해당 토큰에 있는 정보를 활용하여 사용자 정보에 맞게 응답을 진행
• Refresh Token : 새로운 Access Token을 발급해주기 위해 사용하는 토큰으로 짧은 수명을 가지는 Access Token에게 새로운 토큰을 발급해주기 위해 사용, Access Token 보다 긴 수명을 가지도록 하는 것이 특징

1. 사용자가 ID, PW를 입력하여 서버에 로그인 인증
2. 서버에서 클라이언트로부터 인증 요청을 받으면, Header, PayLoad, Signature를 정의
   -> Hedaer, PayLoad, Signature를 각각 Base64로 한 번 더 암호화하여 JWT를 생성하고 이를 쿠키에 담아 클라이언트에게 발급
3. 클라이언트는 서버로부터 받은 JWT를 로컬 스토리지에 저장(쿠키(Cookie)에도 가능)
   -> API를 서버에 요청할때 Authorization header에 Access Token을 담아서 요청
4. 서버가 할 일은 클라이언트가 Header에 담아서 보낸 JWT가 내 서버에서 발행한 토큰인지 일치 여부를 확인하여 일치한다면 인증을 통과시켜주고 아니라면 통과시키지 않으면 된다.
   -> 인증이 통과되었으므로 페이로드에 들어있는 유저의 정보들을 골라서 클라이언트에게 준다.
5. 클라이언트가 서버에 요청을 했는데, 만일 액세스 토큰의 시간이 만료되면 클라이언트는 리프래시 토큰을 이용
6. 리프레시 토큰이 유효하면 서버는 새로운 액세스 토큰 발급
7. 다시 클라이언트에게 액세스 토큰 전달

🤔 서버는 토큰 안에 들어있는 정보가 무엇인지 아는게 중요한 것이 아니라 해당 토큰이 유효한 토큰인지 확인하는 것이 중요하기 때문에, 클라이언트로부터 받은 JWT의 헤더, 페이로드를 서버의 key값을 이용해 시그니처를 다시 만들고 이를 비교하며 일치했을 경우 인증을 통과

🤔 JWT은 서명(인증)이 목적

• JWT는 Base64로 암호화를 하기 때문에 디버거를 사용해서 인코딩된 JWT를 1초만에 복호화 가능
• 복호화 하면 사용자의 데이터를 담은 Payload 부분이 그대로 노출 -> 그래서 페이로드에는 비밀번호와 같은 민감한 정보는 넣지 말자

⁉️ JWT 사용 이유?

• Header와 Payload로 Signature를 만드므로 데이터 위변조를 막을 수 있다.
• 서버가 별도의 저장소가 필요없다.
• 무상태(StateLess)
• OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인 가능

상태(Stateful)

• 클라이언트의 상태 정보를 서버에 저장하고 유지
• 서버측에서 클라이언트의 상태를 계속 유지해야하기 때문에 많은 메모리 소모

무상태(Stateless)

• 서버가 클라이언트의 상태를 보존하지 않음
• 서버는 단순히 요청이 오면 응답을 보내는 역할만 수행
• 서버는 단순히 받아서 응답만 해주기 때문에 상태 유지에 대한 부하 감소

📌 Jwt의 인증 방식(쿠키(Cookie) vs 헤더(Header))

JWT는 클라이언트와 서버 간에 인증 정보를 전달하는 수단으로, 쿠키 방식과 HTTP 헤더 방식(주로 Authorization 헤더의 Bearer 스키마 사용) 두 가지 방법으로 사용 가능하다.

1) 쿠키(Cookie)

• 서버가 JWT 토큰을 쿠키에 저장하여 클라이언트에 전송하고, 클라이언트는 자동으로 쿠키를 포함하여 요청한다.
• HttpOnly, Secure, SameSite 등의 옵션을 사용하면 자바스크립트 접근을 차단하고 보안을 강화 가능
• 브라우저가 자동으로 쿠키를 포함해 전송하므로, CSRF(사이트 간 요청 위조) 공격에 취약

Cookie cookie = new Cookie("accessToken", jwt);
cookie.setHttpOnly(true); // 자바스크립트 접근 불가
ookie.setSecure(true);   // HTTPS 환경에서만 전송 (개발 환경에서는 false로 설정 가능)
cookie.setPath("/");
cookie.setMaxAge(3600);   // 1시간 (초 단위)
response.addCookie(cookie);

2) 헤더(Header)

• 클라이언트가 직접 토큰을 관리하여 필요한 요청에만 명시적으로 첨부할 수 있으므로, CSRF 공격 위험 감소
• 토큰을 로컬 스토리지나 메모리에 저장하는 경우, XSS(사이트 간 스크립팅) 공격에 노출될 위험 가능

📌 JWT BlackList(블랙리스트)

사실 오늘 jwt를 정리한 이유가 이것 때문이다.AccessToken은 유효기간이 짧아 괜찮다고 해도 만약 refreshToken이 로그아웃 이전 시점에 탈취를 당하면, 악의적인 사용자가 서버에게 탈취한 refreshToken을 보낼 수 있다는 것을 알게 되었다. 그래서 생각한 것이 블랙리스트기법이다.

• 사용자가 로그아웃을 요청 하면, 클라이언트는 쿠키나 localstorage 에서 jwt를 제거하면 되지만 서버는 jwt를 무력화 할 방법이 없다. 따라서 서버에서 Jwt에 대한 블랙리스트를 만들어 Jwt의 유효 기간이 만료 될 때까지 DB에서 관리하는 것을 블랙리스트 기법이라고 한다.
• 만약 로그인 시에 블랙리스트에 있는 Jwt 토큰이 들어오면 거부를 하면 된다.

🤔 그러면 Jwt를 DB에 저장하면 Stateful해지는게 아닐까?

내가 이 기법을 찾아보면서 생겼던 의문점이다. 그래서 가끔 사용하는 개발자 커뮤니티에 내 의문점을 질문하였다. JWT에서 블랙리스트를 사용하는 이유가 잘 이해되지 않습니다. jwt는 Stateless 장점이있는데 왜 Redis 같은 저장소를 써서 상태를 관리하나요?

결론

결국은 관점의 차이였다. 실제로 블랙리스트 기업은 실무에서도 많이 쓰고 Redis를 사용하면 속도도 빠르기 때문에 괜찮을 것 같고 모든지 기술이 완벽할 수는 없고 그 방법을 어떻게 잘 해결하고 잘 설계하는것이 개발자의 몫인것 같다.

참고 :

• Decode JWT Token and Verify in Plain Java

• JWT 토큰 인증 이란? (쿠키 vs 세션 vs 토큰)