모의면접 예상 질문 (이력서 기반)

OAuth 2.0

• OAuth 2.0을 사용한다면 대부분의 로그인, 개인정보 관리 책임을 서드파티 애플리케이션 (Google, Facebook, Kakao 등)에게 위임할 수 있다. (단, 사용자가 기존에 서드파티 서비스에 회원가입이 되어있어야 함) 뿐만아니라 각 서드파티가 가지고 있는 사용자의 리소스를 조회 등을 내 애플리케이션에서 수행할 수 있다.

---

• Resource Owner : 리소스의 권한을 가진 사용자. 사용자 혹은 유저(User)라고도 한다. ex) 나몰닭 유저
• Client : 리소스 서버에 접근을 요청하는 어플리케이션 혹은 웹 사이트. 즉, 서비스를 제공자이며 Third Party Application 라고도 한다. ex) 나몰닭이 여기에 해당
• Authorization Server : 액세스 토큰(Access Token)을 클라이언트에게 발급해주는 서버. 인가의 주체. ex) 카카오톡, 구글, 네이버 등
• Resource Server : Authorization Server가 발급한 액세스 토큰(Access Token)을 확인하고 리소스를 제공. API 서버. ex) 이름, 나이 등 아이디 관련 정보(리소스)를 제공하는 서버. 카카오톡, 구글, 페이스북, Github 등

---

· Authorization Code Grant Type

•   클라이언트가 사용자 대신 특정 리소스에 접근을 요청할 때 사용된다. 클라이언트는 Access Token을 발급 받기 전, 인가코드(Authorization Code)를 사용자에 의해 받게 되고, 그 인가코드(Authorization Code)를 가지고 인가 서버(Authorization Server)에 요청을 보내면 리소스에 대한 Access Token을 발급 받을 수 있다.

 

Redis Refresh Token 

• JWT는 발급한 후 삭제가 불가능하기 때문에, 접근에 관여하는 토큰에 유효시간을 부여하는 식으로 탈취 문제에 대해 대응을 하여야 한다.
• 이처럼 토큰 유효기간을 짧게하면 토큰 남용을 방지하는 것이 해결책이 될 수 있지만, 유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편하다는 단점이 있다. 그렇다고 무턱대고 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 된다.
• 이때 “그러면 유효기간을 짧게 하면서  좋은 방법이 있지는 않을까?”라는 질문의 답이 바로 Refresh Token이다. 이름이 다르지만 형태 자체는 Refresh Token은 Access Token과 똑같은 JWT다.
• 단지 Access Token은 접근에 관여하는 토큰이고, Refresh Token은 재발급에 관여하는 토큰 이므로 행하는 역할이 다르다고 보면 된다.

Redis 사용 이유

1) In Memory DB의 장점인 빠른 액세스 속도로 사용자 로그인시 (리프레시 토큰 발급시) 병목이 되지 않는다.

2) Refresh Token은 발급된 후 일정 시간 이후 만료되어야 한다. Refresh Token을 RDB인 MySQL에 저장하면, 스케줄러 등을 사용하여 주기적으로 만료된 토큰을 만료 처리하거나 제거해야한다. 하지만, 레디스는 기본적으로 데이터의 유효기간(time to live)을 지정할 수 있어서 보다 쉽게 구현이 가능하다.

 

AWS S3 이미지 업로드

• putObject 메소드를 이용하여 지정된 버켓에 파일이름과 이미지파일을 저장해주고
• return값으로 이미지 url을 String 타입으로 반환하다.
• S3에 저장될 파일이름을 fileName 에 담아준다.
• 다음, 이미지 파일과 파일 이름을 아래 putS3 메소드를 이용하여 S3에 업로드해준다.
• 다음 아아래에 있는 removeNewFile 메소드를 이용해 로컬에 저장된 이미지파일을 삭제한다.
• 1개 이상의 이미지가 담겨있는 multipartFileList를 for문을 돌려 이미지가 있을 시 convert 메소드를 통해 파일을 전환시켜 준다.
• 그리고, new ImagFile 안에서 아래의 upload 메소드를 사용해 이미지 파일과, 폴더명, 유저 정보, 룸 정보를 담아준다. 
• 다음 imageFileRepository에 저장한다.

 

