인증 관련
클라이언트과 서버의 request, response가 있을 떄, 이를 그냥 요청하고 받으면 누가 요청했는지 알 필요가 없게끔 stateless하게 웹이 구성되어 있음 ‘인증받은 것을 표현하자’ stateless한 것을 stateful하게 관리 세션값을 유니크하게 만들기 로그인 후 브라우저의 쿠키 → 개발자 도구로 조회 가능 서버는 클라이언트의 상태를 알고 있음
토큰 기반 인증 인증 정보를 서버에서 가지고 있지 않기 때문에 편리함 매번 다른 서버로 갈 때가 있는데 모든 인증을 서버에서 유지하기가 어려움 따라서 이를 인지할 수 있는 토큰을 통해 사용자의 validation을 처리 해시값을 이용해 무결성 체크 API에 대한 권한 토큰은 쿠키값에 저장? 쿠키의 접근을 스크립트로 하지 못하게 http-only설정 엑세스토큰을 플로우로 확인하고 리프레시 토큰을 써서 갱신 어플리케이션 로직까지 갈 필요가 없으니 정적인 것들을 개선할 필요가 없음. 바로 라우팅 처리 인증은 네트워크 보안의 의미 리프레시 토큰 - 시간 관리상 하기 부족하니까 낮은 우선순위로 두기
데이터 통신 - 실시간 양방향
양방향 통신은 실시간성이 요구되는 다양한 애플리케이션에서 필수적.
대표적인 양방향 통신 방법은 아래와 같음.
AJAX Polling
클라이언트가 일정한 간격으로 서버에 HTTP 요청을 보내 데이터를 가져오는 방식 단방향 통신이지만, 주기적으로 데이터를 요청함으로써 간접적인 양방향 통신 구현 가능 setInterval을 통해 http 요청 보내기
장점
- 구현이 간단하며 대부분의 브라우저에서 지원
- 기존 HTTP 인프라를 그대로 사용가능
단점
- 불필요한 요청이 빈번하게 발생하여 서버 부하 증가
- 실시간성 부족, 데이터 업데이트 지연 발생
사용 사례
- 실시간성이 크게 요구되지 않는 간헐적인 데이터 업데이트
- 간단한 상태 모니터링 대시보드
- 뉴스 피드나 공지사항 업데이트 등
Long Polling
클라이언트가 서버에 요청을 보내면 서버는 새로운 데이터가 생길 때까지 응답을 지연시키는 방식 데이터가 준비되면 서버가 응답을 보내고, 클라이언트는 즉시 새로운 요청을 보내는 방식 데이터의 양, 종류, 리소스를 보고 결정함
장점
- 실시간성 향상, 클라이언트가 새로운 데이터를 즉시 받을 수 있음
- 불필요한 요청 감소, 서버 부하 상대적으로 적음
단점
- 여전히 HTTP 요청의 한계 존재
- 구현 복잡성 증가, 서버 리소스 소비
사용 사례
- 채팅 애플리케이션
- 실시간 알림 시스템
- 실시간 업데이트가 필요한 협업 도구 등
Server-Sent Events (SSE)
Server-Sent Events는 서버에서 클라이언트로 일방향으로 지속적인 데이터 스트림을 전송하는 방식임. 클라이언트는 서버로부터 지속적으로 데이터를 수신할 수 있지만, 클라이언트에서 서버로 데이터를 보내는 것은 불가능함.
장점
- 구현이 비교적 간단하고 효율적임
- 자동 재연결 기능 제공
- 텍스트 기반 데이터 전송에 최적화됨
단점
- 단방향 통신만 가능함
- 과거 브라우저에서 지원되지 않을 수 있음
사용 사례
- 실시간 뉴스 피드
- 실시간 주식 시세 업데이트
- 실시간 스포츠 경기 점수 업데이트
SSE의 처리되는 흐름
- 클라이언트에서 서버로 연결 요청
- 클라이언트는
EventSource객체를 생성해/sse경로로GET요청을 보냄. - 이 요청을 통해 데이터를 지속적으로 수신할 준비를 함.
- 클라이언트는
- 서버에서 연결을 유지하고 스트리밍 응답 시작
- 서버는 클라이언트의 요청에 대해
Content-Type: text/event-stream헤더를 설정하고 응답을 유지함. - 이 상태에서 서버는 데이터를 계속해서 클라이언트로 푸시할 수 있음.
- 서버는 클라이언트의 요청에 대해
- 서버가 주기적으로 데이터를 전송
- 서버는 특정 이벤트나 일정 시간 간격에 따라 데이터를
res.write()메서드를 사용해 클라이언트로 전송함. - 각 메시지는
data:로 시작하고 두 개의 개행 문자(\n\n)로 끝내야 하며, 이를 통해 클라이언트는 메시지의 끝을 구분할 수 있음.
- 서버는 특정 이벤트나 일정 시간 간격에 따라 데이터를
- 클라이언트에서 실시간으로 데이터 수신
- 클라이언트는
onmessage이벤트 핸들러를 통해 서버에서 전송된 데이터를 실시간으로 수신하고 처리할 수 있음.
- 클라이언트는
WebSocket
- 실시간 통신의 필요성이 커지면서 2011년에 WebSocket이 표준화.
- WebSocket은 이 TCP프로토콜을 기반으로 작동하며, 데이터가 순서대로 전송되도록 하고 오류가 발생할 경우 자동으로 복구.
- HTTP 핸드셰이크로 연결을 시작한 후 TCP 소켓을 통해 양방향 데이터 전송을 지속함.
- http 요청을 보낸 후 업그레이드 하는 방식
- 실시간 데이터 교환이 중요한 애플리케이션에 적합.
장점
- 낮은 지연 시간, 실시간 데이터 교환에 최적화됨
- 효율적인 데이터 전송, 헤더 오버헤드 감소
- 클라이언트와 서버가 동시에 데이터를 주고받을 수 있음
단점
- 지속적인 연결로 인한 서버 자원 소모
- 구현 복잡성 증가
- 일부 방화벽이나 프록시에서 차단될 수 있음
사용 사례
- 실시간 채팅 애플리케이션
- 실시간 게임
- 실시간 협업 도구 (예: 공동 문서 편집)
- 실시간 데이터 스트리밍 (예: 라이브 스포츠 중계)
사용 사례 비교
- JAX Polling
- 간헐적인 데이터 업데이트가 필요한 경우
- Long Polling
- 실시간 채팅이나 알림 등, 중간 정도의 실시간성이 필요한 경우
- SSE
- 서버에서 클라이언트로 지속적인 데이터 스트림이 필요한 경우
- WebSocket
- 높은 실시간성과 양방향 통신이 필요한 경우
Websocket 더 알아보기
- 무상태 → 이를 보완하기 위해 세션이나 쿠키 사용
- websocket-key : 브라우저의 고유한 ID값을 만들어 보내고, 서버는 이로 식별한다
Oauth
Oauth는 사용자 자격 증명을 공유하지 않는다? → ID와 패스워드를 공유하지 않는다. ID와 패스워드를 공유하게 된다면 악용 가능 제한된 방식의 접근만 허용하기 oauth를 쓰게 된다면 사용자가 소유한 리소스 중에서 접근을 명시적으로 허가한 부분만 접근 가능
-
client → 브라우저가 아닌 oauth를 사용하려는 우리의 서버
-
authorization Server → github의 인증서버, 리소스 소유자에게 인증을 받고 토큰 발급
-
Resouce Server → github api의 서버, 엑세스 토큰으로 접근 허용
-
인증(authentication)
- 내가 누구다 라고 증명하는 것
- 실제 누구가 맞는지 확인하는 과정
-
권한 부여(authorization)
- 요청한 리소스에 대해서 권한이 있나 없나 확인하고 적절한 권한이 있으면 리소스를 제공
인증방법들
- 아이디 패스워드
- 아이디 패스워드를 가지게 되면 모든 리소스에 접근이 가능해서 문제가 될 수 있음
- 토큰 인증
- AccessToken과 Refresh Token을 함께 사용한 인증
- JWT를 사용한 인증
- LDAP / AD
Oauth의 장점 및 필요성
- 인증과 권한 부여를 동시에 가능
- 일반 사용자의 정보 유출을 막으면서 서드 파티에게 필요한 정보를 제공 가능
- 세밀하게 scope 제어 가능
- 현재 사실상의 업계 표준
추상적인 흐름
- 우리 서비스가 유저에게 Authorization Request를 보냄(사용자에게 인증 요청)
- 유저는 리소스에서 로그인 및 회원 정보 제공
- 클라이언트는 유저로부터 받은 결과물(허용 범위, 정보)를 가지고 깃허브의 인증 서버로 보냄
- 인증 서버는 정확한 정보가 맞는지 확인과 함께 요청한 서비스가 실제로 맞는지 확인
- 확인이 되면 인증 서버는 엑세스 토큰을 발급
- 엑세스 토큰을 가지고 리소스 서버에서 scope에 허용된 정보만 가져옴
- 리소스 서버는 제한된 범위의 리소스를 보여줌
엑세스 토큰은 세션에서 db에 저장해놓기 리소스 서버의 엑세스 토큰을 들고 있을 필요가 없음
+----------+
| Resource |
| Owner |
| (일반 유저)|
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | (깃허브에서 로그인 페이지) | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ (요청한 서비스,스코프,유저) +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | (앱의 시크릿 키) |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
- Authorization Code Grant
authorizationURL에 다른 쿼리 파라미터로 내어주기
보통은 oauth인증받은거를 기반으로 redirect uri로 이동
code를 받음
authorization 서버로 받은 코드를 넣어 다시 보내기
토큰 받기