HTTP 통신과 인증 인가

HTTP(Hyper Text Transfer Protocol)

- Web 상에서 client와 server 간에 통신을 위한 protocol

 

특징: Stateless protocol (상태유지 X) + Connectionless (비연결성)

 

한계: 현재 connection에 대한 client의 어떠한 상태정보도 유지할 수 없음.

 

HTTP 통신 과정

 

 

 

HTTP의 한계를 해결하기 위해 나온 방식 세가지: Cookie, Session, Token

 

 

 

 

Cookie (내가 만든 쿠키)

- client session 상태정보를 유지하기 위한 정보

 

특징: 개별 client 상태정보를 HTTP request와 HTTP response header에 같이 전달한다.

          처리속도가 빠르고 서버는 쿠키 정보를 바탕으로 페이지 접근을 허용

 

취약점: client 상태정보를 client에 저장 + HTTP request/response header에 노출 > 공격 위험성 존재

 

 

 

 

 

 

 

Session 

- 개별 client 상태정보를 server에 저장하는 방식

 

특징: server가 개별 client session을 식별하기 위해 Session ID를 부여함

       client 상태 정보를 server에 저장하므로 cookie 방식보다 보안상 안전함

 

단점: server에서 이를 처리하므로 처리 속도가 느림

 

출처: https://uncertainty.oopy.io/8f8ca9b9-cc23-4dde-80aa-4c6fbe977772

 

 

 

 

 

Token

- Cookie / Session 방식보다 보안성과 효율성을 높인 방식

 

- cookie의 단점: packet에 노출되어 공격자 탈취 가능

- session의 단점:  사용자가 많아질 경우, server의 부하 발생

 

따라서 Token은 보안성과 효율성을 모두 잡기 위한 방법이라 볼 수 있다.

 

특징: 사용자의 인증 정보를 암호화하여 이를 토큰으로 발급 해당 토큰을 갖고 다른 웹사이트에도 접근 가능

         토큰은 세션과 달리 사용자 PC에 저장

 

Access Token 인증 방식

 

 

 

Token의 종류 (JWT example)

 

- Access Token: server에 저장되지 않고 자체로 검증을 하며 사용자 권한을 인증하는 Token

Token이 만료되기 전까지 Token을 갖고 있는 사람은 누구나 권한 접근이 가능함

따라서, Token 만료시간이 비교적 짧음.

 

 

- Refresh Token: Access Token이 접근 권한을 가진 Token 이라면 Refresh Token은 Access Token이 만료되면

재발급을 위한 Token.

해당 Token은 server에 저장되며 Token 만료시간이 비교적 길다.

 

 

Access Token이 만료된 상황에서 기존의 Access Token을 전송하게 된다면,

HTTP response의 값은 401(Unauthorized)로 반환하게 될 것이다.

 

이 때, 사용자는 Refresh Token을 Access Token과 같이 함께 server로 보내면

server에 저장된 Refresh Token과 비교해

동일함을 확인하고 유효기간도 동일하다면 Access Token을 재발급해준다.