2021 06 23 Web전반
2021-06-22 Web 전반¶
REST API¶
- REST API가 뭔가요? - REST API를 통해 웹의 장점을 최대한 활용할 수 있는 설계로, - URL을 통해 자원의 위치를 표현하고, - HTTP Method를 통해 행위를 표현합니다.
- REST API를 통해 구축하면 무슨 장점이 있죠? - REST API를 사용함으로써, 1. REST API의 메시지만 보고도 뜻을 명확히 알 수 있다. 2. HTTP 프로토콜 서비스라는 기본적인 요구만 충족되면 다양한 플랫폼에서 원하는 서비스를 쉽고 빠르게 개발/배포 가능
- REST API를 사용하면서 단점을 느껴본 적이 있나요? - REST API를 사용하면 HTTP 메서드만으로 자원의 행위를 정의합니다. - 그에 따라 GET, POST, PUT, DELETE 만으로 완벽하게 행위를 표현하지 못하는 경우도 있었음 - 가령 체스미션에서 새로운 게임을 덮어써 생성하도록 함을 REST 하게 표현하기 어려웠음 - POST: /games/new - 또한 완벽한 표준이라고 정해진 것이 없어 기준을 가지고 얘기할 수가 없었음
Session¶
- Session이 왜 필요한가요? - HTTP는 무상태성 프로토콜로써, 클라이언트~서버의 관계를 유지하지 않음 - 이를 통해 확장성엔 유리했지만, 상태를 가져야하는 경우 이를 표현함에 불편함이 있었음 - 한번 로그인에 성공한 사용자에 대해 인가 권한을 부여하는 방식중에 하나로, 인가된 사용자에게 SessionID를 발급해주고, 이를 서버측에 저장하여 사용자의 신원을 확인함
- Session이 뭔가요? - Session을 통해 인가된 사용자의 정보를 서버 측에 저장해 둘 수 있습니다.
- Session을 사용하는 과정을 이야기해 주세요 1. Client가 Request를 보냄 2. SessionID가 Server 저장소에 존재하지 않으면, Session과 SessionID를 생성 및 저장하고, Cookie에 SessionID를 담아 Response로 돌려줌 3. Client가 Request를 전송할 때 SessionID를 Cookie에 담아 보내고, Server는 저장소에서 SessionID로 Session을 찾아 인가과정 진행
- Session은 언제 만료되나요? - 다음과 같이 Session의 만료기간을 시간으로 설정해줄수 있고, 로그아웃을 사용자가 누르면 session을 파기할 수도 있음
- Cookie와 Session의 차이는 뭔가요? - 참고: https://woowacourse.github.io/javable/post/2021-05-22-cookie-session-jwt/ - Cookie는 어떤 사이트를 방문했을 시, 해당 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일 - 서버는 클라이언트의 로그인 요청에 대한 응답 작성할 때, 클라이언트 측에 저장하고픈 정보를 set-cookie에 담음 - 이후 클라이언트는 요청 보낼 때 마다, 매번 저장된 쿠키를 요청 헤더의 cookie에 담아 보냄 - 하지만 쿠키는 인가에 값 자체를 그대로를 노출시키고 있기 떄문에 보안에 취약함 - 정말 민감하지 않은 정보들 (가령 오늘 하루동안 뭐시꺵이 안보기) 이럴 때 cookie를 통해 구현하면 좋을듯 - 개인 정보를 그대로 노출시키는 것은 위험하기에 Session 기반 인증의 도입 - 로그인이 완료된 후 SESSIONID를 발급해 이를 set-cookie로 값을 담아 클라이언트에 보냄 - 클라이언트는 SESSIONID를 cookie에 담아 보냄 - 서버에서 SESSIONID를 사용자마다 저장해야 되기에 부하가 큼
JWT¶
- JWT가 뭔가요? - JSON WEB TOKEN으로써, 인증에 필요한 정보들을 담아 이를 암호화 시킨 토큰입니다. - JWT 토큰을 HTTP 헤더에 실어 서버가 클라이언트를 식별함 - Authorization: TYPE(BEARER) ACCESS-TOKEN(dsl23hsd89fs)
- JWT의 페이로드에는 무엇을 넣어둘까요? - header와 payload는 BASE64 인코딩만 진행하기 때문에 탈취되었을 경우 쉽게 해독이 가능 - 따라서 민감한 사용자 정보는 넣으면 안됨 - 하지만 사용자의 정보를 토큰이 자체적으로 담고 있는게 장점이기에, 너무 사용자를 식별할 수 없는 정보면 안됨 - 사람들과 함께 의논하여 결정해야 할 듯하다
- JWT의 장점은 무엇인가요? - JWT는 인증을 위한 별도 저장소 필요 없음 - 토큰의 유효성을 토큰 자체가 가지고 있음 - 서버를 무상태로 유지할 수 있음
- JWT과 Session 중 어느 서비스에 어떤 것을 쓸 것인가요? - 서버를 무상태로 유지할 수 있다는 것은 유지보수 및 확장에 유리하다고 생각 - 탈취되어도 덜 민감한 정보로 이루어진 JWT면 가장 좋을 듯
CORS¶
- CORS가 뭔가요? - Cross Origin Resource Sharing의 약자로, - 서로 다른 도메인의 리소스 요청을 보내기 위해서는 프론트와 서버에서 특정한 작업해야함 - 프론트: Request Header에 CORS 옵션을 넣어줌 - 서버: Response Header에 해당하는 프론트의 요청을 허용한다는 내용
- 다른 출처에서의 HTTP 요청 과정을 설명해주세요 - HTTP 헤더에 Content-type 요청이 추가되면 preflight라는 실제 요청이 안전한지 확인하는 요청이 보내지게 됩니다. - preflight 요청은 OPTIONS 요청을 보내 응답을 받게 되며, 다음을 설정합니다. - 어떠한 클라이언트에게 CORS를 허락해줬는지 - 어떠한 메서드를 통해 서버의 자원에 접근할 수 있는지 - preflight 요청을 통해 보내고자 하는 HTTP Method가 허락됨을 알았다면 해당 요청을 서버에 전송합니다. - 이때 Client는 Origin에 자신의 도메인 정보를 담고, - 서버는 Allow-Origin에 담습니다.
- CORS 에러를 방지하고자 어떤 방법으로 서비스를 구현했나요? - 총 두가지 방법을 사용해봤습니다. - Controller에 어노테이션 사용하기 - WebMvcConfigurer을 구현한 WebConfig를 정의하여 addCorsMapping에 CORS 설정을 등록해주기
https¶
- https가 뭔가요? - https란 ssl 보안 프로토콜 위에서 동작하는 http 입니다.
- ssl은 뭔가요? - ssl은 인터넷 상에서 데이터를 안전하게 전송하기 위한 암호화 통신 프로토콜 입니다. - 응용 계층과 전송 계층 사이에서 동작하는 독립적인 프로토콜으로, - http의 경우 전송계층으로 캡슐화 되기 이전에 SSL 프로토콜에 의해 사용자의 데이터가 암호화 되게 됩니다.
- 간략한 https 설명 가능한가요? - https는 대칭키와 비대칭키를 혼용합니다. - 서버와 클라이언트는 각각 더미데이터를 만들어 서로에게 전송합니다. - 서버는 CA의 개인키로 암호화된 SSL 인증서를 발급받아 클라이언트에게 전송 - 클라이언트는 서버로 부터 이를 받아 CA의 공개키로 이를 복호화 - 복호화한 해당 인증서에는 서버의 공개키가 있음 - 이제 클라이언트가 둘 다 가진 더미데이터로 대칭키를 만들어 이를 서버의 공개키로 암호화하여 전송 - 서버는 이제 이를 서버의 개인키로 복호화하여 클라이언트가 만든 대칭키 확인하고 이를 사용
- https를 쓰면 어떤 장점이 있나요? - http가 보안에 취약한 점을 설명해야 할 것 같다. http의 취약한 보안을 극복하고자 나온 것이 https - http만 가지고는 도청이 너무 쉽다. 중요한 내용이 그대로 노출됨 - 클라이언트 입장에서도 통신 상대를 확인하지 않아, 위장/변조가 가능하다.
웹 서버와 WAS¶
- 웹 서버는 뭔가요? - 웹 서버는 HTML, CSS, JS, 이미지 등의 정적 자원들을 반환하고 - PHP 등의 언어를 사용해 아주 간단한 동적 웹 생성이 가능한 SW입니다. - 대표적으로 아파치, nginx가 있습니다. - 보안과 운영에 장점이 있는 SW 입니다.
- WAS는 뭔가요? - DB 접근과 비즈니스 로직 처리를 통해 동적 자원을 생성하는 SW입니다. - WAS는 웹으로 할 수 있는 처리들이 많아지면서 등장했습니다. - 대표적으로 Tomcat이 있습니다.
- WAS로도 충분히 서비스 제공이 가능한데 웹 서버를 두는 이유는 뭔가요? - WAS 보다 웹 서버가 가진 장점이 있기 때문이다. - 웹 서버를 사용하면 보안적인 측면과 운영적인 측면에서 장점이 많다. - 보안적인 측면 - Reverse Proxy로서의 기능을 할 수 있다 - 클라이언트로 부터 WAS의 정보를 감출 수 있다. - 협업 미션에서 nginx를 앞단에 두고 새로운 인스턴스를 파서 연결시켰었다. - 클라이언트는 WAS의 IP나 정보를 하나도 몰라도 서비스 사용이 가능했음 - 운영적인 측면 - 로드 밸런싱이 가능하다. - 클라이언트의 요청 몰릴때 분산시킬 수 있다 - 자주 접근되는 자원에 Caching이 가능하다 - Health Check와 같이 안전하게 서버를 운영할 수 있는 기능들이 있다 - 또한 하나 협업미션으로 느꼈던 장점은 - https 인증에 대한 분업을 WS에서 하고, WAS에는 http 요청을 보내 통신할 수 있도록 한점 - 매 WAS마다 https 인증서를 발급받고 하는 것보다 훨씬 확장성에 좋아보임