서버 인증 방식의 종류
HTTP의 특징으로 stateless와 connectionless를 떠올릴 수 있다. 즉, 상태 및 접속 정보를 유지하지 않는다는 점이다. 그럼 서버에서 클라이언트를 식별하기 위해선 어떻게 해야할까?
단순하게 HTTP의 헤더에 사용자의 계정 정보(Id/Password)를 넣음으로써 서버에서 식별할 수 있다. 하지만 이러한 방법은 제 3자에 의해 탈취당했을 때 개인정보가 드러나기 때문에 보안에 좋지 않은 방식이라 할 수 있다.
위의 문제를 해결하기 위해서는 두 가지의 방법이 존재한다.
세션 및 쿠키를 이용한 인증 방식
세션 및 쿠키를 이용한 인증 방식은 로그인 과정에서만 계정 정보를 서버에 직접 보내고, 그 후로는 세션과 쿠키를 활용하여 인증하는 방식이다.
출처 : https://tansfil.tistory.com/58
1) 인증되지 않은 사용자가 서버에 로그인 계정 정보를 보낸다.
2) 서버는 전달 받은 계정 정보를 통해 DB를 조회하여 사용자를 확인한다.
3) 서버는 세션 스토리지에 세션을 생성한다.
4) 서버는 세션 스토리지로 부터 세션ID를 발급받는다.
5) 서버는 클라이언트에게 세션ID를 포함하여 응답 메시지를 보낸다. 사용자는 전달받은 세션ID를 쿠키에 저장한다.
6) 사용자는 이후의 요청에 발급받은 쿠키를 포함하여 서버로 보낸다.
7) 서버는 쿠키를 통해 세션ID를 얻은 후 세션 스토리지로부터 세션을 얻는다.
8) 서버는 얻어진 세션을 바탕으로 요청 데이터를 찾아서 사용자에게 응답한다.
세션 쿠키 방식의 장단점
장점
1) 세션ID는 유의미한 값을 갖지 않아서 HTTP 헤더나 바디에 직접 계정정보를 담아 전송하는 것보다는 보안에 뛰어나다.
2) 세션ID는 고유의 ID값이기 때문에 서버 메모리에서 바로 검색할 수 있어 성능 향상을 기대할 수 있다.
단점
1) 가로챈 쿠키 즉, 세션 ID를 가지고 해커가 동일한 요청을 보낼 경우 진짜 사용자인지 해커인지 구분 할 수 없다.(세션 하이재킹 공격에 노출될 가능성 존재)
=> 위와 같은 단점을 보완하기 위해선 세션 유효시간을 짧게 설정하고, HTTPS 프로토콜을 사용하여야 함
2) 세션 스토리지는 별도의 메모리를 사용하기 때문에 동시 사용자가 많을 수록 서버에 부하가 생길 가능성이 있다.
토큰을 활용한 인증 방식
JWT
Json Web Token의 약자로, 인증에 필요한 정보들을 토큰으로 만든 것이다. 사용자는 HTTP헤더에 넣어 서버로 보내게 된다.(토큰 자체를 정보로 이용하는 Self-Contained 자가 수용적 방식이다)
JWT 구조
- JWT는 Header, Payload, Verify Signature의 3 부분으로 구성
- . 으로 구분되어 있다.(Header.Payload.VerifySignature 구조)
- 각 부분은 Json 형태를 Base64 인코딩하여 표현
Header
- Verify Signature를 해싱하기 위한 해싱 알고리즘에 대한 정보(암호화할 방식, 타입)
- typ: 타입(ex. JWT)
- alg: 해싱 알고리즘 종류(ex. HS256)
Paylaod
- 토큰에서 사용할 정보들, 서버에서 보낼 데이터(유저의 고유 ID 및 유효기간 등의 데이터가 들어간다.)
- 클레임(Claim)이라고 부르는 정보의 조각이 들어간다. name/value 키 쌍으로 들어가있으며 자세한 내용은 여기 참고하자.
Verify Signature
- 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드
- Header, Payload를 각각 Base64로 인코딩한 값을 합친 후, 비밀키로 해쉬를 한다. 그 해쉬 값을 Base64로 인코딩하여 생성한다.
1
2
3
4
5
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload), secretKey
)
# 이렇게 해서 나온 해쉬 값을(hex) base64 인코딩하여 사용
- base64 방식을 사용하기에 URL에서 파라미터로 사용할 수 있어 URL_Safe하고, 해시 암호화 알고리즘을 이용하여 암호화되어있다.
- 위의 Header와 Payload는 별도로 암호화를 진행하지 않기에 디코딩만 하면 바로 정보가 드러나게 된다. 하지만 Verify Signature에서 사용하는 Secret Key를 모른다면 암호화된 Header와 Payload를 복호화할 수 없도록 되어 있다. 즉, 악의적인 사용자가 JWT토큰을 사용해서 Header나 Payload를 변조한다 하더라도 Verify Signature의 값과 일치하지 않기에 안전하다고 볼 수 있다.
실제 토큰 기반의 인증이 진행되는 방식
출처 : https://tansfil.tistory.com/58
1) 사용자가 로그인 계정 정보(Id/Password)를 서버로 보낸다.
2) 서버가 DB를 조회하여 사용자를 확인한다.
3) 서버에서 액세스 토큰(JWT)를 발급한다.
4) 발급한 액세스 토큰을 사용자에게 전달한다.
5) 사용자는 전달 받은 액세스 토큰과 함께 데이터를 요청한다.
6) 서버는 단순하게 액세스 토큰을 검증하여 클라이언트를 식별한다.
7) 서버는 인가된 사용자에 한해 응답 데이터를 보내준다.
토큰 방식의 장단점
장점
1) 세션 쿠키 방식과 달리 토큰은 별도의 저장소 관리가 필요 없고 검증만 하면 되기 때문에 별도의 세션 스토리지가 필요 없다.
=> 토큰은 필요한 정보를 전부 담아두고 있기 때문에
2) Facebook이나 Google에서 지원해주는 다양한 서비스도 토큰 기반으로 진행되기 때문에 관련 기능을 확장하기 용이하다.
3) 서명(Verify Signature) 부분에 누가 보냈는지와 보낸 정보에 대한 내용들이 포함되어 있기에 중간에 데이터가 조작되어도 서버에서 이를 알아차릴 수 있다.
단점
1) 토큰의 경우도 세션 ID와 마찬가지로 탈취되었을 경우 진짜 사용자인지 해커인지 구분할 수 없다. 데이터를 조작하거나 변조하는 것은 방지할 수 있으나 해커가 실제 해당 유저로 가장하여 행동하는 건 방지할 수 없다.
=> 위와 같은 단점을 보완하기 위해 토큰 유효기간을 짧게 설정하거나(Refresh Token 사용) HTTPS 프로토콜을 사용하여야 함
2) 필요한 정보들이 전부 토큰 안에서 관리되기에 토큰의 크기가 커질 수 있다. 이로 인해, 데이터 트래픽 크기에 영향을 줄 수 있다.