Notes Spring Security 1

• 로그인이 이루어지는 시점을 다이어그램으로 그려보기 << use ipad
  • “진짜 이게 최선인지”
  • id + password 들어가는 요소 + 흐름은 내부에서 사실 엄청 복잡함
• 세션 기반 인증, 토큰 기반 인증 ⭐
  • 면접 단골
  • 생각하지도 말고 그냥 입에서 튀어나와야함
• OAuth vs OpenID connect
  • Openid connect를 더 많이 씀 (oath 를 확장)

유저 기능의 필요성과 활용

• 어플리케이션에 회원이 생기는거임
• 유저는 정말 많은 곳에 참조가 될것임
  • 잘 설계하지 않으면, 전파될 수 있음

1. 유저 기능의 역할

   • 비회원, 회원
     • 회원 → 개인화
     • 비회원
       • 장바구니 가능하지만 쿠기같은거 써야함
       • 근데 비회원일때도 서비스 사용 대부분이 가능해야하는 제약조건이 많이 있음
   • 맞춤형 서비스
     • netflix, 유튜브
     • 장바구니
       • 장바구니 담은것 < → 실제 결제 전환율 계산 도 가능! 요즘은 데이터를 넓은 범위로 사용됨
     • 은행서비스는 인증이 필수
       • 민감한 정보를 다루기 때문에!

2. 인증 (authentication) 개념

   • 로그인 안에 인증이 포함됨!
   • 인증 → 내가 본인이 맞는지 증명하는 것!
   • 비닐번호
     • 해싱이 필수 → 평문으로 저장하면 잡혀감..ㅋㅋㅋㅋ
     • 해싱의 특징
       • 단방향 암호화
       • 복구가 불가능?!
       • 대표적인 알고리즘
         • SHA-256 (가장 많이 쓰임) → 걍 못품 (근데 양자컴퓨터 오면 maybe? 근데 양자 암호화도 개발되고 있음)
         • 근데 암호화를 거쳐도, 많이 쓰이는 비닐번호는 털릴 수 있음 (해싱 결과는 항상 같기 때문에!)
           • rainbow table?
   • 보안
     • 내 정보가 언제든지 털릴 수 있다는 점
     • 털리면 상대방이 함부르 쓰지 못하게 해야 함

인증 vs 인가

• 인증
  • 본인 확인
• 인가 authorization
  • 너는 여기까지 할 수 있어! 접근 가능한 권한을 확인 + 부여
    • 사용자가 뭘 할 수 있는지 결정하고 부여
  • 항상 인증 이후!!!!
  • header
• 왜 분리?
  • 유지보수 편리
  • 로그인안에 둘다 들어가지만, 인가는 무조건 인증 이후

인증

• 잘못된 비닐번호를 입력했습니다 → 보안에 구멍!!!!
  • ID가 맞다고 유추할 수 있음!!! → ID도 민감한 정보에 포함됨
  • 되게 불편한데, 정보가 노출되지 않기 위해서!
• usercredential
  • 로그인 시도 횟수, 마지막 로그인 시간 등
  • 나눠서 관리 가능! → 어플리케이션 규모가 커졌을때 (msa 등 인증서버를 아예 따로 둘 수 있음)
• 유저 안에 roles
  • 계층형 구조
  • roles 많이 포함 (n개 가질 수 있음! <<< 그냥 외워라)

이매일과 비닐번호

• 불일치하면 실패 횟수를 증가
  • 계정 잠금 → 카톡/매일 등으로 보냄
  • 네이버가 잘되어있음 → 해외로그인: 로그인 성공했지만 실패로 쳐짐!!!
  • id + pw 보통은 1000원도 안함 ㅋ
• 요즘은 아이디보단 이매일/전번 씀
  • 아이디는 까먹기 쉬움
  • 추가적인 인증 가능
  • 남의 매일로 가입 못함 → 이매일 인증 거쳐야함 (인증과정이 좀 더 고도화됨)
• 전번은 유니크 x
  • 전번 교체할 수 있음

인증 워크플로우

• 클라이언트도 검증을 해야함

• 공격

  • 쿼리문으로 공격 가능 (sql injection?)

• 비즈니스 로직인 이유

  • 기능 추가할 수 있음
  • 예를 들면 새로운 회원은 쿠폰 발행할 수 있음

• 위는 보편적인 회원가입 플로우임

• 회원가입을 하면 기본적으로 잠겨있음

  • 회원 상태 - 가입 대기중
  • 최조 회원가입을 하면 이매일 인증을 하야함 → 활성화
  • 비닐번호 재설정 이매일도 전송할 수 있어야 함
  • redis 사용

로그인 워크플로

• session, token 발행해야함
  • http 라서
  • http 특징
    • 무상태성, 비연결성 <<<<<<<<<<<< 바로 나와야함!!!!! 그래서 session, token 발행해야함
