0. 왜 알아보게 되었는가?
프로젝트를 본격 시작하기에 앞서 로그인 및 인증인가 기능 구현을 위해 필요한 기초 지식을 쌓기 위해
1. 인증
1. 인증이란?
로그인 절차에서 정확한 ID와 PW조합을 입력했는 지 확인하는 과정
2. 사용 목적
서비스 사용자의 파악과 추적을 위해!
3. 무엇이 필요한가
ID, PW, 이메일 등 일반적으로 로그인 시 필요한 정보
4. 암호화 방법의 종류
1. 단방향 해시
- 일반적인 해시는 정보 저장의 용이성 때문에 자료구조의 성격으로 사용되는데 반해,
단방향 해시는 복원이 불가하며, 암호학적 용도로 사용된다. - 종류: MD5, SHA-1, SHA-256 등
- 한계: 평문이 같으면 결과 암호도 항상 같다. (같은 평문에 대해 항상 같은 암호로 암호화되다보니, 해킹에 쉽게 노출됨)
2. SALTING & Key Stretching
- why?: 단순 해싱값이 해킹에 쉽게 노출된다는 한계를 가져 이를 극복하기 위해 탄생!
- SALTING: 입력한 비밀번호와 임의 생성 문자열(Salt)을 합쳐서 해싱 후, Salt값과 해싱 값을 함께 저장
(함께 저장하는 이유는 비교를 위해서) - Key Stretching: SALTING, 해싱을 여러 번 반복해서 원본 (평문)을 유추하기 어렵게 만드는 것
(해커가 무작위 대입으로 해시값을 계산하는 데 필요한 시간을 높여서 보안이 좋아짐)
2. 인가
1. 인가란?
사용자가 서버에 요청을 보내면 인증과정을 거쳐 확인된 사용자가 맞는지 확인하는 과정
3. JWT
1. JWT란?
JSON Web Token.
유저를 인증 및 식별하기 위한 토큰 기반의 인증 인가 기법
2. 특징
- 토큰 자체에 사용자의 권한정보, 서비스를 사용하기 위한 정보가 포함되어 있음 (self-contained)
- 데이터가 많이 포함될수록, 토큰의 크기도 커짐
- 토큰 발급 이후, 사용자 정보를 바꿔도 재발급 전까지 반영되지 않음.
- RESTful과 같은 무상태(stateless) 환경에서 사용자 데이터를 주고받을 수 있게 됨
3. 기존 세션방식과의 차이점
세션과 달리,
- 서버가 아닌 클라이언트에 저장되어서 서버의 부담이 줄어든다.
- 기존 세션 방식: 서버 내 메모리, 스토리지에 세션을 관리했음. - 클라이언트에 저장되고, HTTP 요청 시 헤더에 토큰을 첨부하여 데이터를 요청하고, 응답을 받아올 수 있다.
- 기존 세션 방식: 쿠키 등을 통해 식별한 후, 서버에 세션을 저장.
4. JWT방식으로 인가하는 과정
① 클라이언트 사용자가 ID/PW로 인증
② 서버에서 서명된(signed) JWT를 생성하여 클라이언트에 응답으로 돌려줌
③ 클라이언트가 서버에 데이터 추가 요구 시, HTTP Header에 JWT첨부.
④ 서버가 클라이언트로부터 온 JWT를 검증 (== 인가)
5. 구조
- 각 요소는 . 으로 구분됨
1. Header
JWT에서 사용할 타입, 알고리즘 종류 정보를 포함한다.
2. Payload
서버에서 첨부한 사용자 권한 정보 & 데이터를 포함한다.
3. Signature
- 기능
Signature에 담긴 문자열을 통해 서버에서 이 토큰이 유효한 것인지 검증한다. - 구조
(1) Header와 Payload를 Base64 URL-Safe Encode해서
(2) Header에 명시된 해시함수를 적용한 것과
(3) 개인키로 서명한 전자서명을
(4) 암호화함 (아래 예시에서는 타원곡선 암호화(ECDSA)사용)
정리하면 아래와 같은 구조다.
위의sig를 사용해 JWT 전체의 구조를 나타내면 아래와 같다.
6. 장점
- JWT는 최근 웹서비스에서 범용적으로 사용되고 있으며, 규격이 정해져있기 때문에 다양한 클라이언트 (웹, 모바일 등)에서 호환성이 뛰어나다
- RESTful과 같은 무상태 환경에서의 통신이 용이하고 사용하기 쉽다.
- 데이터를 자체적으로 가지고 있어, 데이터를 얻기 위해 타 서비스에 다시 요청하는 횟수가 줄어, 서버의 부담이 줄어든다.
7. 단점 및 한계
- Payload가 많아지면 토큰의 사이즈 증가로 트래픽의 크기가 커져, 네트워크 과부화가 올 수 있다.
- 토큰이 재발급되기 전까지 사용자 정보가 갱신되더라도 적용되지 않는 문제가 있다.
- 토큰에 만료시간이 있는 경우 만료시간까지는 강제적으로 만료시킬 수 없으므로 노출이 되어서는 안되며, 중요정보를 저장하기에 부적절하다.
4. References
Java Developer