* * 작성 중인 글입니다. * *
🍀 오늘의 날짜 : 23년 05월 02일 ~ 4일. + 0923 업데이트><
🍀 오늘의 주제 : Cookie / Session / Token
Chapter 01 : Cookie
쿠키는 서버에서 " 클라이언트 " 에 영속성 있는 데이터를 저장( 방문자 컴퓨터의 메모리에 저장 )하는 방법입니다. 서버는 클라이언트의 쿠키를 이용하여 데이터를 가져올 수 있고, 클라이언트에서 서버로 쿠키를 다시 전송할 수 있습니다.
일반적으로 쿠키는 우리의 인터넷 활동을 식별하는데 사용되는 작은 데이터 파일로 우리가 온라인에서 활동한 행동들을 모니터링할 수 있도록 우리들의 기기에 생성이 됩니다. 우리들의 온라인 활동을 추적하고 개인화하고 저장하기 위해 특별히 생성되는 친구들입니다.
개발자 입장에서 다시 쿠키를 확인해보면, 서버는 쿠키를 이용하여 클라이언트에 특정한 데이터를 저장하고 다시 불러와서 사용할 수 있습니다. 물론 데이터를 저장하고 아무 때나 데이터를 가져오는 것이 아니라 특정 조건들이 만족되어야 다시 가져올 수 있습니다. 이러한 특정 조건들은 http 헤더를 사용해서 쿠키 옵션 ( Cookie Option )으로 표현할 수 있습니다.
쿠키 옵션 ( Cookie Option )
#Domain #Path #MaxAge or Expires #Secure #HttpOnly #SameSite
1. Domain
Domain은 포트, 서브 도메인(www) 정보, 세부 경로를 포함하지 않습니다.
쿠키 옵션에서 도메인 정보를 지정함으로써 클라이언트에서 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키를 전송할 수 있게 설정할 수 있습니다.
> http:///www.localhost.com:3000/users/login
2. Path
Path 는 세부 경로로써 서버가 라우팅할 때 사용하는 경로를 의미합니다.
쿠키 옵션에서 Path 를 지정함으로써 정해진 세부 경로와 일치할 때 쿠키를 전송할 수 있습니다.
> http:///www.localhost.com:3000/users/login
3. MaxAge or Expires
MaxAge or Expires 는 쿠키의 유효기간을 정하는 옵션입니다.
MaxAge 는 유효 기간을 초 단위로 설정하는 옵션이고, Expires 는 특정 날짜까지 유효하다는 심판의 날을 지정하는 옵션입니다.
[1] Session Cookie : MaxAge 또는 Expires 옵션이 없는 임시 쿠키로 브라우저가 실행될 때만 사용할 수 있습니다.
[2] Persistent Cookie : 브라우저의 실행/종료와 관계없이 지정된 유효기간만큼 사용할 수 있습니다.
4. Secure
사용하는 프로토콜에 따른 쿠키의 전송 여부를 결정하는 옵션으로 true / false 로 설정할 수 있습니다.
true 일 때는 HTTPS 를 이용하는 경우에만 쿠키를 전송할 수 있습니다. 다만 도메인이 localhost가 아닌 경우에는 true 설정이어도 HTTPS가 아니어도 쿠키 전소이 가능합니다.
5. HttpOnly **
자바스크립트로 브라우저의 쿠키에 접근이 가능한지 여부를 결정하는 옵션으로 true / false 로 설정할 수 있습니다.
true 일 때는 자바스크립트로 쿠키에 접근이 불가능합니다.
false 인 경우 document.cookie를 이용해 쿠키의 탈취 위험이 있으니 주의해야 합니다.
6. SameSite
Cross-Site 요청을 받은 경우, 요청에서 사용한 메서드와 해당 옵션의 조합을 기준으로 서버의 쿠키 전송 여부를 결정할 수 있습니다. ( ** Cross - Origin 아닙니다. ) SameSite 옵션에서 설정할 수 있는 속성은 다음과 같이 3가지가 있습니다.
[1] Lax : Cross - Site 요청이라면 GET 메서드 일 경우만 쿠키를 전송할 수 있습니다.
[2] Strict : 가장 엄격한 옵션으로 Same - Site 인 경우에만 쿠키를 전송할 수 있습니다.
[3] None : 가장 관대한 옵션으로 항상 쿠키를 보내줄 수 있습니다만 쿠키 옵션 중 Secure 옵션이 필요합니다.
≫ Cross - Site 와 Cross - Origin 의 차이점
- Cross - Site
** 업데이트 예정 **
- Cross - Origin
쿠키가 더이상 쓸 수 가 없다고 .. ?
구글은 2023년 말까지 크롬(Chrome)에서 3자 쿠키 지원을 중단할 것을 발표했습니다. 애플은 이미 사파리(Safari) 웹 브라우저에서 승인되지 않은 3자 쿠키 지원을 중단했고 파이어폭스(Firefox)는 벌써 몇 년 전에 사용자 보호 권한을 적용했습니다.
여기서 나오는 3자 쿠키란 써드파티 쿠키 ( Third - Party Cookies )라고도 불리우며 주로 광고 플랫폼(Ad Tech) 회사들이 사용자의 행동 데이터를 수집하고 광고 타켓팅에 사용하기 위해 추가하는 쿠키입니다. 예를 들어 신발을 하나 검색했는데 인스타나 유튜브에 광고로 신발 추천이 뜨는 것도 이러한 써드파티 쿠키를 활용한 사례라고 할 수 있습니다.
써드파티라고 하니 퍼스트 파티 도 있을 것 같은데 실제로 퍼스트 파티 쿠키( First - Party -Cookies )도 존재합니다. 다만 이름 그대로 퍼스트 파티 쿠키는 해당 웹사이트의 소유자가 고객들을 더욱 이해하고 고객의 욕구에 알맞는 서비스를 제공하여 UX (사용자 경험) 향상을 위해 데이터를 수집하는 경우로 웹사이트 주인이 소유하고 고객이 사이트를 이탈하면 고객의 온라인 활동 데이터를 추적할 수 없습니다.
이러한 이유로 마케팅 업계에서는 써드 파티 쿠키를 더이상 사용할 수 없는 상황을 대비하여 다양한 전략을 준비하고 있는 상태입니다.
* 참고 : 서드파티 쿠키 종말을 대비하는 10가지 방법
Chapter 02 : Session
우선 Session은 웹 서버가 세션 아이디와 파일을 만들어 서비스가 돌아가고 있는 " 서버 " 에 저장하는 방식입니다.
일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 " 상태 " 로 보고 해당 상태를 일정하게 유지시키는 기술입니다.
* 일정 시간 : 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점으로부터 웹 브라우저를 종료함으로써 연결을 끝내는 시점
: = 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보며 이를 세션이라고 합니다.
** 업데이트 중 **
Chapter 03 : Token
웹 애플리케이션에서 많이 사용되는 인증 방식 중 하나로 사용자의 인증 정보를 ' 서버 ' 가 아닌 ' 클라이언트 ' 측에 저장할 수 있습니다.
기존의 세션 기반 인증이 가지고 있던 한계를 극복하기 위해 고안되었습니다. 세션 기반 인증은 서버에서 유저의 상태를 관리합니다. 그래서 개발자들은 서버의 부담을 줄이기 위해 서버가 아닌 클라이언트에 저장하여 서버의 부하나 메모리 부족 문제를 줄일 수 있게 되었습니다.
웹 보안에서의 토큰은 인증과 권한 정보를 담고 있는 암호화된 문자열을 의미합니다. 이를 이용해 특정 애플리케이션에 대한 사용자의 접근 권한을 부여할 수 있습니다.
🍀 토큰 인증 방식의 장점을 따로 나열하자면 다음과 같습니다. 🍀
- 무상태성 : 서버가 유저의 인증 상태를 관리하지 않음. 서버는 비밀 키를 통해 클라이언트에서 보낸 토큰의 유효성만 검증하면 되기 때문에 무상태적인 아키텍처를 구축할 수 있음.
- 확장성 : 다수의 서버가 공통된 세션 데이터를 가질 필요가 없어서 서버 확장에 매우 용이.
- 어디서나 토큰 생성 가능 : 토큰의 생성과 검증이 하나의 서버에서 이루어지지 않아도 되기 때문에 토큰 생성만 담당하는 서버를 구축하여 편리하게 사용할 수 있음 ( Ex. 여러 서비스 간의 공통된 인증 서버 구현 )
- 권한 부여에 용이 : 토큰은 인증 상태, 접근 권한 등 다양한 정보를 담을 수 있기 때문에 사용자 권한 부여에 용이. (Ex. 어드민 권한 부여 및 정보에 접근할 수 있는 범위 설정 가능 )
🍀 토큰 인증 방식의 한계점은 다음과 같습니다. 🍀
- 무상태성 : 인증 상태를 관리하는 주체가 서버가 아니기 때문에 토큰이 탈취 될 경우 해당 토큰을 강제로 만료가 불가하다는 문제가 있어 토큰이 만료될 때까지 사용자로 가장해 계속해서 악의적인 요청을 보낼 수 있습니다.
- 유효기간 : 토큰 탈취 방지를 위해 유효기간을 짧게 설정하면 사용자는 토큰이 만료 될 때마다 다시 로그인을 진행해야 하는 좋지 못한 UX(사용자 경험)을 제공합니다.
- 토큰의 크기 : 여러 정보를 담을 수 있는 만큼 많은 데이터를 담으면 그만큼 암호화하는 과정도 길어지고 토큰의 크기도 커지기 때문에 네트워크 비용 문제가 생길 수 있습니다.
이러한 토큰의 한계점을 극복하기 위한 방법죽 대표적인 구현 방법중 하나가 " 액세스 토큰 "과 " 리프레시 토큰" 을 함께 사용 하는 것 입니다.
액세스 토큰 & 리프레시 토큰
액세스 토큰과 리프레시 토큰을 사용하면 짧은 유효기간을 가진 액세스 토큰이 만료되어도 유효기간이 긴 리프레시 유효기간이 남아 토큰을 재 발급하고 사용자는 지속해서 인증 상태를 유지할 수 있습니다. 보안을 위해 리프레시 토큰을 세션처럼 서버에 저장하고 이에 대한 상태를 관리하기도 합니다. 서버에서 상태를 관리하지 않기 위해 고안된 토큰 인증도 결국은 보안 때문에 일정 부분은 서버에서 상태를 관리해야 하는 것 처럼 "완벽한 보안 방법" 은 없습니다.
1. Access Token
서버에 접근하기 위한 토큰으로 다른 토큰과 비슷한 역할을 합니다. 보안을 위해 보통 24시간 정도의 짧은 유효기간이 설정되어 있습니다.
2. Refresh Token
액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용되는 토큰입니다. 그래서 리프레시 토큰은 액세스 토큰보다 긴 유효기간을 설정합니다.
JWT (JSON Web Token)
JWT는 토큰 기반 인증 구현 시 대표적으로 사용하는 기술입니다. JSON 객체에 정보를 담고 이를 토큰으로 암호화하여 전송할 수 있는 기술입니다. 다음과 같은 흐름으로 인증 정보 검증이 이루어집니다.
1. 클라이언트가 서버에 요청을 보낼 때 인증정보를 암호화된 JWT 토큰으로 전송
2. 서버는 이 토큰을 검증하여 인증정보를 확인
간단한 느낀 점
질문 사항들 정리 예정
refresh token : 새로운 엑세스 토큰 발급 및 재발급
acces token: 브라우저 끄는 순간 토큰 없어지게 / 단발적으로 사용하니까?
근데 왜 checkedKeepLogin 이 true 일때 access token 이랑 refreshToken 둘다 주나요? refreshToken 한개만 주면 무슨 차이가 있나요? 그냥 처음부터 리프래쉬로 검증하면 안되나용?
+ 생각해보니까 궁금하네요
토큰이 하나만 있을때랑 리프레쉬토큰이랑 같이 2개가 있을때
사용자 입장에서 무슨 차이가 있는건지?
>>ANSWER
access token에는 권한 등 서비스를 이용할 수 있는 정보들이 많이 들어갑니다.
refreshToken은 accessToken을 제발급받기 위한 최소한의 정보만 기록합니다.
refresh만 있을 때 새로고침하면 access가 새로 재발급 받아서 page가 유지되도록 해야 하는 건가요? - 맞음
단순히 새로고침했으 대 아무런 요청이 일어나지 않는데 어떻게 access 재발급이 되는 건가요"
>> 별도의 요청을 진행해서 RefreshToken으로 - accessToken을 새롭게 발급 받아야 함.
'일상의 기록 > 🌷DAILY 회고록 : 코드스테이츠' 카테고리의 다른 글
| 메인 프로젝트 1차 마무리 회고 (0) | 2023.08.08 |
|---|---|
| 프론트엔드에서 하는 Google oAuth 로그인 로직 (0) | 2023.07.19 |
| 메인 플젝 진행 중 - 03 : 무한 스크롤과 + 휠 이미지 슬라이드 + 구글 OAUTH (0) | 2023.07.02 |
| react-query x typescript data call. error (0) | 2023.06.21 |
| 돌겠음 msw이용해서 fetch해서 데이터 filter돌리기 에러 무한 에러 . (0) | 2023.06.20 |