Enum

• Enum이란 enumerated type의 줄임말로 열거형이라고 불리며 서로 연관된 상수들의 집합을 의미한다.
• 흔히 상수를 정의할 때 final static string 과 같은 방식으로 상수를 정의한다. 하지만 이렇게 상수를 정의해서 코딩하는 경우 다양한 문제가 발생하는데, 이러한 문제점들을 보완하기 위해 자바 1.5버전부터 새롭게 추가된 것이 바로 "Enum" 이다.
• 코드가 단순해지며, 가독성이 좋다.
• 인스턴스 생성과 상속을 방지하여 상수값의 타입안정성이 보장된다.
• enum class를 사용해 새로운 상수들의 타입을 정의함으로 정의한 타입이외의 타입을 가진 데이터값을 컴파일시 체크한다.
• Enum을 사용하는데 있어 가장 큰 허들은 "변경이 어렵다"란 점
• 코드를 추가하거나 변경해야 하는 일이 빈번하다면, 매번 Enum 코드를 변경하고 배포하는것보다 관리자 페이지에서 관리자가 직접 변경하는 것이 훨씬 편리할 수 있다.
• 위와 같은 경우 테이블로 관리함으로써 얻는 장점이 정적언어를 활용함으로써 얻는 장점을 버릴정도로 더 큰지 고민해봐야 한다.

 

비관적 락

• 자원 요청에 따른 동시성문제가 발생할것이라고 예상하고 락을 걸어버리는 방법론
• 트랜잭션의 충돌이 발생한다고 가정 = 사용자들이 같은 데이터를 동시에 수정 할 것이라고 가정
• 하나의 트랜잭션이 자원에 접근시 락을 걸고, 다른 트랜잭션이 접근하지 못하게 하는 방식 = 한사용자가 데이터를 읽는 시점에 Lock을 걸고 조회 또는 갱신 처리가 완료될 때 까지 유지

장점

• 충돌이 자주 발생하는 환경에 대해서는 롤백의 횟수를 줄일 수 있으므로 성능에서 유리
• 데이터 무결성을 보장하는 수준이 매우 높다.

단점

• 데이터 자체에 락을 걸어버리므로 동시성이 떨어져 성능 손해를 많이 보게 된다. 특히 읽기가 많이 이루어지는 데이터베이스의 경우에는 손해가 더 두드러짐.
• 첫번째 사용자가 트랜잭션을 완료하기 전까지 다른 사용자들이 데이터를 수정할수 없기때문에 제어를 잘못하면 동시성을 저해 받게 된다.
• 서로 자원이 필요한 경우에, 락이 걸려있으므로 데드락이 일어날 가능성이 있다.

 

낙관적 락 

• 자원에 락을 걸어서 선점하지말고, 동시성 문제가 발생하면 그때 가서 처리 하자는 방법론 
• 낙관적 동시성 제어는 사용자들이 동시에 데이터를 수정하지 않을 것이라고 가정한다. = 트랜잭션의 충돌이 발생하지 않을것이라고 기대
• 일단 충돌이 나는것을 막지 않고, 충돌이 난것을 감지하면 그때 처리

장점

• 충돌이 안난다는 가정하에, 동시 요청에 대해서 처리 성능이 좋다.

단점

• 잦은 충돌이 일어나는경우 롤백처리에 대한 비용이 많이 들어 오히려 성능에서 손해를 볼 수 있다.
• 롤백 처리를 구현하는게 복잡할 수 있다.

