230104 TIL

오늘의 공부

인증, 인가는 Controller 단에서 끝내야 한다

• 인증
  • 식별가능한 정보로 서비스에 등록된 유저의 신원을 입증하는 과정
• 인가
  • 인증된 사용자에 대한 자원 접근 권한 확인
• service에는 business logic만 딱 깔끔하게
  • Controller에서 먼저 확인을 하고 Service으로 이동

세션

• 세션 유지를 위해 → 서버저장 → 로드밸런싱 하게되면 → 다른 서버로 가면 세션 유지 안됨
  • redis, memcached같은 메모리형 db 사용
  • 또는 JWT 사용
• stateful
• 한 기기에서만 로그인 되도록 관리 가능 → 기존 세션 종료

JWT

• stateless
• base64로 디코딩해보면 여러 정보가 담겨있다
• 토큰으로 상태관리하기 때문에 따로 세션을 둘 필요가 없다
• 토큰 탈취 위험
• 구조
  • 1번 헤더
    • 타입
      • jwt
    • alg
      • 3번 서명값을 만드는데 사용될 알고리즘이 지정됨
      • HS256 등…
  • 2번 페이로드
    • 이 토큰을 누가 누구에게 발급했는지, 이 토큰이 언제까지 유효한지
    • 서비스가 사용자에게 이 토큰을 통해 공개하기 원하는 내용
      • 사용자의 닉네임, 서비스 상의 레벨, 관리자여부
      • 이렇게 토큰에 담긴 사용자 정보 등의 데이터를 claim 이라고 한다
  • 3번 서명값
    • 1번 + 2번과 서버에 저장되어있는 비밀 값을 1번의 알고리즘에 넣고 돌리면
    • 서명값이 나온다 → 토큰이 조금이라도 수정되면 싹 다 바뀜
  • 토큰의 서명값과 계산값이 일치하고 토큰 사용기간도 지나지 않았다면 인가를 받는다
• 다중로그인, 보안 문제들 떄문에 JWT ‘만’ 사용하는 곳은 드물다
• 나름대로 보완 방법 : 만료시간을 아주 짧게하는 대신, 로그인 하고나면 토큰을 두 개 준다
  • access 토큰 : 수명이 몇 시간이나 몇 분 이하 → 매번 쓰는 것
  • refresh 토큰 : 수명이 보통 2주 → 서버 db에도 저장해뒀다가
    • access토큰 수명 다되면 클라이언트가 refresh토큰을 보낸다
    • 서버가 db와 대조해보고 맞다면 새 access 토큰 바로 발급
    • access 토큰이 만료될 때 마다 재로그인 필요 없이 새로 발급 가능
    • Refresh Token은 JWT 일수도, 그냥 간단한 문자열 또는 UUID 일수도 있다.
      • JWT 형태의 Refresh Token
        • stateless → 서버 부하 줄어듬
        • 탈취 위험
      • JWT 형태가 아닌 Refresh Token
        • 서버 DB에 저장 필요
        • 강제 로그아웃, 차단 가능
        • 탈취 위험 적음, 탈취 당한 경우 서버에서 직접 무효화 가능
  • 두 토큰을 한번에 만들고, access 토큰은 서버에 저장하지 않고 refresh 토큰만 서버에 저장하고 두 토큰을 클라이언트에 보낸다
    
  • 클라이언트는 이제 요청과 access 토큰을 함께 실어 통신 만료된 access토큰으로 소통하려하면 서버로부터 만료됐다는 답장이 옴 그럼 브라우저단에서 자동으로 두 토큰을 함께 다시 보낸다 서버는 받은 리프레쉬토큰으로 어 이 사람이 맞네 확인하고 access 토큰을 ‘새로 갱신’해서 다시 줌 → 아까 그 access 토큰과는 다른 토큰! refresh 토큰 탈취 위험은 여전히 남아있다
    

https://hudi.blog/refresh-token/

ResponseEntity

• spring framework에서 제공하는 클래스 중 HttpEntity라는 클래스를 상속받아 사용하는 클래스
• 사용자의 HttpRequest에 대한 응답 데이터를 포함
• 사용하는 클래스
  • HttpStatus
  • HttpHeaders
  • HttpBody
• 왜 사용하나?
  • 200 400같은 http status를 좀 더 디테일하게 사용하고자…
• HttpEntity = HttpHeader + HttpBody

@AuthenticationPrincipal

• https://velog.io/@jyleedev/AuthenticationPrincipal-로그인-정보-받아오기
• https://kim-jong-hyun.tistory.com/33
• 읽어보자

postman과 swagger의차이?

• 둘의 공통점은 HTTP/HTTPS에서 실행되는 RESTful API를 설명하고, 요청에 대한 응답을 제공하며, 다양한 프로그래밍 언어에 대해 처리가 가능하다.
• postman은 API를 테스트하기 위한 도구이고, Swagger은 API에 대한 문서를 만들귀 위한 오픈 프레임워크이다.
  • api 문서 자동화
  • 프로젝트에서 지정한 url들을 html 화면으로 확인할 수 있게 해주는 오픈 프레임워크

https://velog.io/@dyjeong/Node.js-Swagger-API-문서화

스프링 시큐리티

• 필요한 필터를 골라서 Filter Chain을 구현하여 사용
  • 스프링 시큐리티에서 제공하는 필터들이 아주 많다

스프링 예외처리

• 통신 장애가 일어나면 Exception 발생
• 크게 2가지 처리방식이 존재한다
  • @ControllerAdvice를 통해 모든 Controller에서 발생할 수 있는 예외 처리
  • @ExceptionHandler를 통해 특정 Controller의 예외 처리
  • 즉, @CntrollerAdvice로 모든 컨트롤러에서 발생할 예외를 정의하고,
    @ExceptionHandler를 통해 발생하는 예외마다 처리할 메소드를 정의
• 그 외 처리방식
  • 메서드 안에서 try-catch
  • global level에서 Controller 이후 Client에게 전달되기 직전에 처리 → 소규모의 경우 간단하게
• IOException, checked exception
• RuntimeException, unchecked exception
• AroundHubException 예외 직접 정의?
• @ControllerAdvice, @RestControllerAdvice
  • 예외들을 한 곳에서 관리하고 처리할 수 있게 하는 어노테이션
  • 특정 컨트롤러만 처리하도록 범위 지정 가능
  • 예외 발생 시 json으로 결과 반환하려면 @RestControllerAdvice 사용하면 됨
• @ExceptionHandler
  • 예외가 발생하면 Handler로 처리하겠다
  • 뒤에 괄호를 붙여서 어떤 Exception.Class를 처리할 지 설정 가능
    • 하위 세부 예외처리가 존재하면 그 핸들러가 우선 처리하게 됨
  • 이 메소드가 어느 클래스에 배치되느냐에 따라서 우선순위를 가지게 된다
    • 전역설정 하려면 @ControllerAdvice 내부 메소드로 정의
    • 지역설정 하려면 각각 Controller 안에 Handler 배치

메모

null