본문 바로가기
카테고리 없음

Authentication/Authorization

by 띠리에이터 2024. 2. 27.
Authentication
  • 인증 : 서버가 리퀘스트를 보낸 유저가 누구인지를 파악하는 기능
Authorization
  • 인가 : 리퀘스트가 어떤 권한이 있는지 판단하는것

 

 

 

클라이언트가 서버에 인증서를 받고 다시 서버에게 전달하는 방법 두 가지↓
http는 비연결성과 무상태성을 가진다. 

-> 한번 서버에 요청하고 응답을 받으면 연결이 끊긴다. 따라 지속성을 위해 쿠키가 등장! 

1. 쿠키 
  • 서버 리스폰스나 클라이언트 코드에 따라 브라우저에 저장되는 작은 단위의 문자열 파일들
  • 유저 인증뿐만 아니라 브라우저 이용자에 대한 개인화된 기능과 데이터 제공 수단으로 사용할 수있다. 
    - 로그인을 하지 않아도 검색기록이 저장되거나 쇼핑카트를 사용 하거나, 테마 유지 등

쿠키 인증 사용 시 보안 설정

 

 

  • Domin
    - 서버와 요청의 도메인이 일치하는 경우 쿠키 전송
    - 쿠키에 접근 가능한 도메인을 지정. 
  • path
    - 서버와 요청의 세부 경로가 일치하는 경우 쿠키 전송 
    - 이 경로나 이 경로의 하위 경로에 있는 페이지만 쿠키에 접근할 수 있다. 
  • MaxAge or Expires
    - 쿠키의 유효기간 설정 , 옵션이 지정되어있지 않으면 브라우저가 닫힐 때 쿠키도 함께 삭제
    -> 이런 쿠키를 세션 쿠키라고 부름 

    - MaxAge  : 만료기간
    - Expires : 유효일자 
// 1시간 뒤에 쿠키가 삭제됩니다.
document.cookie = "user=John; max-age=3600";

// 만료 기간을 0으로 지정하여 쿠키를 바로 삭제함
document.cookie = "user=John; max-age=0";

// 지금으로부터 하루 후
let date = new Date(Date.now() + 86400e3);
date = date.toUTCString();
document.cookie = "user=John; expires=" + date;
  •  Secure
    - 서버에서 response를 보낼 때 이 설정을 추가해주면 http보다 보안에 강한 https를 사용할 때만 클라이언트에서 서버로 쿠키가 보내진다. 
    -> https를 사용하면 리퀘스트와 리스폰스가 암호화 되기 때문에 정보유출을 줄일 수 있음.
Set-Cookie: cookie_name=cookie_value; Secure;
//리스폰스 set-cookie헤더에 이름-값 쌍 뒤 ;과 Secure키워드를 통해 적용

 

  • HttpOnly
    - 클라이언트가 자바스크립트 코드로 해당 쿠키에 접근할 수 없게 된다
Set-Cookie: cookie_name=cookie_value; Secure; HttpOnly;
//리스폰스 Set-Cookie 헤더에 이름-값 쌍 뒤 ;과 HttpOnly 키워드를 사용해서 적용
  • SameSite
    - csrf공격을 예방할 수 있는 설정.
    - SameSite를 stritc로 하면 다른 도메인에서 리퀘스트를 보낼 때 쿠키가 가는 걸 아예 방지할 수 있음
    -> 리퀘스트를 보내는 클라이언트와 이걸 받는 서버의 도메인이 서로 같을 때만 쿠키 전송

    - SameSite 속성
    1. lax
    2. strict
    3.none
Set-Cookie: cookie_name=cookie_value; Secure; HttpOnly; SameSite=Lax;
//리스폰스 Set-Cookie 헤더에 이름-값 쌍 뒤 ;과 SameSite 키워드, 
//그리고 원하는 쿠키 사용 범위 키워드, None, Lax, Strict를 사용해서 적용

 

 

2. 세션
  • 서버가 저장하는 사이트 방문자들의 기록 

 

 

 

 

 

토큰의 종류
  •  accessToken
  • refreshToken
  • jwt Token
    - 점을 기준으로 3부분으로 나눔
    -> header / payload / signature
    1. header -> 토큰 자체에 대한 정보 저정, 암호화에 사용된 알고리즘, 토큰 형식 등
    2.payload -> 토큰이 실질적으로 저장하려는 데이터 , 공식적으로 사용하는 키값이 있다. 
    3.signature -> 토큰을 믿을 수 있는지 확인하기 위한 데이터 저장

    토큰의 header , payload는 암호화된 내용이 아니라서 누구나 볼 수 있다. 
    -> 비밀번호 같이 보안에 민감함 내용은 넣지 않

accessToken보다는 refreshToken이 더 좋아보임 이유는? 

refreshToken은 access 토큰이 만료됐을 때 이메일 비밀번호를 사용하지않고 access 토큰을 새롭게 발급받는데 사용되는 토 

비밀번호는 절대 절대 로컬스토리지에 저장 x

 

더 찾아보고