TIL - 24.01.17

인증과 인가에 대하여

이전 팀 프로젝트에서도 그렇고, 개인 과제에서도 그렇고 인증과 인가에 대해 자세하게 학습하지 못한 상태에서 코드를 작성해왔다.

 

인증과 인가에 대해 좀 더 알아보았다.

 

 

1. 인증의 종류

1) 쿠키 / 세션 기반 인증

쿠키란?

쿠키는 브라우저에 저장되는 작은 데이터. 클라이언트 상태정보를 저장하기 위해 사용함.

서버에서 전송되어 클라이언트(브라우저)에 저장되고 이후 같은 서버에서 요청이 있을 때마다 자동으로 서버로 쿠키값 전송함. 이름, 값, 유효시간, 도메인, 경로정보 등이 포함

 

세션이란?

세션은 서버 측에서 클라이언트의 상태를 유지하는 기술.

클라이언트에게 고유의 세션 ID를 부여하여 클라이언트 정보 확인. 이 때 세션 ID를 부여하기 위해 쿠키 사용함.

 

즉 클라이언트가 로그인 시 서버는 클라이언트에게 세션 ID를 부여하고 ID와 클라이언트 정보를 메모리에 저장함.

클라이언트는 이 세션 ID를 쿠키로 받음. 이렇게 되면 클라이언트는 다음 요청부터 서버에 세션ID가 쿠키에 담긴 채 요청을 보냄. 

서버는 클라이언트의 세션 ID가 메모리에 존재하는지 확인하고, 존재할 경우 정상적으로 응답. 아닐 경우 에러.

 

이런 방식은 클라이언트의 인증 상태 정보를 매번 확인하므로 stateful 한 구조임.

 

1-2) 장/단점

장점: 클라이언트 정보를 모두 서버에서 관리하므로 보안성이 좋고 세션ID만 클라이언트와 서버 사이를 왔다갔다 하므로 트래픽이 적음.

 

단점

확장성이 좋지는 않음. 보통 사용자가 많은 서비스의 경우 서버를 여러대 사용하는데, 세션ID는 서버의 메모리에 저장됨. 즉 클라이언트가 기존에 요청하던 서버가 아닌 다른 서버에 요청할 시 해당 서버는 클라이언트의 세션ID가 없다고 판단함.

그렇다고 서버측 메모리가 아닌 별도의 저장소에 세션ID를 저장할 경우 매 요청마다 저장소를 통해 세션 ID를 확인하는 작업이 추가되어 매우 비효율적.

 

2) 토큰 기반 인증

인증 정보를 서버에서 저장하지 않고 토큰이라는 데이터에 저장하여 클라이언트가 토큰을 갖고 요청을 하게끔 하는 방식

서버는 토큰을 생성해서 클라이언트에게 제공, 클라이언트는 토큰을 저장하고 요청시 서버에 전송함.

토큰 정보를 클라이언트에서 하므로 서버는 토큰 수령시 해당 서버에서 발급한 토큰인지 검사해야 함. 때문에 토큰 검증에 대한 절차를 추가로 설정할 필요가 있음.

일반적으로 HTTP Header에 토큰을 넣어 함께 전송함.

서버에서 토큰을 저장하지 않고 세션상태를 유지하지 않으므로 Stateless한 구조. 즉 확장성이 좋음. 검증 방식만 공유되면 다른 로그인 시스템에서도 동일한 토큰으로 인증 가능함.

보안상 취약하다는 단점이 있음.

 

3) JWT

확장성이라는 문제 때문에 대부분 토큰 기반 인증을 사용함. 토큰은 어떤 형태든 될 수 있지만, JWT(JSON Web Token) 형태를 가장 많이 사용.

JWT는 XXXXX.YYYYY.ZZZZZ 형태의 문자열로 이루어진 토큰이다.

XXXXX 부분은 헤더(Header), YYYYY 부분은 내용(Payload), ZZZZZ 부분은 서명(Signature) 이다.

 

여기서 헤더와 페이로드 부분은 JSON형태인데, base64 인코더를 이용해 문자열로 바꿈.

헤더엔 알고리즘, 토큰 타입을 지정.

내용엔 서버에서 설정한 사용자 권한 정보가 들어있음. 토큰의 발급 주체, 대상 주체, 만료시간, 식별자 등이 포함

서명은 서버가 자신이 보낸 JWT가 맞는지 검증하기 위한 값이다.

헤더와 내용을 함쳐 암호화 한 후 한번 더 base64로 인코딩한 값.

서명 알고리즘은 크게 2가지로 나누는데, 대칭키와 비대칭키이다.

 

대칭기

한개의 키로 암호화 및 복호화가 가능할 때 이를 대칭키라고 함. 여기서 키는 단순한 문자열인데, 암호화 함수에 키와 메세지가 인자로 들어가면 알수없는 문자열이 함수의 결과로 나옴. 

즉 서버는 본인이 암호화 한 메세지를 원래 메세지 뒤에 붙혀놓고, 해당 암호문을 복호화 해서 원래 메세지와 비교하면 본인이 보낸 메세지인지 확인할 수 있다. (여기서 메세지는 헤드와 내용을 가리킴)

M:메세지 O:암호문 K: 키 라고 할 때

암호화 함수(M, K) = O

전송 시 M + O 이런 형태로 보냄. 서버는 해당 메세지를 받고 암호문을 키를 이용해 복호화

복호화 함수(O, K) = M 과 함께 온 M을 비교해서 같을 경우 인증처리

이 부가적인 암호문을 서명이라고 함.

 

비대칭키

키를 공개키, 개인키 두개로 나누어 사용.

한 키로 서명시 다른 한 키로 복호화 가능.

즉 A가 B에게 공개키를 제공하면 B는 공개키를 이용해 암호화. 이 암호문은 개인키를 가진 A만 복호화 가능.

A는 B에게 개인키로 암호화한 암호문을 전송하면 B는 공개키를 이용해서 암호문을 복호화 할 수 있음.

이 과정을 전자서명이라고 함.

 

대칭키는 키 관리가 중요하므로 단일 시스템 내에서 통신할 때 적합하다.

비대칭키는 공개키를 공유할 수 있으므로 다수의 시스템이 토큰을 공유하고 검증할 때 적합하다.