Section 27. Cognito: Cognito 사용자 풀, Cognito 자격 증명 풀 및 Cognito Sync

Amazon Cognito

• Cognito는 사용자에게 자격 증명을 부여해서 웹, 모바일 어플리케이션과 상호작용하게 한다.
• Cognito의 두 가지 하위 서비스:
  • 앱 사용자를 위한 로그인 기능
  • API Gateway와 ALB를 통합
• Cognito Identity Pools (Federated Identity):
  • AWS의 리소스에 바로 액세스할 수 있도록 임시 AWS 자격증명을 제공한다.
  • Cognito 사용자 풀과도 통합 된다.
• Cognito와 IAM를 비교하면 IAM에 이미 사용자가 있더라도,
  Cognito는 AWS 외부에 자리한 웹/모바일 어플리케이션 사용자를 위한 것이다.

---

Cognito User Pools(CUP)

1. User Features

• 웹/모바일 어플리케이션을 사용하는 유저들을 위한 서버리스 데이터베이스를 생성한다.
• 서버리스 데이터베이스란 사용자 이름이나 이메일 그리고 비밀번호의 조합으로 어플리케이션에 접속이 가능한 어플리케이션이다.
• 비밀번호 변경이 가능하며, 이메일 전화번호 인증이 가능하다.
• Federated 식별이 가능하다.
• 인증 정보가 유출 된다면 사용자를 차단할 수도 있다.
• JWT 방식을 사용한다.

2. Integrations

• CUP는 API Gateway와 ALB와 통합이 된다.
• 오른쪽 그림의 API Gateway의 경우에는 사용자들이 Cognito 사용자 풀을 통해 인증을 하고, JSON 웹 토큰을 받는다.
  그러면 사용자들이 이 토큰을 API Gateway로 전달하고, API Gateway는 Cognito 토큰을 평가하고 유효 여부를 판단한 뒤에 백엔드로 액세스를 허용해 준다.

 

 

 

• ALB의 경우에는 리스너와 규칙을 사용하여 Cognito 사용자 풀에 대해 사용자들을 인증할 수 있고 인증이 끝나면 사용자들을 대상 그룹의 백엔드로 보낼 수 있다.(이 때 대상 그룹은 EC2 인스턴스, Lambda 함수, ECS 컨테이너가 될 수 있다.)

 

 

 

 

 

3. Lambda Triggers

• 람다 트리거를 사용해서 Cognito 사용자 풀이 이 트리거 발생 시 람다 함수를 동시에 호출할 수 있다.

4. Hosted Authentication UI

• 호스팅 인증 UI를 사용하면 어플리케이션에 해당 UI를 프로그래밍하지 않아도 된다!
  Cognito가 대신 생성해준 UI를 재사용하기만 하면 되고 그것으로 가입과 로그인 워크플로를 처리하면 된다!
• 호스팅 UI를 사용하면 SNS 로그인, OIDC나 SAML과 전부 통합해주는 기반이 만들어져서 다시 프로그래밍할 필요가 없다.
• UI를 어플리케이션에 넣고 싶다면 로고를 사용자 지정하고 CSS도 사용자 지정을 하면 된다.

5. Hosted UI Custom Domain

• 커스텀 도메인을 하기위해서는 "us-east-1"의 ACM 인증을 생성해야만 한다.
• 커스텀 도메인은 반드시 "App Integration" 항목에서 정의되어야 한다.

6. Adaptive Authentication

• 조정 기능은 비정상적인 로그인이 감지되면 로그인을 차단하거나 다중 인증을 요구할 수 있는 기능이다.
• 사용자는 위험이 있을 때에만 2단계 다중 인증을 해야할 수도 있다.(Cognito를 했던 장소에서 사용하자!)
• 손상된 자격 증명인 경우에는 계정 탈취 방지가 있고 핸드폰이나 이메일 인증도 있다.
• 조정 인증 메카니즘이 수행하는 작업은 로그인 시도나 위험 점수, 시도 실패 등 종류와 상관없이 CloudWatch Logs에 기록된다.

Decoding a ID Token;JWT - JSON Web Token

• JWT 토큰은 Base64로 인코딩되어 있으며, 헤더, 페이로드, 서명으로 이루어져 있다.
• 페이로드는 사용자에 관한 정보들을 담고 있다.
• 페이로드에 있는 정보를 신뢰하려면 서명을 인증해야 하며, 알고리즘을 사용해 서명이 올바르면 페이로드에 있는 정보가 어떻든 믿을 수 있다고 결정을 내리게 된다.

