인증 & 인가, 로깅

인증(Authentication) : 제대로 된 사용자인지 확인하는 과정
인가(Authorization) : 해당 요청에 대해 허가된 접근인지 확인하는 과정

<인증>

인증 방식 | 👨🏻‍💻 Tech Interview

---

인증 방식

• API Key
• OAuth2.0
• JWT(토큰 기반 인증)
  • 정보가 서버에 저장되지 않기 때문에 서버 메모리 부담이나 멀티 디바이스 환경에 대한 부담이 없음
  • 상대적으로 손상의 위험이 있고, XSS 공격에 취약해 가능한 민감 정보는 포함시키지 않을 필요가 있음
• 세션 기반 인증
  • 서버측에서 관리하기 때문에 클라이언트 변조로부터 상대적으로 안정적
  • 서버 메모리를 활용하기 때문에 서버에 부담이 될 수 있다는 점과 멀티 디바이스 환경에서 로그인 시 신경써줘야할 부분들이 생김

 

OAuth_인증

• OAuth란?
  • Open Authentification 의 약자로, 비밀번호를 따로 제공하지 않아도 다른 웹사이트의 자신의 정보를 타 애플리케이션으로 접근할 수 있게 하는 개방형 표준 방법

 

• 토큰 종류?
  • 비밀번호 대신에 토큰을 활용해서 인증 절차를 진행하는데, Access Token과 Refresh Token이 있고, 엑세스 토큰이 만료되면 리프레시 토큰으로 재발행이 가능한 구조

 

• 관련 용어
  • 사용자 : 계정을 가지고 있는 개인 (ex. 카카오톡 계정 사용자)
  • 소비자 : OAuth를 사용해 서비스 제공자에게 접근하는 애플리케이션 (ex. 카카오톡 계정을 사용하려는 타 앱)
  • 서비스 제공자 : OAuth를 통해 접근을 지원하는 웹 애플리케이션 (ex. 카카오톡)
  • 소비자 비밀번호 : 서비스 제공자에서 소비자가 자신임을 인증하기 위한 키
  • 요청 토큰 : 소비자가 사용자에게 접근권한을 인증받기 위해 필요한 정보가 담겨있음
  • 접근 토큰 : 인증 후에 사용자가 서비스 제공자가 아닌 소비자를 통해 보호 자원에 접근하기 위한 키

 

• OAuth 와 OAuth2 차이
  • OAuth1.0
    • 데스크톱, 웹 브라우저에 가장 적합함 => 네이티브 데스크톱 및 모바일 애플리케이션에 적합한 사용환경을 제공하지 못함
    • 인증에 너무 많은 단계의 공유 스토리지와 임시 자격 증명을 필요로 하며, 데이터 센터 전반에 걸쳐 동기화하기 까다로운 경우가 많음
    • OAuth1.0은 API 서버가 응용 프로그램의 ID와 비밀번호에 접근할 수 있도록 요구함. 대부분의 경우 인증 서버와 API 서버가 완전히 분리된 대형 공급 업체의 아키텍처를 파괴함
  • OAuth2.0.
    • 네이티브 애플리케이션에 대한 더 나은 사용자 환경 지원, 프로토콜 확장하여 미래 장치 요구사항과의 호환성 제공
    • 사용자 인증 및 API 호출을 수신하는 역할을 지원하여 확장성을 필요로 하는 더 큰 공급 업체는 이러한 확장성을 구현할 수 있으며, 더 작은 공급 업체는 원하는 경우 두 역할 모두에 동일한 서버를 사용할 수 있

 

• 프로토콜의 흐름

OAuth 동작 흐름

 

JWT_인증

• 구성
  • aaa.bbb.ccc => 헤더(header) + 내용(payload) + 서명(signature)
  • 헤더 : typ 토큰의 타입(JWT) + alg 해싱 알고리즘(HMAC, SHA256, RSA)
  • 내용 : 토큰에 담을 정보(정보의 한 조각을 클레임(claim)이라 부르고 name/value 쌍으로 이루어져 있음. 여러개를 담을 수 있지만 너무 많으면 토큰이 길어질 수 있음)
  • 서명 : 헤더의 인코딩값과 정보의 인코딩값을 합친 후 주어진 비밀키(salt)로 해쉬를 하여 생성함. 이렇게 만든 해쉬를 base64 형태로 나타내게 됨

클레임의 종류
- 등록된 클레임 : 토큰에 대한 정보들을 담기 위하여 이름이 이미 정해진 클레임(서비스에서 필요한 정보들이 X)
- 공개 클레임 : 충돌이 방지된 이름을 가지고 있어야 하기 때문에 이름을 URI 형식으로 지음
- 비공개 클레임 : 보통 클라이언트와 서버간의 합의 하에 사용되는 클레임 이름

• 프로토콜 흐름

JWT 동작 흐름

 

로깅 레벨(Logging Level)

• 로그가 필요한 이유?
  • 서비스 동작 상태를 파악
  • 장애 파악 & 알림
• 종류
  • DEBUG : 개발자가 기록할 가치가 있는 정보
  • INFO : 중요한 비즈니스 프로세스의 시작, 종료 시점을 알려주는 로그 (ex. `~가 ~를 실행했음`)
  • WARN : 주의해야 하지만, 프로세스는 계속 진행되는 상태
    • ex. SpringScheduling 동작 시 Redis와의 연결이 끊긴 경우
  • ERROR : 프로그램 동작에 큰 문제가 발생한 상태
    • ex. DB 오류 등
• Log4j와같은 로깅 라이브러리를 따로 활용하는 이유?
  • Log4j : 로깅 라이브러리
  • 로그 작성 인터페이스를 추상화한다는 점과 로그 출력 방식에 대한 확장성을 지원한다는 장점
  • Appender에 대한 설정만으로 다양한 로그 저장소(파일, Sentry, ElasticSearch 등) 에 저장할 수 있음