[240220] 11. 클라이언트 식별과 쿠키 ~ 12. 기본 인증

[jaenny]

• 질문은 코멘트로 남겨주세요.

Q. 질문

A. 답변

[jaenny]

Q. 공인IP, 사설IP, 고정IP, 동적IP 차이 알아보기

A. https://m.blog.naver.com/xcripts/70121283191 참고

[jaenny]

Q. 다른 회사들은 쿠키를 어디까지 사용하나요?!

A. 답변

[seoyeonkim01]

p.318 문서가 Set-Cookie 헤더를 제외하고 캐시를 해도 될경우라면 그 문서에 명시적으로 Cache-Control: no-cache="Set-Cookie" 를 기술 해서 명확히 표시한다. 또한 캐시를 해도 되는 문서에 Cache-Control:public 사용하면 웹의 대역폭을 더 절약시켜준다.

Q. 위 문장의 의미는?

문서가 Set-Cookie 헤더를 제외하고 캐시를 해도 될경우라면 그 문서에 명시적으로 Cache-Control: no-cache="Set-Cookie" 를 기술 해서 명확히 표시한다.

A. 보통 위와 같이 no-cache="Set-Cookie"를 기술하는것이 표준 HTTP 매커니즘은 아니라고함. 일반적으로 Cache-Control:no-store 또는 Cache-Control:no-cache 를 사용해서 쿠키를 설정하는 응답이 캐시되지 않도록 함.

• no-cache: 대부분의 브라우저에서 max-age=0과 동일한 뜻을 가짐. 캐시는 저장하지만, 사용하려고 할때마다 서버에 재검증 요청을 보내야함
• no-store: 캐시를 절대로 해서는 안되는 리소스일 사용. (어떤 경우에도 캐시 저장소에 해당 리소스를 저장하지 않음)

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary https://toss.tech/article/smart-web-service-cache

캐시를 해도 되는 문서에 Cache-Control:public을 사용하면 웹의 대역폭을 더 절약시켜준다.

A. Cache-Control: public 지시어는 응답이 공개 캐시에 의해 저장되어도 좋다는 것을 나타냄. 공개 캐시에 저장되어 있으면, 해당 문서를 빠르게 반환할 수 있음.

• public은 모든 사람과 중간 서버가 캐시를 저장할 수 있음을 나타냄.
• private은 가장 끝의 사용자 브라우저만 캐시를 저장할 수 있음을 나타냄.

[seoyeonkim01]

Q. AWS CloudFront(CDN)과 같이 중간 서버에서 쿠키에 따라 캐시를 만료시키는지?

A. 기본적으로 쿠키를 고려하지 않고, Cookie 헤더의 내용을 제외하고 동일한 두 개의 요청을 CloudFront가 수신하면 요청을 동일하게 처리하고 동일한 객체를 반환함.

하지만 쿠키 일부 또는 전체를 오리진으로 전달하고, 전달 되는 쿠키 값에 따라 별도의 객체 버전을 캐싱하도록 수성할 수 있다고 함.

1. 오리진에 모든 쿠키 전달: 오리진에서 응답을 반환할 때, 최종 사용자 요청의 쿠키 이름 및 쿠키 값을 사용해서 응답 캐싱
2. 일부만 전달
3. 전달하지 않음: Set-Cookie 헤더 제거

https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/Cookies.html

[soheeeeP]

p. 318 Set-Cookie가 있는 이미지에 대해서는 캐시를 하지만 Set-Cookie가 있는 텍스트는 캐시를 하지 않는 캐시도 있다

Q. 문장의 의미

A. 모르겠음

[autumndr3ams]

Q. OAuth, JWT, Bearer token

• Bearer token: _HTTP통신에서 사용하는 인증 방식에 Bearer Authentication을 사용하는 것_이다. Bearer Authentication이란, "이 토큰을 나르는(bearer) 사람에게 권한을 부여하시오"라는 것인데, 앞서 살펴본 Oauth 역시 사용자가 아닌 소비자가 중간에서 사용자의 권한을 일부 부여받게 된다. Bearer Token은 JWT나 Oauth에서 사용되는 토큰을 모두 통칭하는 용어이다.

• OAuth: 사용자가 가입된 서비스의 API에 접근하기 위해 사용자로부터 권한을 위임받아야함. 이 때 사용자의 패스워드 없이도 권한을 위임받아 Oauth를 통해 상호 연동을 지원. 자격증명을 노출하지 않고 사용자 리소스에 대한 액세스 권한을 타사 애플리케이션에 부여해야 할 때 유용함

• JWT: 헤더, 페이로드, 서명의 세 부분으로 구성됨. 일반적으로 사용자가 애플리케이션에 로그인하고 JWT를 응답으로 받음. 그 다음 JWT를 사용하여 애플리케이션 내의 보호된 리소스에 액세스 가능. 사용자를 인증하고 애플리케이션 내의 보호된 리소스에 대한 액세스 권한을 부여해야 할 때 유용

차이점 OAuth는 권한 부여에 사용 JWT는 인증에 사용 OAuth에는 인증 서버 필요, JWT 흐름이 더 간단함

https://hgko-dev.tistory.com/294

[soheeeeP]

(스터디 때 잠깐 언급되었던 내용 정리)

A. Cache-Control 옵션

• no-cache: 리소스에 대한 캐시를 생성하지만, 리소스를 요청할 때 원 서버에 항상 캐시 유효성 검증을 하는 옵션
• no-store: 리소스에 대한 캐시를 생성하지 않는 옵션. 저장하면 안되는 민감한 정보일 때 사용
  • CDN과 같은 중간 서버를 사용할 때, 캐시가 여러 곳에 생길 수 있음. 이럴 때 no-store를 설정하거나 CDN Invalidation를 적용