자체 회원 시스템을 만들어 본 개발자라면 누구나 알겠지만, 인증·인가는 처음에는 단순해 보이다가 점점 괴물이 되어 가는 영역이다. 처음엔 "이메일 + bcrypt 비밀번호 + JWT"만 있으면 충분한 것 같지만, 곧 비밀번호 정책, 비밀번호 재설정 메일, MFA, 소셜 로그인(Google·Facebook·Apple), 기업 SSO(SAML·Okta·AD), 디바이스 신뢰, 위협 탐지, 로그인 시도 제한, 토큰 갱신, refresh token 회전, GDPR 동의 관리, 세션 만료 같은 요구가 차례차례 쌓인다. 그 결과 자체 회원 시스템 코드가 결제 시스템보다 더 복잡해지고, 보안 사고의 70% 이상이 이 영역에서 터진다.
이 문제를 SaaS로 분리한 게 identity-as-a-service 카테고리이고 Auth0(2013), Okta(2009), Firebase Auth(2016) 같은 회사·서비스가 이 시장을 만들었다. AWS는 2014년 7월 모바일 SDK의 일부로 Cognito를 시작했다가 2016년 7월에 현재 형태인 User Pool(사용자 디렉터리)와 Identity Pool(AWS 자격증명 발급)의 분리 구조를 확정했다. 둘의 분업이 헷갈리는 게 시험·실무 양쪽의 가장 큰 함정이고, "둘 중 어느 하나만 쓰는 케이스"와 "둘을 조합하는 케이스"의 구분이 정확해야 SAA 보안 도메인의 인증·인가 시나리오를 풀 수 있다.