| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 기술블로그
- CI/CD
- Express
- nodeJS
- 포워드 프록시
- node-cron
- typescript
- 코딩컨벤션
- gtiactions
- 에러핸들링
- 자동배포
- amazon web services
- JWT
- cronjob
- 프론테
- 리버스 프록시
- 웹개발
- server
- jsonwebtoken
- 성능
- 데이터베이스
- 토큰인증
- 개발지식
- 권한인증
- 풀스택
- 유저기능
- pm2
- 백엔드
- AWS
- nextjs
- Today
- Total
생각해 보자 님의 블로그
JWT? 토큰 인증을 활용해 보자 본문
1.토큰 인증 방식이란?
웹 애플리케이션에서 사용자의 인증을 처리하는 방법에는 세션 기반 인증과 토큰 기반 인증이 있습니다. 이 두 방식은 인증 처리 방식에 있어 근본적으로 차이가 있습니다. 세션 기반 인증은 서버가 클라이언트의 상태를 저장하고, 이를 기반으로 인증을 처리하는 방식입니다. 반면, 토큰 기반 인증은 클라이언트가 인증 정보를 저장한 JWT와 같은 토큰을 서버에 전달하고, 서버는 이를 통해 인증을 처리합니다.
간단히 말하면, 세션은 서버에서 인증 정보를 관리하는 방식이고, 토큰은 클라이언트가 인증 정보를 가지고 다니며 인증을 처리하는 방식입니다. 이번 글에서는 JWT를 사용한 토큰 인증 방식에 대해 깊이 살펴보겠습니다. 특히 JWT가 어떻게 동작하고, 이를 실제 프로젝트에 어떻게 활용할 수 있는지에 대해 알아보겠습니다.
2. 배경
이전 글에서 세션 방식과 토큰 방식의 차이를 다뤘습니다. 세션 방식은 서버가 클라이언트의 상태를 기억하면서 인증을 처리하는 방식인 반면, 토큰 방식은 클라이언트가 직접 인증 정보를 저장하고, 이를 통해 인증을 처리하는 방식입니다.
이번 글에서는 JWT라는 토큰을 활용하는 방법에 대해 설명할 것입니다. JWT는 단순한 인증 토큰이 아니라, 서버에서 클라이언트의 상태를 관리할 필요 없이 인증을 처리할 수 있는 방법입니다. 이러한 특징은 특히 마이크로서비스 아키텍처나 분산 시스템에서 매우 유용하게 활용됩니다. 그럼 이제 JWT가 무엇인지, 그리고 어떻게 활용할 수 있는지 알아보겠습니다.
3. JWT 토큰이란?
**JWT (JSON Web Token)**는 인증을 처리하기 위한 표준 방식입니다. JWT는 헤더, 페이로드(payload), 서명의 세 가지 주요 부분으로 구성됩니다.
- 헤더(Header): 이 부분은 토큰의 타입과 서명 방식에 대한 정보를 담고 있습니다. 예를 들어, {"alg": "HS256", "typ": "JWT"}와 같이 서명 알고리즘을 정의합니다.
- 페이로드(Payload): 인증에 필요한 데이터를 담는 부분입니다. 이 데이터에는 사용자 ID, 역할, 만료 시간 등 필요한 정보를 담을 수 있습니다. 중요한 점은 이 데이터가 인코딩되어 저장되며, 암호화되지 않는다는 점입니다.
- 서명(Signature): 서명은 JWT의 무결성을 보장하기 위한 부분입니다. 서버는 시크릿 키를 사용하여 헤더와 페이로드를 결합하고 서명을 생성합니다. 이 서명은 서버가 JWT를 검증할 때 사용됩니다.
JWT는 클라이언트가 토큰을 보유하고 있기 때문에 서버에서 상태를 관리하지 않고도 인증을 처리할 수 있습니다. 이를 통해 확장성과 효율성을 제공하며, 서버 간의 상태 공유나 관리 없이도 인증을 유연하게 처리할 수 있게 됩니다.
4. JWT 활용하기
JWT 토큰의 장점
- 서버 상태 관리 불필요: 서버는 클라이언트의 상태를 관리할 필요가 없습니다. 클라이언트는 JWT를 통해 필요한 인증 정보를 가지고 다니며, 서버는 이를 통해 인증을 처리합니다. 이로 인해 서버 간의 분산 환경에서 효율적으로 인증을 관리할 수 있습니다.
- 클라이언트의 독립성: JWT는 자체적으로 인증 정보를 담고 있기 때문에, 클라이언트가 서버와 독립적으로 인증을 처리할 수 있습니다. 서버와 클라이언트 간의 의존성이 적어지며, 효율적인 인증 방식이 됩니다.
- 다양한 데이터 저장 가능: JWT의 페이로드에 사용자의 정보나 권한 정보를 자유롭게 담을 수 있습니다. 인증뿐만 아니라 추가적인 데이터를 한 번에 처리할 수 있어 유용합니다.
- 보안: JWT는 서명을 통해 변조를 방지할 수 있으며, 토큰에 만료 시간을 설정하여 자동으로 만료되게 할 수 있습니다. 이를 통해 보안을 강화할 수 있습니다.
JWT 토큰의 단점
- 토큰 크기: JWT는 데이터를 페이로드에 담기 때문에, 데이터 양이 많을 경우 토큰 크기가 커질 수 있습니다. 이는 네트워크 성능에 영향을 미칠 수 있기 때문에, 필요한 데이터만 담는 것이 중요합니다.
- 만료된 토큰 처리: JWT는 클라이언트 측에 저장되기 때문에, 만약 토큰이 만료되었을 경우 클라이언트에서 이를 갱신하는 방식에 대한 처리가 필요합니다. 일반적으로 리프레시 토큰을 사용하여 만료된 JWT를 갱신하는 방식이 사용됩니다.
- 브라우저 보안: JWT는 클라이언트 측에 저장되므로 보안에 취약할 수 있습니다. 특히, XSS(교차 사이트 스크립팅) 공격에 의한 노출을 방지하기 위해 JWT를 안전하게 저장하는 방법이 필요합니다.
JWT 페이로드에 담을 수 있는 데이터
JWT의 페이로드에는 인증에 필요한 다양한 정보를 담을 수 있습니다. 예를 들어, 사용자 ID, 역할, 토큰의 만료 시간 등 다양한 정보를 포함할 수 있습니다. 중요한 점은 페이로드가 암호화되지 않기 때문에 중요한 정보를 담을 때에는 주의가 필요합니다.
- userId: 사용자의 고유 ID
- role: 사용자의 역할 (예: admin, user)
- exp: 토큰의 만료 시간 (예: 1시간 후 만료)
- iat: 토큰의 발급 시간
이러한 정보들은 JWT를 통해 서버로 전달되며, 서버는 이를 이용해 인증과 권한을 처리합니다.
프로젝트에서 JWT 활용 예시
실제 프로젝트에서 JWT를 어떻게 활용했는지에 대해 설명하겠습니다. 제가 진행한 프로젝트에서는 User, Customer, Mover라는 테이블을 기반으로 JWT 인증을 구현했습니다.
- 테이블 구조:
- User 테이블에는 사용자 정보가 저장됩니다.
- Customer와 Mover 테이블은 각각 User와 1:1 관계를 가지며, 추가적인 사용자 정보를 포함합니다.
- JWT 생성:
- 사용자가 로그인하면, 서버는 userId를 포함한 JWT를 생성하여 클라이언트에 반환합니다. 이 토큰은 시크릿 키로 서명되어 변조를 방지합니다.
- JWT 검증:
- 클라이언트는 API 요청 시마다 Authorization 헤더에 JWT를 담아 보냅니다. 서버는 이 JWT를 검증하여 유효한지 확인하고, 토큰에 포함된 userId를 바탕으로 요청을 처리합니다. 이 정보를 req.user에 담아 미들웨어에서 활용합니다.
이 방식은 서버가 클라이언트의 상태를 관리할 필요 없이 JWT만으로 인증을 처리할 수 있기 때문에, 효율적이고 확장성이 뛰어난 인증 방식을 제공합니다. 또한, 토큰에 사용자 정보와 권한이 포함되어 있기 때문에 매번 데이터베이스를 조회할 필요 없이 인증을 처리할 수 있습니다.
결론
JWT는 분산 시스템에서 인증을 처리할 때 매우 유용한 방식입니다. 서버는 클라이언트의 상태를 관리할 필요 없이, 클라이언트가 보유한 JWT를 통해 인증을 처리할 수 있습니다. 이 방식은 특히 확장성과 효율성이 중요한 환경에서 큰 장점을 가집니다. 물론 보안에 대한 세심한 고려가 필요하고, 토큰 관리에 대한 추가적인 처리가 요구되지만, 적절하게 활용하면 매우 강력한 인증 시스템을 구축할 수 있습니다.
이번 글을 통해 JWT가 무엇인지, 그리고 실제 프로젝트에서 어떻게 활용할 수 있는지에 대해 이해했기를 바랍니다. 여러분도 JWT를 사용해 간편하고 효율적인 인증 시스템을 구현할 수 있을 것입니다.
'테크 지식' 카테고리의 다른 글
| 많이 사용하는 AWS, 왜 사용하는 것일까? (0) | 2024.12.27 |
|---|---|
| node-cron: 왜 외부 스케줄러 대신 노드에서 직접 관리하는 것이 더 나을까? (1) | 2024.12.26 |
| 권한 인증?(Authorization)? Token과 Session을 알아 보자 (1) | 2024.12.20 |
| 프록시( Proxy )? 여기선 무슨 일이 일어 날까? (1) | 2024.12.19 |
| CI/CD가 뭘 까? 자동 배포의 대하여 알아보자 (feat . Git Actions & PM2 ) (0) | 2024.12.18 |