• 당연히 로그 남겨야함

stateless

• 다음 요청을 보낼때 로그인 했다는 것을 기억 못함
• 그러면 글을 쓸때 매번 내 이아디 +비번을 써야함
  • 서버에서도 검증하는 기능 more expensive
• 그래서 로그인 됐다는 것을 기억하기 위해서 가장 많이 쓰는게 session, token임 <<<⭐
  1. session
  2. token

비연결성

• keep alive → 여기에 인증정보를 담을 수 없음
  • tcp위에 올라감, 그래서 tcp에서 사용되는 것만 저장. 우리가 원하는 것을 저장할 수 없음
• 분산 인프라
  • 클라이언트, 서버
  • 로드 밸런서
  • 
    • 인증을 거치고 난 후 로드 밸랜서로 감

세션

• 쿠키 클라이언트는 전달받은 1을 가지고 요청을 보냄!

• 세션저장소 → 서버에서 저장!!!

  • 인증 상태는 서버가 들고있음

• 클라이언트는 저 인증상태에 접속할 수 있는 id만 들고있음

  • jsession id, session id → 쿠키에 담겨져 보냄

• 브라우저는 쿠키를 관리함

• chrome dev tools → application →storage → cookies

  • session storage - 창을 닫으면 사라짐

세션 쿠키 필수 옵션 테이블 다 알아야함

• 도메인이 같으면 무조건 담겨져서 나옴
• same site 이해하기 <<<<<
  • same site None??
  • Strict
    • 같은 도메인/사이트에서만 쿠키 사용 가능
  • Lax
    • 기본 값
    • 필요할때는 열려있음
    • Get 요청에서는 쓸 수 있음, post같은 요청은 크로스 사이트를 허용하지 않음
    • 얘를 쓰면 최소한의 보안정치를 사용할수있음
• document.cookie
  • 콘솔창에 치면 쿠키 값 접근가능
  • 근데 js 콘솔에서는 민감한거는 담지 않음!!
  • 변경 못하는거는 http only 속성을 적용해야함<<<

서버에서 상태를 유지하는 것 자체가 단점

• scale up - 성능 up
• scale out - 서버 늘리기

글로벌 세션 저장소

• 이렇게 하면 모든 트래픽이 중앙으로 몰림
• 따로 관리하면, 반대로 다른 서버 세션들에 동기화 문제가 있음
• 스키티 세션 ⭐(알아야함)
  • 분산된 처리에서 내 인증정보가 저장된 서버로만 요청 가능하게 고정 할 수 있음!!!!
  • 근데 문제점: 1번 서버가 꽉 찼을 때

토큰

• http header로 전송

  • authorization header로 담아서 보냄 → 인증정보가 담긴 헤더다!
    • 인증정보를 서버로 전달하기 위해서 보냄!
  • 여기에 있는 토큰으로 인증
  • 데이터를 토큰으로 변환하고 보내는거임

• 민감한 정보 안담음!!!!!!!!!!!!!!!

  • 유저 정보, 권한 등만 담음

• 나중에 더 자세히 볼꺼임

• 토큰 → 평문 알고리즘 있음 (서버에 있음)

  • 복구화를 거쳐서 인증정보를 사용하는거임
    • 그냥 메서드임
  • 토근에 인증정보가있음
  • 매 요청이 어느 서버로 가든 복구화가 가능! 그냥 메서드만 호출하면 되니까!

• 토큰이 탈취될때 문제

  • 세션은 탈취되면 그냥 세션을 지우면 됨
  • 하지만 토큰은 무효화될 수 없음 - 만료기간을 맘대로 바꿀 수 없음 (불변이라고 생각)
  • 차이점 이해하기

• 세션보다 좀 더 까다로움

  • 로그아웃이 좀 까다로움 → 토큰 관리 저장소 따로 관리 (redis)
    • 토큰이 유효한지 보관할 수 있어야함

• 두가지로분류

  • access
    • 인증정보 담음
      • 유저 아이디, 등
    • 만료기간있음
  • refresh
    • access token을 재발급하기 위한 정보만 담겨있음
    • 탈취되더라도, 탈취한 사용자는 짧은 시간만 사용할 수 있음
    • 브라우저에는 refresh token만 저장하는 경우가 많음
  • 두개 같이 털리면? 그냥 해킹당하는거임
    • 그래서 refresh token 1회용으로
  • 보안
    • access 만들떄 refresh도 만듬 (같이 재발급)
    • refresh는 한번 재발급하면 기존거는 못씀
    • 폐기된 refresh 토큰을 누가 사용하는거면 누가 탈취한거임 → 이때 그냥 다 잠그고 사용자가 본인인증을 하고 다시 받게 할수도있음

• 클라이언트에 저장

• 만료기간 설정