• 비관적락 은 데이터의 무결성이 중요하고, 충돌이 많이 발생하여 잦은 롤백으로 인한 효율성 문제가 발생하는것이 예상되는 시나리오에서좋다.
• 비관적 동시성 제어는 동시성이 저하 되지만 데이터를 일일이 검사하지 않아도 된다. 만약 데이터 정합성이 중요한 업무(금융) 라면 비관적 동시성 제어로 동시성이 저하 되더라도 for update 문으로 예외처리를 하여 오히여 동시성을 높이면서 좋은 데이터 정합성을 가질 수 있다.
• 낙관적락 은 실제로 데이터 충돌이 자주 일어나지 않을것이라고 예상되는 시나리오에서 좋다.
• 낙관적 동시성 제어는 크게 경합이 벌어지지 않는 업무 ( 쇼핑몰) 등에서 사용하고, Lock이 짧아져 동시성을 높이는것이 좋다.
  하지만 상품 조회시점과 결제 시점에 가격이 다를 수 있으므로 반드시 데이터 수정시 일관성 검사를 거쳐야만 한다.

 

Spring Security

• 인증(Authentication) : 해당 사용자가 본인인지 확인하는 절차
• 인가(Authorization) : 인증된 사용자가 요청한 자원에 접근 가능한지 결정하는 절차
• 접근 주체(Principal) : 보호받는 Resource에 접근하는 대상
• 비밀번호(Credential) : Resource에 접근하는 대상의 비밀번호
• 권한 : 인증된 주체가 어플리케이션의 동작을 수행할 수 있도록 허락되어 있는지 결정
  • 인증 과정을 통해 주체가 증명된 이후 권한을 부여할 수 있다.
  • 권한 부여에 두 가지 영역이 존재하는데 웹 요청 권한과 메서드 호출 및 도메아ㅣㄴ 인스턴스에 대한 접근 권한 부여가 있다.

Spring Security는 기본적으로 인증 절차를 거친 후 인가 절차를 진행하게 되며, 인가 과정에서 해당 리소스에 대한 접근 권한이 있는지를 확인한다. 이러한 인증과 인가를 위해 Principal을 아이디로, Credential을 비밀번호로 사용하는 인증 방식을 사용한다.
spring security 에서는 기본적으로 세션 - 쿠키 방식을 사용하고 있다.

일반적인 Form Login 절차

1. 요청 수신

• 사용자가 form을 통해 로그인 정보가 담긴 Request를 보낸다.

1. 토큰 생성

• AuthenticationFilter가 요청을 받아서 UsernamePasswordAuthenticationToken토큰(인증용 객체)을 생성
• UsernamePasswordAuthenticationToken은 해당 요청을 처리할 수 있는 Provider을 찾는데 사용

1. AuthenticationFilter로 부터 인증용 객체를 전달 받는다.

• Authentication Manager에게 처리 위임
• Authentication Manager는 List형태로 Provider들을 갖고 있다.

1. Token을 처리할 수 있는 Authentication Provider 선택

• 실제 인증을 할 AuthenticationProvider에게 인증용 객체를 다시 전달한다.

1. 인증 절차

• 인증 절차가 시작되면 AuthenticationProvider 인터페이스가 실행되고 DB에 있는 사용자의 정보와 화면에서 입력한 로그인 정보를 비교

1. UserDetailsService의 loadUserByUsername메소드 수행

• AuthenticationProvider 인터페이스에서는 authenticate() 메소드를 오버라이딩 하게 되는데 이 메소드의 파라미터인 인증용 객체로 화면에서 입력한 로그인 정보를 가져올 수 있다.

1. AuthenticationProvider 인터페이스에서 DB에 있는 사용자의 정보를 가져오려면, UserDetailsService 인터페이스를 사용한다.
2. UserDetailsService 인터페이스는 화면에서 입력한 사용자의 username으로 loadUserByUsername() 메소드를 호출하여 DB에 있는 사용자의 정보를 UserDetails 형으로 가져온다. 만약 사용자가 존재하지 않으면 예외를 던진다. 이렇게 DB에서 가져온 이용자의 정보와 화면에서 입력한 로그인 정보를 비교하게 되고, 일치하면 Authentication 참조를 리턴하고, 일치 하지 않으면 예외를 던진다.
3. 인증이 완료되면 사용자 정보를 가진 Authentication 객체를 SecurityContextHolder에 담은 이후 AuthenticationSuccessHandle를 실행한다.(실패시 AuthenticationFailureHandler를 실행한다.)

 

