AWS Websockets 소개 섹션 2: 인증

my last post에서 AWS에서 WebSocket API를 만드는 법을 배웠습니다.메시지를 연결하고 보낼 수 있는 기능적인 API를 구축했습니다.하지만 이것은 수수께끼의 일부일 뿐이다.
이제 WebSocket을 시작으로 보안에 대해 논의해야 합니다.정말, 우리는 started with security해야 하는데, 그 배는 이미 출항했다.우리는 악의적인 사용자가 우리의 API에 연결되어 DDoS 또는 주입을 통해 우리를 쓰러뜨리려고 시도하는 것을 원하지 않습니다.
오늘 Google은 지난주에 만든 내용을 사용하여 연결된 모든 사람이 시스템의 유효한 사용자임을 확인하기 위해 lambda authorizer를 추가할 것입니다.

웹소켓auth 이해

너는 "왜 이 문장이 하나의 일이 되었을까? 나는 어떻게 썼는지 안다add a lambda authorizer to an API"고 생각할 수도 있다.
이것은 사실일 수도 있지만, WebSocket 특유의 몇 가지 문제를 이해해야 합니다.대부분의 웹소켓에 연결된 전단 자바스크립트 라이브러리는 표준 Authorization 헤더를 지원하지 않습니다.
연결이 설정되면 WebSocket APIonly supports the Sec-WebSocket-Protocol header가 삭제됩니다.Postman와 같은 도구는 연결을 만들 때 다른 헤더 파일을 전송할 수 있도록 합니다. (이것은 좋은 일입니다.)그러나, 프로그램에서 전방 코드를 작성하기 시작하면, 즉시 멈추게 됩니다.
이 문제를 해결하는 동시에 안전한 연결 방법을 제공하기 위해 우리는 두 가지 선택을 할 수 있다.

제목Sec-WebSocket-Protocol 제목

에 구분 값 제공

검색 문자열 파라미터

에 인증 영패 제공
이 두 가지 방법은 모두 이해득실이 있으니, 최종 결정권은 너에게 있다.AWS 계정에 구축된 솔루션은 두 가지 방법을 지원합니다.나는 query string parameter approach를 사용하는 것을 권장한다. 왜냐하면 그것은 매우 간단하고 access_token 머리의 용도를 바꾸지 않기 때문이다.
따라서 새 연결을 만들 때, 우리는 표준 Sec-WebSocket-Protocol 헤더가 아닌 Authorization 이라는 검색 문자열 파라미터를 전송할 것입니다. 이 파라미터는 우리의 jwt 헤더를 포함합니다.
WebSocket auth에서 주의해야 할 또 다른 점은 $connect에서 인증만 하면 된다는 것입니다.모든 후속 호출은 인증된 연결을 사용합니다.이것은 매우 쉽다!

인증 업데이트 배포

이 시리즈part one를 따르는 경우 AWS 계정에 기본 WebSocket을 배치합니다.연결을 추가하고 삭제하며 특정 실체에 대한 구독을 추가하고 삭제할 수 있습니다.오늘 우리는 branch in that repo를 사용하여 기존의 기능을 강화할 것이다.
저장소의 비주 분기를 체크 아웃하는 데 익숙하지 않은 경우 VS Code 터미널에서 다음 명령을 실행하여 로컬에서 체크 아웃할 수 있습니다.

git fetch
git checkout part-two

로컬에 원본 코드가 있으면 이전처럼 배치할 수 있습니다: access_token 명령을 사용합니다.실행하기 전에 sam deploy 파일을 업데이트해야 합니다.
우리의 lambda authorizer에서, 우리가 제공한 jwt (신분 검증 영패) 는 신뢰할 수 있는 출처에서 나온 것이다.이를 위해 jwt가 키로 서명했는지 확인합니다.키는 사용자가 좋아하는 모든 내용일 수 있지만, 생산 장면에서 이 동작을 실행할 때 다른 사람과 키를 공유하지 않도록 하십시오.
나는 samconfig.toml 명령을 사용하여 이 창고의 매개 변수를 다시 실례화하는 것을 건의합니다.일단 완성되면 즉시 배치합니다!

내가 방금 무엇을 배치했습니까?