• https 사용

  • 당연히 secure사용

• 저장위치주의

• 세션 vs 토큰 비교 테이블 외우기 ⭐

이것도 외워라…

• in memory db - redis
  • fast
  • 지원하는 자료형태가 엄청 많음
  • no sql 안에 들어감 (굳이 분류하자면)
  • 캐싱

토큰 기반 인증

토큰 상태를 저장하는 서버 따로 둘 수 있음음

쿠키

• 데이터의 작은 조각
• 쿠키의 구필수적으로 외워야하는것들
  • domain
  • path
  • secure
  • httponly
  • samesite
• 어디서 만드냐
  • 서버에서 보통 만듬 (클라이언트도 만들수있긴함)
  • set cookie header에 담아서 전송
  • 그러면 클라이언트가 쿠키 저장소에 보관
• 종류
  • 세션 쿠키
  • 영속 쿠키
• spring
  • srting으로 저장, cookie data type 둘다 사용 가능

세션

• 클라이언트는 세션 아이디만 들고있음
• 쿠키로 전달
• set cookie
  • 서버에서 생성
  • response
• cookie
  • 브라우저에서 서버에게 요청을
  • request
• secure 보장은 필수임!!!

httpOnly

• 이 공격은 요즘 많이 없어지긴 함

• 만약에 이런 스크립트 공격이 통하면 그냥 망한거임

  • 그정도로 너무 옛날 공격임

• script 자체는 실행되는데 쿠키만 접근 못하는거임

• SPA

  • SEO 안됨 <<< 면접 단골질문
  • 동적으로 화면 일부만 렌더링!!!!!!!!!! UX 좋음, but SEO는 떨어짐
    • 단점을 극복하기 위해서 next.js

CSRF 공격

• 중간에서 탈취
• 막기 위해 samesite 옵션
  • 하지만 완벽하진 않음

기본 인증

• 요즘 안씀

• base 64

  • 크기는 늘어남

• 인코딩, 암호화에는 차이가 있음

  • 인코딩 - 데이터를 편리하게 전송하게 위해서

• base64 url

  • url 인코딩?
  • 특수문자는 문제가 생김 (쿼리파라미터와 겹침)
    • 그래서 다른걸로 변환시킴!

403

• 인증을 됐으나 리소스 접근 못함

대칭키 암호화 방식, 비대칭키 htttps/http 이거 면접떄알아야함…ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ handshake tcp 통신

JWT

• 토큰
• json 형태의 웹에서 사용하는 토큰
• payload에 절대 민감한 정보 담으면 안됨

• 이거 창에 띄워두고 내일 수업 듣기…!!! <<<<<<<<

• 권한을 빼는건 전파가 됨

  • 필요한 최소한의 권한만 부여

role + policy 같이 무조건 적용해야함

flow

---

• in urls
  • port is 80 by default

CORS는 면접 단골 질문 ㅠㅠ

• CORS는 왜 써야 하나요?

http

• 무상태성
• 비연결성

세션/토큰 혼합은 피라…

---

• Authorization Code Grant
  • 서버 ←> 서버 소통도 가능해야함
  • 보편적으로 가장 많이 쓰림

• spring security는 저 1번에 작동함!
  • dispatcherservelet 도달 전에
  • 이건 외워야함 ㅋㅋ
  • 이걸 담당하는건 실제로 톰캣임 (servlet container)! principal, credential 외우기

---

• 세션

  • 문제점
    • 확장이 어렵다.
    • 1. 그래서 글로벌 세션 (인증 서버)를 따로 만들 수 있지만, 그러면 부하가 다 거기로 몰림
    • 2. sticky session - 로그인한 서버를 앞으로 요청에 올때 그 서버로만 가게끔 고정시키는거!
  • 서버에 보관
  • 카드

• 토큰

  • 클라이언트에서 보관 (주최가 가장 큰 차이점!)
  • 상대적으로 세션보다 인증정보 탈취에 취약함
    • JWT 특성상 암호화되진 아놓고 인코딩됨 (base 64url)
  • JWT
    • 민감한 정보 담으면 안됨
    • signature: 복구화가 거의 불가능한 단반향 암호화
    • 구조는 걍 외워야함!!
  • 만료 시간 꼭
  • 만원짜리 떨어뜨리는것
    • ㅋㅋ 그래서

• http

  • 비대칭키 대칭키 둘다?

3 tier architecture

spa?

• 요즘에 다 적용되어있음

react

• framework가 아니라…라이브러리다…ㅋ
• 다른 프레임워크랑 같이 사용할 수도 있음!

jwt

• 사실 토큰이라는건 아주 많지만 그냥 jwt가 가장 많이 쓰이는거임

• payload가 아무리 늘어나도 signature는 안늘어난다! (길이가 고정됨)

• 대칭키, 비대칭키