---

Application Load Balancer - Authenticate Users

• ALB가 사용자를 안전하게 인증해주기 때문에 어플리케이션과 떨어져서 작업을 삭제하고 이 책임을 로드 밸런서로 넘길 수 있다.
• 사용자는 여러 방법으로 인증할 수 있다.
  
  • Identity Provider: OIDC를 준수하는 자격 증명 공급자를 사용한다.
  • Cognito User Pools: Amazon, Facebook, Google 로그인 같은 소셜 자격 증명 공급자용이다.
• 작업을 하기 위해서는 HTTPS 리스너를 설정해야 한다.
  그 다음에 authenticate-oidc나 authenticate-cognito rules를 설정할 수 있다.
• 사용자가 인증을 받지 못했다면 세 가지 방안이 있다.
  1. 인증해달라고 요청하기
  2. 요청 거부하기
  3. 요청 허용하기

Application Load Balancer - OIDC Auth

• OIDC 인증을 사용하고 있다면 다음과 같이 작업을 하면 된다.

---

Cognito Identity Pools (Federated Identities)

• 사용자들이 액세스를 얻기 위해서는 임시 AWS 자격 증명이 필요하다.
  사용자들이 많을 경우 스케일링도 잘 이루어지지 않고, IAM 계정을 생성할 수도 없기 때문이다.
• 자격 증명 풀은 제 3자를 통해 사용자들에게 로그인을 허용한다.
• 로그인 제공자들 외에도 AWS 자격 증명으로 신분을 교환하기 전에 사용자들에게 신분을 주도록 허용하기 위해 인증되지 않은 게스트 사용자들의 AWS로의 액세스도 허용할 수 있다.
  게스트 정책을 정의해서 게스트 사용자들에게 AWS 자격 증명을 주는 것이다.
• 이 자격 증명을 받은 게스트 사용자들을 AWS 서비스나 API 게이트웨이를 이용할 수 있다.
  • 사용자들은 IAM 권한을 갖고 있다.

임시 자격을 위해 STS 서비스를 받는다.

Cognito 사용자 풀 + Cognito 자격 증명 풀

IAM Roles

• 인증된 사용자들은 기본 IAM 역할의 정의가 가능하다.
• 사용자의 ID에 따라 어떤 역할이 어떤 사용자에게 배정될지 선택하는 규칙을 정의할 수 있다.
• 또한 정책 변수를 사용하여 IAM 정책을 커스터마이징할 수도 있고 이를 통해 S3에서 원하는 것에만 액세스를 할 수 있다.
• 이러한 IAM 자격 증명은 STS를 통해서 Cognito 자격 증명 풀에 의해 획득된다.
  역할은 Cognito 자격 증명 풀의 신뢰 정책을 가지고 있어야만 한다.

---

Cognito User Pools vs. Identity Pools

1. Cognito User Pools

• 사용자 풀은 자격 증명 인증에 사용된다.
• 웹/모바일 어플리케이션 사용자를 모아놓은 데이터가 된다.
• 소셜 로그인이나 기업 로그인이 가능하다.
• 로고를 비롯해 인증에 필요한 호스팅 UI를 사용자 지정할 수도 있으며, 인증 흐름에서 람다와 통합되기도 한다.
• 위험 수준으로 로그인 경험을 조정할 수도 있다.

2. Cognito Identity Pools

• 액세스 관리에 쓰이는데, AWS 안에서 액세스 관리가 이루어진다.
• 사용자 데이터베이스만 갖추고 싶다면 Cognito 사용자 풀로도 가능하다.
• 사용자들이 AWS 환경에 액세스하게 하고 싶다면 권한 부여를 해주어야 한다.(<- Cognito 자격 증명 풀)
• 사용자용 임시 자격 증명을 얻고, 자격 증명을 위한 로그인은 자격 증명용 토큰으로 교환하는 방식을 사용한다.
• 사용자가 어디서 식별되든지 토큰으로 권한을 부여받을 수 있다는 점이 중요하다!
• 사용자들을 게스트로 인증 해제할 수 있다. 자격 증명 풀에 한번 설정이 되면 사용자들은 IAM 역할이나 정책에 매핑되고, 여러 서비스에 액세스할 수 있게 해주는 정책 변수를 최대로 활용할 수 있다.

CUP + CIP를 하게 되면 1차로 인증을 얻고 2차로 권한 부여를 얻게 된다.