[정리] Amazon Cognito를 이용한 백엔드 API 권한 관리

인증/인가를 제대로 구축하지 않으면, MSA를 도입했을 때 복잡해짐. 레거시가 되기 쉽다.

장점?

1. 개발과 운영 리소스 절감

2. 보안 기능을 추상화해서 잘 제공

3. 개발자가 구현할 때, SDK를 기술스택 맞춰서 제공해서 SDK 가져다써서 구현하면 됨.

제공하지 않아도 auth0, oidc 오픈소스 라이브러리 가져다쓰면 쉽게 구현 가능

 

 

이번엔 사용자 풀에 대해서 제공.

Cognito User Pool의 역할

1. 스타트업의 경우에는 회원가입/로그인같은 UI보다 비즈니스 로직에 더 집중하고 싶을 수 있는데, 그럴 때 갖다 쓸 수 있음.

2. AWS 리소스와 통합 가능. (cognito에서 람다 trigger 쏴줄 수 있음)

3. OAuth 기반의 로그인 서비스들과 통합 가능 (소셜 로그인)

4. 웹/백엔드/앱/SPA등 다양한 클라이언트들에 인증 기능 연동 가능.

 

OAuth2 : 서로 다른 애플리케이션간의 접근 권한을 위임하기 위해서 만들어짐.

OIDC : OAuth2기반으로 인증 레이어를 붙여서 인증+인가 같이 처리

 

가장 큰 장점? 기술 스택에 구애받지 않는다. (기술 스택별로 라이브러리가 이미 존재함)

 

사용자별 역할 부여를 어떻게 할 수 있을까?? Cognito의 Group으로 이용해서 구현 가능.

 

초기 앱 클라이언트 설정 (제일 중요)

인증을 어디다가 어떻게 붙일 것인지 설정.

 

기밀 클라이언트 vs 퍼블릭 클라이언트의 차이는 뭘까?

-> Secret Key를 안전하게 저장할 수 있는지 없는지

Client Secret (사용자에게 절대 드러나면 안되는 값). 

기밀 클라이언트 : 환경변수로 서버에 Secret Key를 안전하게 저장

퍼블릭 클라이언트 : 브라우저 환경에서는 안전하게 저장 불가. = 애초에 Secret Key를 안만드는게 나음.

 

Cognito에서 제공하는 로그인/회원가입 UI 사용할 것인지에 대한 옵션

실 서비스에 적용하기가 좀 투박한 디자인임

OAuth 기반으로 인증/인가 구성하려면 사실상 필수 옵션

 

Universal Login이란?

독립된 페이지에 로그인과 회원가입을 구현하는 것

대부분 사용하지 않는 방식이긴 함. 보통은 특정한 특정 route 내에다가 구현을 하지 별도 페이지에 빼는 경우는 거의 없음.

다만 Universal Login은 대중적인 방식.

구글 서비스가 Universal Login을 구현하고 있는 대표적인 예시

개별 서비스는 API 인증 서버와 개별 통신할 필요 없이, Universal Login 페이지로 리다이렉트만 하면 되기 때문에 보안 취약점도 줄어들고 구현하기도 쉬워짐.

서비스 규모가 커지면 Universal Login 방식이 유용해짐.

 

PKCE flow

유저, 브라우저, 클라이언트가 구분되어있는데 사실상 다 똑같이 유저 붙어있는 환경

 

1. 브라우저에서 code vefirifer라는 랜덤 스트링 만들어서 hashing해서 code challenge라는 해싱된 문자열 만들어냄.

2. STS(Cognito)에 리다이렉트 시킴

3. Cognito가 유저 대상으로 인증 수행

4. 인증코드와 code challenge 저장

5. 인증 완료 됐으면, 인증 코드와 함께 응답 받고

6. Cognito가 브라우저에 인증 코드를 넘겨줌

... 다시 정리...

code challenge : hashing된 값

 

jwt : 개인키로 서명하고 공개키를 통해서 서명된게 유효하고 jwt 페이로드가 변경되지 않았는지 검증

iss에 jwt를 어디에 발급했는지가 나와있음