들어가기 전 사담
올해 4월부터 소프트웨어 마에스트로 15기 과정에 참여하게 되었는데, 4월부터 6월까지 약 3개월이라는 긴 시간동안 프로젝트 기획 및 기획 검증의 시간을 가졌다.
기획에 꽤 많은 시간을 쏟다보니 (기획에 이렇게 공을 들여본 프로젝트는 처음이다 .. !) 개발에 투자할 시간이 줄어들어 일정이 살짝 빠듯해졌다. 프로토타입 출시까지 남은 약 2주의 시간 동안 빠르게 개발이 이루어져야 하는 상황이다.
나는 현재 카카오 로그인 및 회원가입 개발을 맡고 있는데, 스프링 시큐리티와 함께 OAuth2 Client 라이브러리를 사용하는 과정에서 (많은) 시행착오를 겪어 생각보다 개발이 지연되었다. 그래도 다행히 프론트엔드와 연동 테스트를 거쳐 무사히 사용자 정보 가져오기를 마쳤다!
Cognito 도입기
카카오 로그인 과정에서 엑세스 토큰과 리프레시 토큰을 발급받기는 하지만, 보안상의 이유로 서비스 API를 호출할 때 카카오 토큰을 계속해서 사용하는 것은 권장되지 않는다고 한다. 따라서 카카오 로그인이 끝나는 시점에 서비스 내에서 자체적으로 엑세스 토큰과 리프레시 토큰을 생성해주고자 한다.
처음에는 토큰 관련한 로직을 전부 직접 개발하려고 했지만, 앞서 사담에서 언급했듯이 개발 일정이 빠듯한 와중에 이건 좋은 선택이 아닌 것 같았다. 그리고 무엇보다 실사용자를 유치하고자 하는 서비스에서 보안 상 구멍이라도 생긴다면 ..? 🫨
이때 AWS Cognito를 사용하게 되면 Cognito에서 제공해주는 API를 사용해 보다 간편하고 안전하게 인가 처리를 할 수 있다고 해 고민끝에 도입해보기로 결정하게 되었다. (그리고 무엇보다 멘토님의 추천이 있었다!🤩)
또 사용자 50,000명이 넘어가기 전까지는 과금 없이 Cognito에서 제공하는 서비스를 계속해서 무료로 사용할 수 있다는 점도 큰 메리트로 다가왔다.
그래서, Cognito란?
Cognito는 인증/인가, 로그인, 회원가입, 자격증명 등 회원관리에 필요한 모든 기능들을 총망라하여 지원해주는 AWS 서비스 중 하나이다. AWS Cognito에서 제공하는 기능은 크게 두 가지로, 사용자 풀(User Pool)과 자격 증명 풀(Identity Pool)이 있다.
사용자 풀은 말 그대로 사용자 정보를 저장하고 있는 저장소의 역할을 한다. 다양한 방식의 회원가입과 로그인을 지원하고, 로그인 한 사용자에게는 토큰을 발급해 자격 증명을 수행할 수 있게 도와준다.
자격 증명 풀은 사용자 풀에 등록되어 있는 사용자의 AWS 인프라 접근 권한을 관리할 수 있도록 도와준다. 사용자 풀을 생성하는 과정이 선행시 되어야 한다는 특징이 있다.
도입 환경
- Spring Boot 3.3.1
- Spring Security + OAuth2 Client 라이브러리를 사용하여 카카오 인증/인가 구현
- 자체 DB를 구축하여 사용자 정보 저장
→ 회원가입 시 필요한 정보들을 모두 사용자 풀에 저장하진 않는다. 사용자 풀은 오로지 토큰을 발급하는 목적으로만 사용한다.
AWS Cognito 연동 과정
Cognito를 도입하게 된 주요 목적이 토큰 발행 및 관리인 만큼, 이번에는 사용자 풀을 생성하고 프로젝트와 연동하는 방법에 대해서만 다루고자 한다.
AWS Cognito 사용자 풀 생성
- AWS Cognito 사용자 풀에 접속한다.
- 사용자 풀 생성
- 로그인 환경 구성
- 공급자 유형은 기본 옵션으로 지정되어 있는
Cognito 사용자 풀을 선택한다. 만약 자격 증명 풀도 함께 사용하고자 한다면연동 자격 증명 공급자를 함께 선택하면 된다. 사용자 풀 로그인 옵션은 사용자 풀에서 개별 사용자를 구별하기 위해 사용할 고유값이라고 생각하면 된다. 여기서 선택한 옵션이 사용자 풀에 중복되게 존재하면 사용자를 등록할 수 없기 때문에 나는 사용자 이름 대신 이메일을 선택했다.
- 보안 요구 사항 구성
(1) 암호 정책
Cognito를 이용해 회원가입까지 구현할 계획이 아니라면 암호 정책을 사용할 일이 없으니 신경쓰지 않아도 된다. 기본값으로 선택해줬다.
(2) 멀티 팩터 인증
Cognito를 이용해 로그인 프로세스를 처리할 때, 비밀번호 입력 외에도 SMS 인증 등을 추가로 사용하고자 할 때 멀티 팩터 인증을 적용하면 된다. 마찬가지로 사용하지 않으므로 MFA 없음을 선택한다.
(3) 사용자 계정 복구
- 가입 환경 구성
(1) 셀프 서비스 가입
활성화 하게 되면 인터넷 상의 모든 사용자가 사용자 풀에 자신을 직접 등록할 수 있게 된다. 필요하지 않은 기능이므로 선택하지 않는다.
(2) 속성 확인 및 사용자 계정 확인
Cognito에서 사용자에게 이메일이나 SMS를 보내 사용자 계정을 확인 및 검증할 수 있다. 다만 이 옵션을 허용할 경우 메시지 전송에 별도의 요금이 추가될 수 있음에 주의한다.
(3) 필수 속성 및 사용자 지정 속성
필수 속성은 사용자를 유저 풀에 등록할 때 반드시 포함해야 할 정보를 말한다. 앞서 로그인 옵션으로 이메일을 선택했기 때문에 이메일은 자동으로 포함되었다.
유저 풀을 DB처럼 사용할 생각이 아니기 때문에 필수 속성을 추가로 등록하지 않았다.
사용자 지정 속성도 마찬가지의 이유로 추가로 등록하지 않고 넘어간다.
- 메시지 전송 구성
유저 풀에 등록된 사용자에게 메시지를 전송할 방식을 선택한다. Amazon SES를 사용할 경우 별도의 요금이 부과된다. Cognito를 사용하는 방식을 선택하고 From, Reply-to는 기본값 그대로 둔다.
- 앱 통합
(1) 사용자 풀 이름
AWS Cognito에서 유저 풀을 구분하기 위한 용도이다. 어떤 프로젝트/서비스에 사용하는 것인지 잘 구분되도록 지으면 된다.
(2) 호스팅 인증 페이지
Cognito에서 제공하는 호스팅 UI를 사용해 회원가입 및 로그인을 구현한다면 해당 옵션을 선택한다. 이번 프로젝트에서는 카카오 로그인을 연동하고, 로그인 이후에 백엔드 로직에서만 Cognito를 활용할 계획이므로 선택하지 않았다.
(3) 초기 앱 클라이언트
Cognito 인증을 어디에 어떻게 붙일 것인지를 선택하는 항목이다.
→ 퍼블릭 클라이언트: SPA나 모바일 앱에서 직접 인증을 처리하는 경우
→ 기밀 클라이언트: 백엔드 서버에서 인증을 처리하는 경우
앱 유형을 구분할 때의 핵심은클라이언트 보안키(Secret Key)를 노출하지 않고 안전하게 관리할 수 있느냐인데, 브라우저 환경에서는 보안키를 안전하게 관리할 수 없으므로 퍼블릭 클라이언트는 보안키를 생성하지 않도록 주의한다.
우리 프로젝트에서는 백엔드 서버에서 인증을 처리하고 있으므로기밀 클라이언트를 선택해 주고, 클라이언트 보안키를 생성해 환경변수로 안전하게 처리하고자 한다.
(4) 고급 앱 클라이언트 설정
엑세스 토큰, 리프레시 토큰의 만료 시간을 설정할 수 있다. 서비스를 운영해보면서 적절히 조절해주는게 좋을 것 같아 아직 별도로 커스텀하지는 않았다.
(5) 속성 읽기 및 쓰기 권한
유저 풀에 등록된 사용자의 속성에 대해 읽기/쓰기 권한을 할당할 수 있는데 별도로 커스텀 할 필요성을 느끼지 못해 마찬가지로 기본값으로 설정하고 넘어간다.
- 사용자 풀 생성
사용자 풀 생성이 끝났다!
이제 프로젝트와 연동해 Cognito에서 제공해주는 API를 활용해서 카카오에서 가져온 유저 정보를 사용자 풀에 등록해주고, 토큰을 발급해주는 작업을 하면 된다 🥳
[보안/인증] Amazon Cognito를 이용한 백엔드 API 권한 관리 | 배진수, 당근마켓을 참고했습니다.
