인증과 쿠키

개발로 쓰는 개발 노트·2023년 6월 13일
http김영한인증쿠키
0

모든 개발자를 위한 HTTP 웹 기본 지식

목록 보기
22/23

인증

  • Authorization : 클라이언트 인증 정보를 서버에 전달한다.
  • WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의

Authorization

  • 클라이언트 인증 정보를 서버에 전달한다.
  • Authorization : Basic xxxxxxxxxxxxxx

WWW-Authenticate

  • 리소스 접근 시 필요한 인증 방법을 정의한다.
  • 401 Unauthorized 응답과 함께 사용(인증이 필요합니다.)
  • WWW-Authenticate : Newauth realm="apps", type=1, title="Login to|"apps|"", Basic realm="simple" 위와 같은 필요한 인증에 대해 알려준다.

정리

  • 인증은 간단하다. Authorization를 통해 서버에 클라이언트 인증을 요청하고
  • 401에러가 생기면 서버에선 WWW-Authenticate를 메시지 헤더에서 응답한다.

쿠키

  • Set-Cookie : 서버에서 클라이언트로 쿠키 전달(응답)
  • Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달한다.
  • 간단하게 서버가 먼저 클라이언트로 쿠키를 준다.
  • 클라이언트는 쿠키를 저장 후에 HTTP가 요청하면 서버로 전달한다.

쿠키 미사용 시

  • 로그인을 한다고 가정하자.
  • GET메서드를 이용하여 클라이언트는 로그인 페이지로 요청한다.
  • 서버에서 로그인 페이지를 응답했다.
  • POST메서드를 이용하여 클라이언트가 로그인을 시도한다.
  • 서버에서 특정 유저가 로그인 했다는 것을 응답하고 페이지를 보여준다.
  • 다시 GET방식을 이용하여 클라이언트가 로그인 페이지를 요청할 때는 특정 유저에 대한 정보가 없기 때문에 기억할 수 없다.
  • Stateless 무상태 프로토콜을 기본으로 하기 때문에 서버는 당연히 특정 유저의 정보를 알 수 없다.

쿠키 미사용 시 위의 문제를 해결하려면?

  • 로그인을 한다.
  • 로그인을 했고 다시 GET방식을 이용하여 클라이언트가 요청할 때 유저의 정보를 계속해서 포함해서 넘긴다.

위 과정에서의 단점

  • 모든 요청에 사용자 정보가 포함되도록 개발해야한다.
  • 보안상의 문제도 있다.
  • 브라우저를 완전히 종료했다가 다시 요청하면 위의 요청조차 불가능하다.

쿠키 사용 시

  • 위의 단점을 해결하기 위해 쿠키를 사용한다.
  • 로그인을 했을 때 서버에서는 클라이언트에게 Set-Cookie라는 HTTP 응답메시지를 보낸다.
GET/welcome HTTP/1.1
Set-Cookie: user=홍길동
  • Set-Cookie를 받은 클라이언트는 이를 쿠키 저장소에 집어넣는다.
user=홍길동
  • GET방식을 이용하여 클라이언트가 다시 서버에 요청할 때는 쿠키 저장소에서 적절한 값을 찾는다.
    Cookie: user=홍길동 을 찾는다.
  • 이후에는 모든 요청에서 Cookie: user=홍길동을 찾아내서 GET방식으로 요청해도 로그인이 된 상태로 페이지를 로딩한다.

쿠키

  • 쿠키는 아래처럼 서버에 보내진다.
set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; 
path=/; domain=.google.com; Secure
  • 주 사용처
    • 사용자 로그인 세션 관리
    • 광고 정보를 트래킹할 때 많이 이용한다.(이 사용자가 어떤 것을 보는지?)
  • 쿠키 정보는 항상 서버에 전송된다.
    • 네트워크 트래픽을 추가로 유발한다.
    • 최소한의 정보만을 사용해야한다.(세션ID, 인증 토큰)
    • 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶다면 웹 스토리지(localStorage, sessionStorage)를 참고 하자
  • 주의해야 하는 사항
    • 보안에 민감한 데이터는 저장하면 안된다.(주민번호, 신용카드 번호 등등) 무조건 서버에 전송하기 때문에 원하지 않아도 보내지게 된다. 보안상 문제가 된다.

쿠키의 생명주기(Expires, max-age)

  • Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
    • 반드시 GMT기준으로 넣어주어야 한다.
    • 만료일이 되면 쿠키는 삭제된다.
  • Set-Cookie: max-age=3600(3600초)
    • 0이나 음수를 지정하면 바로 쿠키 삭제
  • 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지한다.
  • 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지한다.

쿠키의 도메인

  • 예) domain=example.org
  • 명시 : 명시한 문서 기준 도메인 + 서브 도메인 포함
    • domain=example.org를 지정해서 쿠키 생성
      • example.org는 물론이고
      • dev.example.org도 쿠키를 접근한다.
  • 생략 : 현재 문서 기준 도메인만 적용한다.
    • example.org에서 쿠키를 생성하고 domain 지정을 생략한다면
      • example.org에서만 쿠키 접근이 가능하다.
      • dev.example.org에서는 쿠키가 접근이 안된다.

쿠키 경로

  • 예) path=/home
  • 이 경로를 포함한 하위 경로 페이지만 쿠키 접근이 가능하다.
  • 일반적으로 path=/ 루트 페이지로 지정한다.
    • 보통 도메인에 있는 동안은 쿠키가 유지되길 원하기 때문
  • 예)
    • path=/home으로 지정한다면
    • /home 에서는 쿠키 접근이 가능하다.
    • /home/level1 에서 쿠키 접근이 가능하다.
    • /home/level1/level2 에서 쿠키 접근이 가능하다.
    • /hello 에서는 쿠키 접근이 불가능하다.

쿠키의 보안

  • Secure
    • 쿠키는 http, https를 구분하지 않고 전송한다.
    • 그러나 Secure를 적용하면 https인 경우에만 전송한다.
    • http, https는 메시지를 암호화 하는지 안하는지 차이가 있다.
    • http는 암호화하지 않고 https는 메시지를 암호화해서 보낸다.
  • HttpOnly
    • XSS 공격 방지
    • 자바스크립트에서 접근이 불가능하다.(document.cookie)
    • HTTP 전송에만 사용한다.
  • SameSite
    • XSRF 공격 방지
    • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송한다.
    • 생긴지 얼마 되지 않았다. 그래서 적용이 되지 않는 브라우저도 있으니 사용하려면 확인을 한 뒤 사용해야한다.

이제 캐시와 조건부 요청에 대해 알아보고 HTTP에 대해 마치려고 한다.

출처 : 모든 개발자를 위한 HTTP 웹 기본 지식(김영한 강사님 인프런 강의)

profile
개발로 쓰는 개발 노트
비전공자 개발초보입니다!
이전 포스트

HTTP 전송 방식과 정보

다음 포스트

캐시와 조건부 요청 프록시 캐시

0개의 댓글