- 나의 생각 : Amazon Cognito 사용자 풀, Amazon Cognito identity pool을 통해 권한을 얻고 다른 aws 서비스에 접근한다..?
Amazon Cognito 사용자 풀 : 웹 및 모바일 앱 인증 및 권한 부여를 위한 사용자 디렉터리이다. 앱 관점에서 Amazon Cognito 사용자 풀은 OpenID Connect(OIDC) ID 공급자(IdP)이다. 사용자 풀은 보안, ID 페더레이션, 앱 통합 및 사용자 경험 맞춤 설정을 위한 다양한 기능을 제공한다.
위쪽은 “누가 로그인했는지”를 확인하는 부분(유저 풀),
가운데는 “이 계정이 어떤 AWS 리소스를 써도 되는지”를 정해주는 부분(아이덴티티 풀),
아래는 실제로 호출하는 AWS 서비스이다.
0. 서비스 정리
Apps
- 웹/모바일 앱 (React, Vue, iOS, Android 등)
- 사용자 브라우저/앱에서 직접 Cognito에 요청을 보내고,
나중엔 이 앱이 API Gateway, OpenSearch 같은 AWS 서비스도 호출.
Amazon Cognito User Pool
-
사용자 계정 DB + 로그인/회원가입 서비스.
-
하는 일:
- 회원가입(Sign-up), 로그인(Sign-in)
- 비밀번호 재설정, MFA, 이메일/폰 검증
- 로그인에 성공하면 JWT 토큰(ID/Access/Refresh) 발급
외부 Identity Provider들
- Social sign-in: 구글, 애플, 페이스북 같은 소셜 로그인
- SAML: 회사 내부 IdP(Okta, ADFS 등)와 연동
- OIDC: 다른 OIDC 호환 IdP(Keycloak, Auth0 등)
- Custom: 자체 OIDC/SAML 같은 커스텀 IdP
- 유저 풀과 연결돼서, “외부 계정으로 Cognito에 로그인” 할 수 있게 해줌.
Amazon Cognito Identity Pool (아이덴티티 풀)
- “이 사용자에게 어떤 AWS IAM Role을 줄까?”를 결정하는 브리지.
- 유저 풀에서 받은 JWT, 혹은 구글/애플 토큰 등을 받아서
→ STS 임시 자격증명(AccessKey/Secret/SessionToken) 으로 바꿔줌. - 즉, Cognito 사용자 ↔ IAM Role ↔ 다른 AWS 서비스 사이 연결.
Other AWS services (하단)
-
예시로 그려진 것:
- Elastic Load Balancing (ALB/NLB)
- Amazon API Gateway
- Amazon OpenSearch Service
-
실제로는 여기 자리에 S3, Lambda, DynamoDB 등 어떤 서비스든 올 수 있음.
1. ① Apps → User Pool
- 사용자가 앱에서 로그인 시도
-
앱이 Cognito User Pool 엔드포인트로 인증 요청 보냄.
- 소셜/SAML/OIDC를 쓴 경우, 브라우저가 해당 IdP로 리다이렉트됐다가
인증 완료 후 다시 Cognito로 돌아오는 플로우.
- 소셜/SAML/OIDC를 쓴 경우, 브라우저가 해당 IdP로 리다이렉트됐다가
-
Cognito가
- 로컬 유저 DB를 조회하거나
- 외부 IdP에서 받은 assertion/token 을 검증한 뒤
-
인증에 성공하면 앱에게 JWT 토큰 세트를 돌려줌.
- ID 토큰: “이 사용자는 누구인가?” (이메일, 이름, 클레임)
- Access 토큰: Cognito 리소스에 대한 접근 권한
- Refresh 토큰: 만료 후 토큰 재발급용
비유
- User Pool = 건물 입구의 “리셉션 + 출입 명부”
- “이 사람이 우리 회사 사람 또는 파트너가 맞는지” 확인하고 명찰(JWT) 을 달아줌.
2. ② Apps → Identity Pool
-
앱은 로그인 후 얻은 ID 토큰(JWT) 을 들고
- Cognito Identity Pool에 “권한 달라”고 요청.
- 예:
GetId,GetCredentialsForIdentity호출
-
Identity Pool 설정에는 보통 이런 매핑이 있음:
-
인증된 사용자(Authenticated) → Role A
-
비인증 사용자(Guest/Unauthenticated) → Role B
-
또는 그룹/클레임에 따라 여러 Role로 분기
- 예:
cognito:groups에admin이 있으면 AdminRole, 아니면 UserRole
- 예:
-
-
Identity Pool은
- 토큰이 유효한지 검증하고
- 어떤 Role을 줄지 결정한 뒤,
- 내부적으로 STS를 호출해 해당 Role을 Assume 함.
-
STS가 임시 자격증명(AccessKey/Secret/SessionToken)을 만들어 주면
Identity Pool이 그 값을 앱에게 반환.
비유
- Identity Pool = “우리 회사 ID를 가진 사람에게 어떤 구역까지 들어가게 할까”를 정하는 보안실.
- JWT 명찰을 보고 “이 사람은 직원이니까 R&D 층까지 출입증 발급” 이런 느낌.
3. ③ Apps → Other AWS Services
-
앱은 이제 임시 IAM 자격증명을 손에 들고 있음.
- SDK/클라이언트에 이 키들을 설정하거나,
- Cognito SDK가 자동으로 관리해 줌.
-
이 자격증명을 이용해 다음과 같은 AWS 서비스 호출:
- API Gateway → 백엔드 Lambda 호출
- OpenSearch → 검색 쿼리 수행
- (그림엔 없지만) S3 → 파일 업로드/다운로드, DynamoDB → 데이터 조회 등
-
이때 각 서비스의 IAM Policy 로 권한을 제어:
- 예:
Allow s3:PutObjectonmy-app-user-uploads/${cognito-identity.amazonaws.com:sub}/* - OpenSearch 인덱스도 사용자 ID에 따라 제한 가능.
- 예:
-
토큰/자격증명은 일정 시간 후 만료 →
앱이 필요할 때 다시 Identity Pool을 통해 새로 받음.
비유
- 다른 AWS 서비스들 = 실제 “창고, 서버실, 문서보관실”.
- Identity Pool이 발급한 출입증(임시 키)을 들고,
정책에 허용된 방에만 들어가서 작업하는 구조.
4. 이 아키텍처의 핵심 포인트
- User Pool = “사람 인증(Identity Provider + 유저 DB)”
- Identity Pool = “인증된 사람에게 AWS IAM Role 연결”
- Other AWS services = “실제 리소스. IAM으로 접근 통제”
장점:
- 앱 쪽에서 장기 Access Key를 저장할 필요 없음 → 보안 ↑
- 소셜/회사 계정/커스텀 IdP까지 한 번에 연동 가능
- 사용자 속성/그룹에 따라 세밀하게 IAM 권한 분리 가능