우선, 믿어줘서 고마워요.그 다음으로 지난번과 같은 설정을 배치하고 새로운 기능을 추가했습니다.

새로운 lambda 권한 수여자

사용자 정보를 저장하는 $connect lambda가 업데이트되었습니다

배치 시 제공된 비밀 테스트를 사용하여 jwt의 lambda

생성

Secrets Manager 기밀 보안 저장 jwt 기밀

저장소에는 sam deploy --guided 파일에서 생성된 전체 인프라 다이어그램이 들어 있습니다.만약 네가 아직 그것을 흔히 볼 수 있는 방법으로 삼지 않았다면, 나는 highly recommend generated diagrams.그것들은 먼지를 털기 힘들지 않고 거대한 가치를 제공했다.다음은 AWS에 배포된 보안 WebSocket API의 전체 리소스입니다.

보안 WebSocket 아키텍처의 인프라 다이어그램

안전한 웹소켓에 연결

모든 것이 배치되었으니, 우리 웹소켓과 연결할 때가 되었다.우선 연결이 안전한지 확인해야 합니다.따라서, 우리는 이 시리즈의 첫 번째 부분에서 했던 것처럼 그것을 연결하려고 시도할 것이다.

열기desktop app

신규 선택 ->WebSocket 요청

주소 필드

에 SAM 배포 출력의 라우팅template.yaml 출력 값을 입력합니다.

탭을 클릭하고 WebsocketUri 제목 및 값Headers을 추가합니다.

클릭 연결

만약 모든 것이 계획대로 진행된다면, 우리는 401을 받을 것이다. 왜냐하면 우리는 신분 검증 영패를 제공하지 않았기 때문이다.

401 인증 토큰이 연결되지 않았을 때의 응답
이제 영패를 가져와 연결을 맺읍시다.

터미널이나 VS 코드에서 다음 명령을 입력하여 jwt를 생성하는 테스트 lambda를 실행합니다

aws lambda invoke --function-name CreateTestJwt response.json

생성된 Sec-WebSocket-Protocol 파일을 열고 authToken 속성

의 값을 복사합니다

Postman에서 websocket라는 URL에 검색 문자열 파라미터를 추가하고authToken 값

을 붙인다.

클릭 연결

연결 성공!!
현재 우리는 이미 연결되어 있으며, 우리는 웹 소켓에 메시지를 보내고 받을 수 있으며, 추가 신분 검증이 필요하지 않다.

저희가 지금 뭘 할 수 있을까요?

WebSocket이 안전한 이상 악성 사용자가 시스템을 파괴할 염려가 없습니다.그래서 우리가 할 수 있는 첫 번째 일은 긴장을 푸는 것이다.
그 다음으로, 우리는 이미 특정한 사용자의 단계에서 통지를 보낼 수 있다.Lambda authorizers는 코드에 사용할 충실한 데이터를 포함하는 response.json 객체를 반환합니다.예시authorizer에서 jwt의 access_token, context, userId, firstName 와 lastName 를 디코딩하여 $connect 함수에 전달했습니다.
이 정보는 다이나모의 연결 기록에 저장되어 있기 때문에 우리는 이를 사용하여 사용자에게 알림을 보낼 수 있다.

lambda 권한 수여자로부터 온 사용자 정보
사용자 id는 sub로 저장되어 있기 때문에 우리는 사용자의 연결 정보를 찾을 수 있고 필요할 때 그들에게 전송할 수 있다.본 연습에서는 이 기능을 실현하지 못했지만, 우리는 본 시리즈의 후속 문장에서 이에 대해 확장할 것이다.

다음은요?

year of async에서 우리는 머리를 아래로 향해 웹소켓 수영장으로 잠입했다.이 시리즈의 후속 글은 WebSocket API를 어떻게 사용하고Async API Spec 기록하는지, 사용자 기반 푸시 알림을 추가하는지, 동기화 단점에서 비동기화 단점으로 어떻게 이동하는지 어떤 박자도 잃지 않고 어떻게 이동하는지 소개할 것이다.
이 강좌에서 창고를 시도하고 구성 요소를 익히며 변경을 시도합니다!즐거운 코딩!