클라이언트와 서버간 통신을 할 때 사용자의 신원을 인증할 수 있는 방법은 다양하다.
Session, Cookie
첫번쨰로 쿠키인증방식이 있다. 이는 HTTP의 stateless 방식을 보완하기 한 방법으로, 인증과정을 거친 사용자에 대해 서버 내 세션에 인증된 사용자 정보를 저장한 후 클라이언트에게 세션ID를 넘겨준다. 이후 클라이언트는 인증이 필요한 요청마다 요청 헤더에 세션ID를 담은 쿠키를 함께 넘겨준다.
로드 밸런싱이 적용된 서버에서 이 방식을 사용한다면 문제가 발생한다. 트래픽 이슈로 인해 요청을 받는 서버가 바뀐다면 클라이언트의 정보가 저장된 서버단 세션은 접근할 수 없게 된다. 서버가 In-Memory 데이터베이스를 사용하여 distributed 서버끼리 세션을 공유한다면 해결 가능하지만, 확장성이 떨어지는건 부정할 수 없다.
클라이언트가 HTTP가 아닌 Javascript를 사용하여 쿠키를 넘겨주게 된다면(대표적으로 Ajax) SOP(Same-Origin Policy; 동일 도메인 정책)에 따라 서버측에서 쿠키를 거부할 수 있다. 서버측에서 동일 도메인이 아니더라도 자바스크립트로 쿠키를 받을 수 있도록 허용한다면, 악의적인 자바스크립트 공격을 받을 가능성이 있어 서버의 보안에 안좋은 영향을 끼칠 수 있다.
HTTP Basic
두번째로 HTTP Basic 인증방식이 있다. 클라이언트 요청 헤더의 Authorization 키값에 사용자의 아이디와 비밀번호같은 개인정보를 담아 요청마다 인증을 반복하는 방식이다. 확장성이 좋지만 HTTP는 암호화를 사용하지 않기 때문에 사용자의 기밀성을 유지하기 어렵다. 이 인증방식을 사용하기 위해선 요청을 암호화하여 전송하는 HTTPS서버를 사용해야한다.
HTTP Bearer
세번째로 Bearer 인증방식이 있다. HTTP Basic과는 달리 Authorization 키값에 토큰을 넣어 전송한다. 토큰엔 사용자의 민감한 개인정보는 담지 않고 signature를 이용해 토큰의 진위여부를 판단한다. 만약 토큰이 노출되었다 하더라도, 토큰 유효시간이 있어 일정기간이 지나면 토큰은 만료된다.
