Amazon Cognito 사용자 풀을 사용하여 API Gateway Rest API에서 액세스를 제어하는 방법이 혼란 스럽습니다.

그래서, 나는 모든 답을 가지고 있지는 않지만, 당신을 지시 할 몇 가지가 있습니다.

Cognito 사용자 이름은 고유 한 것이 보장됩니까?

사용자 이름 / 이메일이 이미 사용중인 경우 사용자는 가입 할 수 없습니다. 사용자 이름에 사용할 필드 (예 : 이메일 또는 사용자 이름)를 지정해야합니다.

액세스 토큰은 세션 쿠키와 동일합니까?

아니요, 액세스 토큰은 일반적으로 authorization베어러 토큰 전략을 통해 요청 의 헤더 내에서 전달되며 쿠키는 cookie헤더 내에 있습니다. 일부 서비스는 쿠키의 유효성을 검사하고 다른 서비스 (특히 컴퓨터 간)는 authorization헤더의 유효성을 검사합니다 . 어떤 경우에는 개발자가이를 동일하게 만들기로 결정할 수 있지만 항상이 방법은 아닙니다.

람다 스크립트 내부에서 액세스 토큰을 처리하려는 경우 사용할 수있는 라이브러리 또는 서비스가 있습니까?

액세스 토큰의 컨텍스트 (예 : JWT 문자열 내에 인코딩 된 사용자 이름)를 얻으려는 경우 JWT 디코딩 기능을 사용할 수 있습니다. 요청이 람다에 도달 할 때까지 Authorizor가 이미 유효성을 검사 했으므로 다시 동일하게 수행 할 필요가 없습니다.

기본 제공 권한 부여자가 사용자 정보를 람다 스크립트로 리디렉션하지 않는 이유

모든 서비스에 필요한 것은 아니기 때문입니다. 서비스 소비가 토큰을 디코딩 한 후 컨텍스트로 필요한 작업을 수행하는 것이 더 좋습니다.

API Gateway에 직접 연결할 수있는 미리 빌드 된 람다 권한 부여자가 있습니까? 그러면 로그인 한 사용자와 익명 사용자가 모두 요청하고 사용자 정보를 람다 스크립트로 리디렉션 할 수 있습니까?

이 질문은 휴식에 대한 이해에 문제가 있음을 보여줍니다. API는 CRUD 작업을 활용해야합니다. 따라서 Create기여자에게만 부여 할 Read수 있고, 공개적으로 부여 할 수 있으며, Update소유자 Delete에게만 부여 할 수 있으며 , 소유자 에게만 부여 할 수 있습니다. 위는 일반화되었지만 API 전략이 필요합니다. 이 전략을 개발할 때 "쉬운"버튼이 없다는 것을 알게 될 것입니다.

일반적으로 2 개의 API 게이트웨이가 있는데 하나는 읽기 전용이고 다른 하나는 콘텐츠 관리 용입니다. 이렇게하면 간단하게 유지되고 다양한 방식으로 확장 할 수 있습니다 (예 : 확장 문제가있는 상황에서 기여자가 읽기 전용 사용으로 차단되지 않도록 할 수 있습니다).

또한 경로 기반 전략을 채택하면 누가 어떤 리소스에 액세스 할 수 있는지 단순화하는 데 도움이 될 수 있습니다. 아래 예를 들어 보겠습니다.

사용자 /api/blog/가 새 블로그를 만들기 위해 에 POST 요청을 보냅니다 (결과는 /api/blog/:blogId). /api/blog/엔드 포인트는 특정 사용자에 의해 "소유"하지 않습니다. 나중에 사용자가 /api/blog/1234-abcd...를 업데이트하면 이제 서비스가 해당 리소스를 사용자가 소유하고 있는지 확인하기 위해 추가 호출을해야합니다 (이를 "인 타이틀먼트"프로세스라고 함). psuedo-sql SELECT created_by FROM blogs WHERE id='1234-abcd'에서 created_by필드가 사용자 ID와 일치 하는지 확인합니다 .

누구든지 요점을 알 수 있습니다. :) 팀 / 여러 사용자에게 리소스를 수정할 수있는 기능을 허용하면 훨씬 더 복잡해집니다. 그리고 훨씬 더 긴 주제 인 RBAC (역할 기반 액세스 제어)에 새로 추가됩니다.

여담에 대해 미안하지만 이것이 더 많은 방향을 제공하기를 바랍니다.