[ TIL ] Day 40 & 41 - 인증과 인가 / 쿠키, 세션, 토큰, OAuth

🗓️ 수업 일자 : 2025.11.20 ~ 21

✨ 오늘의 수업 평가 :  [ HARD ]  ⚡🧠💣 머리 과부하 ⚡🧠💣

 

뭔가 열심히 배우긴 했는데.. 

흐릿한 저 뭔가.. 아리까리 알송달송.. 알듯 말듯한 개념들이 쏟아진다.. 

실습을 통해 전체 구조는 이해 했는데, 막상 시스템에 적용 한다는 개념은 잘 안잡힌다..

 

📝  오늘 배운 내용  

- 인증과 인가 

- 쿠키(Cookie) / 세션(Session) / 토큰(Token) / OAuth

- 유저 기능 구현(정리 못함)

---

1. 인증과 인가 

인증 : Authentication, 사용자가 누구인지 확인하는 과정으로 위에 설명한 세션과 토큰으로 인증 과정을 거침

인가 : Authorization, 인증된 사용자의 권한을 확인하는 과정으로 인가를 통해 확인 된 정보를 바탕으로
          "일정 등급의 유저에게는 특정 permission을 제공" 하는 등의 서비스 가능

 

⇒ 웹 사이트에서 "인증"을 진행하면 자연스럽게 "인가"가 따라오기 때문에,
     HTTP의 Header에서는 이 두 가지를  Authorization(=인가) : ... 으로 함께 사용

 

 

 

2. 쿠키(Cookie) / 세션(Session) / 토큰(Token) / OAuth

0) 전체 간략 보기

명칭	분류	설명	관리
쿠키	저장/전송 기술	클라이언트에서 가지고 있는 작은 단위의 데이터. 주로 사용자 로그인 정보, 설정값, 세션 등이며 일부 정보는 요청에 대한 응답으로 받아 저장하고 있다가 특정 상황에 사용 (로그인 정보 등)	서버 생성 → 클라이언트 저장
세션	인증 관리 방식	서버의 사용자 인증 방식으로, 사용자가 서버에 접속하면 세션 ID를 쿠키에 담아 클라이언트에 전달. 클라이언트는 댓글 작성 등과 같은 서비스에서 해당 세션을 이용해 사용자 정보를 사용	서버 생성 & 저장 후 관리
토큰	인증 관리 방식	사용자 정보를 암호화 하여 비밀키를 생성&사용하는 인증 방식으로,  주로 JWT를 사용해 사용자 정보를 암호화 하여 문자열로 취급	서버 생성, 아무데도 저장 안함
OAuth	인증 프로토콜	유저가 허용한 범위에서, 타 사이트에 저장 된 사용자 정보를 가져와 현재 서비스에서 사용하는 방식	타 서버의 데이터 공유

 

 

 

1) 쿠키(Cookie)

- 기본 개념 : 사용자의 로그인 정보, 설정, 세션등 브라우저에 저장되는 작은 데이터 파일을 의미

- cookie 헤더 = 요청 쿠키

: [key - value] 한 쌍으로 이루어진 쿠키를 여러개 이어서 작성 가능

: 미리 설정 해 둔 조건과 요청 상황이 맞으면 클라이언트(=브라우저)가 자동으로 채워서 보냄

POST 요청을 보낼 때 Cookie 사용하는 방법 예시

 

 

- Set-Cookie = 응답 쿠키

   : 서버가 요청에 대한 처리로 response 보낼 때, 헤더 안에 Set-Cookie로 설정하여 클라이언트한테 쿠키값을 전달.
     클라이언트(=브라우저)는 응답 정보와 함께 받은 Set-Cookie 정보를 자동으로 저장

      => 클라이언트가 서버에 요청 할 때,  특정 조건이 맞으면 req에 cookie에 넣어서 다시 전달

# response 예시

HTTP/1.1 200 OK
Set-Cookie: token=abc123;          Path=/;        HttpOnly; Secure; 
          : <쿠키 이름>=<쿠키 값>; 옵션1=옵션1값;   옵션2;   옵션3 ...

 

- 자주 쓰는 Set-Cooki 쿠키 옵션 종류
( 보안 관련해서는 HttpOnly, SameSite, Secure 옵션을 함께 사용 )

• Expires : 쿠키가 만료되는 정확한 날짜와 시간을 지정
• Max-Age : 쿠키가 유효한 시간을 초 단위로 지정, Expires보다 우선순위가 높음
• Domain : 쿠키가 전송될 수 있는 도메인을 지정
• Secure : HTTPS 연결에서만 쿠키가 전송되도록 제한
• HttpOnly : JavaScript를 사용해 직접 쿠키를 접근하는 방식을 차단, XSS 공격을 방지
• SameSite : CSRF 공격 방지를 위해 cross-site 요청 시 쿠키 전송 여부를 제어
                     (클라이언트와 서버의 도메인이 같아야 쿠키 전달)
                     ⇒ 민감한 정보에 대해서만 해당 조치가 필요하고, 일반적인 값에서는 과한 조치임
                          값에 따라 제어 방식이 달라짐
  
  • SameSite=Lax : 일반적인 페이지 이동에서는 쿠키 전송 O, 민감한 요청(CSRF 위험 높은 POST 등)엔 전송 X 
                               예시) 인스타 하다가 광고 눌렀을 때(=페이지 이동), 해당 사이트와 쿠키를 공유 
  • SameSite=Strict : 아예 외부 사이트에서 오는 모든 요청엔 쿠키 전송 X (보안 최강)
                                 예시) 인스타 하다가 광고 눌러서 새로운 사이트에 접속 했지만, 쿠키는 하나도 주지 않음
  • SameSite=None : 모든 요청에 쿠키 전송 O, 대신 Secure 옵션 필수 (HTTPS만)
                                  예시) 인스타 하다가 광고 눌러서 새로운 사이트에 접속 했는데 HTTPS 사이트여서 쿠키 공유

 

