Amazon Cognito
Cognito는 애플리케이션 최종 사용자의 가입, 로그인, 토큰 발급을 담당하는 사용자 인증 계층입니다. 앱은 Cognito가 발급한 토큰으로 사용자를 식별하고, 필요하면 소셜 로그인과 임시 AWS 자격증명까지 연결합니다.
▶아키텍처 다이어그램
🔄 프로세스 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
회원가입, 로그인, 토큰 갱신, 비밀번호 재설정을 직접 만들기 시작하면 제품 기능보다 계정 보안 흐름을 붙잡는 일이 커집니다. 소셜 로그인과 여러 클라이언트까지 붙으면 인증 자체가 별도 프로젝트가 됩니다.
OAuth 2.0과 OIDC를 직접 구현하면 토큰 발급, 갱신, 폐기 흐름만으로도 코드가 복잡해지고, 미묘한 구현 실수 하나로 세션 탈취나 토큰 재사용 공격이 열립니다. 소셜 로그인까지 붙이면 각 제공자의 인증 스펙 차이를 흡수해야 하고, MFA 추가 시점에는 인증 서비스 자체가 별도 팀의 전담 프로젝트가 됩니다. 이런 비용을 감당하기 어려운 팀이 늘면서, 가입부터 토큰 갱신까지 전체 인증 흐름을 관리형으로 맡길 수 있는 Cognito 같은 서비스가 등장했습니다. 직접 구현 대비 보안 사고 표면을 줄이고, 인증 운영 부담을 AWS 인프라 쪽으로 넘기는 것이 핵심 동기였습니다.
Cognito는 User Pool로 사용자 디렉터리와 토큰 발급을 담당하고, 필요하면 Identity Pool로 AWS 자격증명을 연결합니다. Apple, Facebook 같은 소셜 로그인, SAML(기업 내부 ID 시스템과 연동하는 표준 프로토콜), 자체 IdP(신원을 확인해 주는 외부 서비스)를 붙일 수 있고, Lambda 트리거로 가입·인증 흐름을 확장할 수 있습니다.
Cognito와 IAM은 둘 다 인증처럼 보이지만 대상이 다릅니다. Cognito는 앱 사용자의 로그인과 토큰을 다루고, IAM은 AWS 계정 안의 사람과 서비스 권한을 다룹니다. 앱 사용자 가입, 로그인, 토큰 발급이 문제면 Cognito를 보고, AWS 내부 권한과 역할 설계가 문제면 IAM을 보면 됩니다.
모바일 앱이나 SPA에서 사용자 가입·로그인을 빠르게 붙여야 할 때 Cognito User Pool이 첫 선택지가 됩니다. 예를 들어 API Gateway 앞에 Cognito Authorizer를 설정하면 토큰 검증 로직 없이도 인증된 요청만 Lambda까지 도달하게 만들 수 있습니다. B2C 서비스에서 Google, Apple 소셜 로그인을 붙이거나, Identity Pool로 프론트엔드에서 S3에 직접 파일을 업로드하게 하는 구성도 흔합니다. 다만 Hosted UI의 커스터마이징에는 제약이 있어 브랜드 로그인 화면을 세밀하게 다듬으려면 별도 UI를 직접 만들어야 합니다. 기존 자체 인증 시스템에서 사용자를 마이그레이션할 때도 Lambda 트리거를 통한 점진적 이전이 필요해 전환 비용이 작지 않습니다. AWS 리소스 간 내부 권한 제어에는 맞지 않습니다.