JWT 인증,인가의 장점 / 한계점

nana·2024년 9월 13일

개발 지식

목록 보기

1/7

개요

게시판 API를 구현하면서 JWT인증을 사용하게되었는데 앞으로도 자주 쓰일 것이라 생각되어 JWT가 무엇이고 JWT로 인증 인가를 했을 때 장점과 한계점에 대해 정리하고자 한다.

인증 & 인가

인증과 인가는 둘 다 보안과 관련되어있고, JWT토ㅡㄴ 기반인 경우 해당 토큰을 사용한다는 점에서는 동일하나 인증은 장치 혹은 사용자를 식별하는 행위 인가는 장치 및 사용자 엑세스 권한을 허용/거부하는 행위이다.

🔑 인증

어떤 사실 또는 어떤 문서가 진짜인지 증명하는 과정을 가리키는 용어.
사용자는 사용자와 시스템간에 공유되는 합의된 정보를 제공하여 자신의 신원을 증명함.
ex) 회원가입하고 로그인 하는 것.

🔐 인가

유저가 요청하는 request를 실행할 수 있는 권한이 있는 유저인가를 확인하는 절차.
즉, 액세스 권한을 확인하는 프로세스를 의미.
ex) 유저에 대한 권한을 허락하는 것.

JWT를 쓰면 인가가 수월함. 서버가 유저 정보를 갖고 있으므로 데이터에서 유저의 권한 정보도 읽어들이면 됨.
'access token'을 통해 해당 유저 정보를 얻을 수 있으므로 해당 유저가 가지고 있는 권한(permission)도 확인 가능.

Authorization 절차

Authentication 절차를 통해 access token을 생성한다. access token에는 유저 정보를 확인할 수 있는 정보가 들어가 있어야 한다 (예를 들어 user id).
유저가 request를 보낼때 access token을 첨부해서 보낸다.
서버에서는 유저가 보낸 access token을 복호화 한다.
복호화된 데이터를 통해 user id를 얻는다.
user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인하다.
유저가 충분한 권한을 가지고 있으면 해당 요청을 처리한다.
유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보낸다.

인증→인가로 이어질 수 있지만 인가→인증으로는 이어질 수 없다.

JWT(Json Web Token)

서비스에서 유저를 인증하고 식별하기 위한 Token기반 방식.
토큰은 세션과 달리 서버가 아닌 클라이언트에 저장된다.
인증에 필요한 정보들을 암호화 시킨 Json형식의 토큰
JWT는 HMAC 알고리즘을 사용하여 비밀키 또는 RSA를 이용한 Public Key/Private Key 쌍으로 서명할 수 있다.

// 참고
JWS(Json Web Signature) : JSON으로 전자 서명을 하여 URL-safe문자열로 표현한 것.
JWE(Json WEb Encryption) : JSON을 암호화하여 URL-safe 문자열로 표현한 것.
URL-safe : URL에 포함할 수 없는 문자를 포함하지 않는 것.

도 있다.

JWT의 구조

토큰 타입과 해시 암호화 알고리즘으로 구성되어있다.

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

Payload

토큰에 담을 클레임(claim)정보를 포함하고 있다.
name-value의 한 쌍으로 이루어 져 있고, 토큰에는 여러개의 클레임들을 넣을 수 있다.

{
  "type": "test", 
  "name": "nana_velog",
  "date": "2024-09-13"
}

Signature

secret key를 포함하여 암호화 되어있다.

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

Process

기존의 토큰 방식 인증은 이후의 모든 서비스 호출에 사용되어 서비스를 받기 위해서 토큰의 유효성을 확인하고 세부 정보를 쿼리해야한다.
참조에 의한 호출(Call by Reference) 형태로 모든 서비스는 항상 상호작용할 때 다시 접속해야한다.

JWT 장점

별도의 인증 저장소가 필요없다 : 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에.
쉬운 인증 및 인가 방법 제공 : 중앙 집중식 인증 서버와 데이터베이스에 의존x
데이터의 위변조를 방지한다.
확장성이 우수 : Payload에 정보만 담으면 되기때문에
모바일에서도 잘 동작한다. cf) 세션은 모바일 x
💡
서버에서 가장 피해야 할 것은 DB조회이다.
JWT는 DB조회가 필요없다는 점에서 큰 장점을 가지고 있다.

JWT 단점

정보 변경 시 실시간으로 적용 불가 : 토큰은 클라이언트에 저장되기때문에 데이터베이스에서 사용자 정보를 조작하더라도 토큰에 직접 적용할 수 없다.
더 많은 필드가 추가되면 토큰이 커질 수 있다.
데이터 트래픽 크기에 영향을 미칠 수 있음 : 비상태 애플리케이션에서 토큰은 거의 모든 요청에 대해 전송되기때문.
중요한 정보는 담을 수 없음 : Payload자체가 암호화가 되지 않기 때문에.

JWT 사용되는 곳

1. 회원인증

서버에서는 사용자에 대한 세션을 유지할 필요가 없다.
사용자가 요청을 했을 때 토큰만 확인하면 되므로 세션 관리가 필요 없어서 서버 자원과 비용을 절감할 수 있다.

2. 정보 교류

JWT는 두 개체 사이에서 안정성 있게 정보를 교환하기에 좋은 방법이다.
정보가 서명되어있기 때문에 정보를 보낸이가 바뀌진 않았는지, 정보가 도중에 조작되지는 않았는지 검증할 수 있다.

JWT 인코딩, 디코딩

jwt.io 여기서 인코딩과 디코딩을 바로 확인 가능합니다.

덧붙이기.

▪️ 우연히 본 세션에 관한 글.
"어디에 세션을 보관할까?"

참고

참고1
참고2

nana

BackEnd Developer, 기록의 힘을 믿습니다.

다음 포스트