JWT

• JWT(JSON Web Token)란 인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미한다.
• JWT(Json Web Token)란 Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token이다. JWT는 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달한다. 
• JWT는 Header, Payload, Signature의 3 부분으로 이루어지며, Json 형태인 각 부분은 Base64Url로 인코딩 되어 표현된다. 또한 각각의 부분을 이어 주기 위해 . 구분자를 사용하여 구분한다. 추가로 Base64Url는 암호화된 문자열이 아니고, 같은 문자열에 대해 항상 같은 인코딩 문자열을 반환한다.

 

단점 

• Self-contained: 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다. 
• 토큰 길이: 토큰의 페이로드(Payload)에 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다. 
• Payload 인코딩: 페이로드(Payload) 자체는 암호화 된 것이 아니라, BASE64Url로 인코딩 된 것이다. 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, JWE로 암호화하거나 Payload에 중요 데이터를 넣지 않아야 한다. 
• Stateless: JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능하다. 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 한다. 
• Store Token: 토큰은 클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 한다.

 

[서버 기반 vs 토큰 기반]

서버(세션) 기반 인증 시스템
서버의 세션을 사용해 사용자 인증을 하는 방법으로 서버측(서버 램 or 데이터베이스)에서 사용자의 인증정보를 관리하는 것을 의미한다.
그러다 보니, 클라이언트로부터 요청을 받으면 클라이언트의 상태를 계속에서 유지해놓고 사용한다.
(Stateful) 이는 사용자가 증가함에 따라 성능의 문제를 일으킬 수 있으며 확장성이 어렵다는 단점을 지닌다.

토큰 기반 인증 시스템
이러한 단점을 극복하기 위해서 "토큰 기반 인증 시스템"이 나타났다.
인증받은 사용자에게 토큰을 발급하고, 로그인이 필요한 작업일 경우 헤더에 토큰을 함께 보내 인증받은 사용자인지 확인한다.
이는 서버 기반 인증 시스템과 달리 상태를 유지하지 않으므로 Stateless 한 특징을 가지고 있다.

 

 

RESTful 한 API 란?

 

RESTful API(=REST API)란, REST한 방식으로 클라이언트와 서버간 상호 데이터 교환을 하는 API이며, 서로간에 stateless한 특징을 가지는 API입니다. -> HTTP를 잘사용하기위해, URI와 HTTP메소드를 사용해서, URL로 어떤 자원에 접근할 것인지, 메소드로 어떤 행위를 할것인지 표현하여 설계된 API를 말합니다.

 

 

또한 API가 RESTful로 간주되기 위해서는 몇가지 조건이 있는데 그 중 가장 중요한 건,

• 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음
• Stateless(무상태)입니다.

 

클라이언트와 서버간 종속적이지 않다는 말입니다.

즉, 서버는 클라이언트의 정보를 저장-유지하고 있지않아, 같은 사람이보낸 정보도, 같은사람이 보냈는지 정보를 유지하고있지 않다는 말입니다.

 

이말은 즉, 클라이언트가 요청시 마다, 자기 정보를 보내야하고, 서버는 받은 정보로 클라이언트의 정보를 확인합니다.

 

따라서,  

• 멀티플랫폼 지원이 용이하고,
• Stateless한 RESTful API는 Client의 요청(호출)을 어느 Server라도 동일하게 처리할 수 있고
• 즉, 어떤 Server라도 Client들의 요청에 응답할 수 있다는 것은, 서버 환경이 분산되었든 아니든, Client쪽에서는 Server쪽에 신경 쓸 필요 없이 API 호출만 하면 원하는 결과를 받을 수 있다는 점에서 RESTful API가 활용되는 것입니다.