Section3 - Unit7 [Backend] 인증 / 보안

Cookie

: 서버가 일방적으로 클라이언트에 전달하는 4KB이하의 작은 데이터로, 웹 서버와 웹 브라우저간의 연결 정보를 저장 및 제공해, 비효율적이고 반복적인 데이터 요청을 줄이고 생산성을 높힐 수 있음

Cookie 옵션 종류

1. Domain

   포트 및 서브 도메인 정보, 세부 경로를 포함하지 않은 도메인 정보를 담으며, 쿠키의 도메인 정보와 서버의 도메인 정보가 일치할 경우만 쿠키를 전송해 다른 서버에서 받은 쿠키를 잘못 전달하는 경우를 막아줌

2. Path

   서버가 라우팅 시 사용하는 세부경로로, 전달 경로의 상위 경로를 쿠키 Path로 전달시 해당 경로의 하위 경로로 전달할 수 있지만, 동등한 레벨의 경로가 다르게 전달 될 경우 쿠키 전송을 제한함

3. MaxAge or Expires

   쿠키를 유효기간 정보를 가지며, 이를 통해 쿠키 탈취에 대한 보안적인 효과를 기대함
   세션 쿠키: MaxAge, Expires가 할당되지 않았은 쿠키를 의미하며, 브라우저 종료시 쿠키가 사라짐
   영속성 쿠키: MaxAge, Expires가 할당된 쿠키로, 브라우저 종료와 무관하게 해당 할당치 만큼 유효기간을 가짐

4. Secure

   boolean값을 가지며, HTTPS 프로토콜 사용한 요청만 쿠키를 전달하도록하지만 localhost는 예외적으로 http, https 모두 요청이 가능함(개발환경을 위한 예외)

5. HttpOnly

   boolean값을 가지며, 스크립트 접근을 제한해 브라우저로로 접근하도록할 것인지, 스크립트 접근 또한 허용할지를 결정함( xss 공격에 대한 보안 )

6. SameSite

   할당된 값에 따라 Cross-site 요청에 대한 처리를 다르게 결정하며,

   • Lax: Cross-site의 GET 요청만 허용
   • Strict: same-site 요청만 허용(Cross-site 요청 거부)
   • None: Secure = true를 요구하고 만족시 모든 Cross-site 요청 허용

• 이러한 쿠키 옵션 정보는 최초의 서버 -> 클라이언트 쿠키 전송시 Set-Cookie 프로퍼티에 담아 전송됨
• 이후 클라이언트 -> 서버 쿠키 전송시 프로퍼티에 쿠키를 담아 전송함

!! 쿠키를 사용한 장기간 상태 보존은 지양할 것

Session

: Server가 Client에 유일하고 암호화된 ID를 cookie로 부여하는 방식

특징

• 고유한 ID를 클라이언트에 부여하고 클라이언트는 이를 통해 자신이 신뢰할 수 있는 대상임으로 인증함
• cookie를 전달하는데 사용함으로 cookie의 한계이니 xss 취약점을 그대로 계승
• 하나의 서버에서만 상태를 가짐으로 분산 시스템에 분리할 수 있음
• 서버의 메모리를 항상 차지함(비효율)

Token

Hashing

: 보편적으로 사용되는 암호화 방식 중 하나로, 해시 함수를 사용해 암호화하고 복호화는 불가능함, 주로 데이터의 유효성을 확인하기 위해 사용

• 항상 같은 길이의 문자열 리턴
• 동일한 문자열에 대해 동일한 결과를 리턴
• 다른 문자열에 대해 항상 다른 결과를 리턴

솔트

• 문제상황 : 해쉬의 특성상 같은 입력에 대해 같은 결과를 출력하는 데, 해당 입출력 결과가 유출될 경우 피해 심각
• 해결 : salt로 불리는 임의의 값을 해시 데이터에 더해 유출되더라고 위험 부담 감소

Token?

: 사용자 인증정보를 담은 토큰을 클라언트에 제공해 저장관리하는 방식으로 웹 어플리케이션에서 많이 사용됨

• 무상태성: 서버가 유저의 인증상태 관리x -> 서버의 강제적 사용자 상태제어 불가능
• 확장성 : 서버에 인증데이터를 보관하지 않음으로 확장 용이
• 자유로운 위치에서 토큰 생성 가능
• 다양한 인증 정보 관리 부여 가능

JWT

: Json 객체에 정보를 담고 토큰을 통해 암호화하여 전송 하는 기술로, . 기호를 통해 Header, Payload, Signature 3부분으로 나누어짐

• Header
  : 토큰 코딩방식, 시그니쳐 생성 알고리즘등 토큰 자체에 대한 데이터를 인코딩함

• Payload
  : 전달하고자 하는 데이터를 인코딩함

• Signature
  : Header 담겨있는 알고리즘 방식으로 암호화하여 시그니쳐를 생성해 유효성을 검증함

  HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);

Access Token & Refresh Token

• Access Token
  : 서버에 접근하기 위한 인증 권한 정보를 가지는 토큰으로 보안을 위해 24시간 정도의 유효기간을 가짐

• Refresh Token
  : Access Token이 만료되었을 때 새로운 엑세스 토큰을 발급받기 위한 토큰으로 상대적으로 긴 유효기간을 가짐

OAuth

: 인증을 중개해주는 메커니즘으로 다양한 플랫폼에 정보 접근 권한을 부여하는 프로토콜

OAuth 사용이유

: 직접적인 정보 노출을 줄여 보안성 Good, 사용자가 제공할 정보를 선택할 수 있어 보안-제어 Good, 무엇보다 사용자 입장에서는 몇번의 클릭으로 인증과정이 완료됨으로 편함!

OAuth의 주체

• 사용자, Resource Owner
  : 사용자 정보를 직접적인 소유자인 주체

• 사용하고자하는 서비스, Application
  : 사용자의 정보에 접근하고자하는 주체

• 사용중인 서비스,Resource server && Authorization server
  : 사용자의 정보를 서버에 저장하고 있는 주체

OAuth 인증 방식의 종류와 흐름

• Implicit Grant Type
  : 어플이 서버에 인증을 요청하면, 서버에서 토큰을 발급하고 해당 토큰으로 어플을 정보에 접근 가능한 방식으로 특별한 인증과정이 부족해 보안성 약함

• Authorization Code Grant Type
  : Implicit 방식에 인증 요청후 토큰 발급전 인증코드를 전송하고 인증코드를 잘 받았는지 확인하고 엑세스 토큰을 발급하는 방식으로 신뢰성을 보안함

• Refresh Token Grant Type
  : Authorization 방식에서 Access 토큰 발급시 Refresh 토큰 또한 같이 발급해 Access 토큰 만료시 Refresh 토큰을 재발급해주는 기능을 추가한 인증 방식으로 과한 인증 요청 과정을 단축시켜 사용자 경험에 긍정적인 효과를 가져와줌