2) 세션 (Session) - 인증 방식

• 기본 개념 : 서버가 사이트 방문자들에 대한 기록을 저장하는것
                  일정 시간 동안 사용자 활동 없으면 세션을 종료 시킴(세션 만료)
• 특징 : DB 또는 메모리에 저장. 특정 세션에 문제(에러,탈취 등)가 있으면, 그냥 통째로 지워서 무효화 가능
• 인증 방식 : 사용자가 사이트를 방문하면 "고유한 세션"을 만들고, 이 세션의 "세션 아이디"를 클라이언트에게 제공 
                    → 쿠키로 작성해서 클라이언트에게 응답으로 내려보냄(set-cookie에 담음), 후속 요청 전달 시 다시 사용
                    → 서버는 요청에 담긴 세션 아이디를 가지고 세션을 확인하고, 인증 된 사용자인지 체크 

 

 

3) 토큰 (Session) - 인증 방식

• 기본 개념 : 유저 정보를 암호화한 문자열, 암호화를 할 때 서버만 접근 가능한 비밀키(=암호키)   
                    탈취 당할 위험이 있기 때문에 유효 시간을 설정(1시간 등)
• 특징 : 서버에 데이터에 저장하지 않고, 내가 만든건지 정도만 확인
            ⇒ 서버 자원을 덜 쓰고, 암호키만 있으면 되서 확장이 쉬움. 토큰이 탈취 당하면 후속 처리가 어려움
• 인증 방식 : 로그인 하면 사용자의 인증 상태를 암호화 한 토큰을 만들어서 클라이언트에게 제공        
                   → 쿠키 또는 응답 바디 중 하나를 선택해 전달
                   → 클라이언트는 후속 요청을 보낼 때 마다 토큰을 함께 보냄 (쿠키 또는 Authorization 헤더 사용)
                   → 서버는 받은 토큰이 유효한 토큰인지 검증하여 인증 된 사용자인지 확인
• 엑세스 토큰 : 유효기간이 짧은 토큰, 일반적인 유저의 작업에 사용되는 토큰  
  리프레시 토큰 : 유효기간이 긴 토큰, 엑세스 토큰이 만료 되면 클라이언트가 리프레시 토큰을 사용해 다시 엑세스 토큰을 발급 받아옴 ⇒ 토큰을 발급 받을 때에는 2가지 토큰을 함께 발급하여 사용함  
• JWT : JSON Web Token , JSON 기반으로 만드는 토큰으로 만들고 검증하는 방식이 단순. 
             만들어진 문자열은 [헤더.페이로드.시그니쳐]로 구성되며, 각각은 ".(점)"으로 구분.
              JWT로 만든 토큰은 재변환이 쉽기 때문에 민감한 정보를 담으면 안됨
  • JWT 구성 요소
  • 헤더 : JWT를 사용하기 위한 정보 
  • 페이로드 : 표준 클레임(유저 정보)이 담겨 있음. 민감하지 않은 정보 위주로 구성 필요.
  • 시그니쳐 : 헤더, 페이로드를 기반으로 "비밀키(256비트 이상의 문자열)"를 작성하여 "서명"하는 정보
    JWT 사이트 : https://www.jwt.io/

    

    JWT 예시 (출처: JWT 공식 홈페이지 https://www.jwt.io/ )

 

4) OAuth

• 유저가 특정 서비스(쇼핑몰 등)에 가입 시, 유저가 허용하는 범위 내에서 타 서비스(SNS 계정)에 저장 된 정보를 사용하는 것 
      ex) 일반 웹사이트에 가입 할 때, SNS 계정(카카오, 네이버, 구글 등) 을 사용하여 회원가입 하는 경우
            해당 SNS 로그인 뒤 해당 계정의 접근을 허용 / 특정 DB를 사용 한다는 과정을 거침 ⇒ OAuth 

• 

  OAuth 가입 절차 다이어그램

• OAuth의 특징
  • 사용자가 승인한 정보(프로필, 이메일 등)만 접근 가능하여, 제한된 권한만 줄 수 있음
  • 가입 한 현재 서비스(쇼핑몰 등)는 타 서비스(SNS등)와 다른 "자체 세션/토큰"을 발급하여 사용 
  • Access Token : 현재 서비스에서 타 서비스의 API를 호출 할 때 사용하는 임시 열쇠
• OAuth 2.0 표준 : https://oauth.net/2/

OAuth 2.0 — OAuth

• OIDC (OAuth ID Connect) : 기존의 OAuth는 타 서비스의 정보만 활용한다면 OIDC는 "인증"기능까지 확장,
                                                JWT 페이로드 영역에 ID 토큰까지 받아서 사용

 

---

 

📃 내일은 뭘 배울까 🤔

- 유저 기능 구현