Application Load Balancer 탑재 인증을 통한 간편한 로그인 기능 출시
오늘 ALB(Application Load Balancer)에서 기본 인증 지원을 소개하게 되어 정말 기쁩니다. 이제 ALB는 사용자가 애플리케이션에 액세스할 때 사용자를 안전하게 인증하므로, 개발자는 인증을 지원하고 백엔드에서 인증 업무를 오프로드할 코드를 작성하지 않아도 됩니다. 팀에서는 멋진 라이브 예제를 만들었습니다. 이 예제를 통해 인증 기능을 시험해볼 수 있습니다.
자격 증명 기반 보안은 애플리케이션의 핵심 요소입니다. 고객이 미션 크리티컬 애플리케이션을 클라우드로 계속 이전하면서 개발자는 동일한 인증 코드를 몇 번이고 작성해달라는 요청을 받습니다. 엔터프라이즈는 클라우드 애플리케이션에서 온프레미스 자격 증명을 사용하려고 하고, 웹 개발자는 사용자가 로그인할 수 있도록 소셜 네트워크의 통합 자격 증명을 사용하려고 합니다.
ALB의 새 인증 작업에서는 Amazon Cognito를 통해 Google, Facebook 및 Amazon과 같은 소셜 IdP(Identity Provider) 기반 인증을 제공합니다. 또한 기본적으로 모든 OpenID Connect 프로토콜 준수 IdP와 통합되므로, 애플리케이션에서 보안 인증 및 SSO(Single Sign-On) 기능을 제공합니다.
ALB 인증 작동 방식
인증은 복잡한 주제이고, 인증에 대한 독자들의 지식 수준도 천차만별일 것입니다. 그래서 공통 이해 기반을 마련하고자 몇 가지 핵심 개념을 살펴보겠습니다. 이미 인증에 대한 전문가이고 ALB 인증 방식에 대해서만 알고 싶다면 다음 섹션으로 넘어가셔도 좋습니다!
- 인증은 신분(자격 증명)을 확인합니다.
- 인증은 자격 증명으로 수행할 수 있는 권한도 확인합니다.
- OIDC(OpenID Connect)는 OAuth 2.0 프로토콜을 바탕으로 구축된 간단한 자격 증명 또는 인증 계층입니다. OIDC 사양 문서는 잘 작성된 문서로, 편하게 읽을 수 있습니다.
- IdP(Identity Provider)는 자격 증명 정보를 관리하고 인증 서비스를 제공합니다. ALB는 OIDC 준수 IdP를 지원하며, Amazon Cognito 또는 Auth0과 같은 서비스를 사용하여 Active Directory, LDAP, Google, Facebook, Amazon 또는 AWS나 온프레미스에 배포된 기타 서비스 등 다양한 IdP에서 여러 자격 증명을 집계할 수 있습니다.
여러 가지 용어가 나오지만, 핵심은 사용자가 누구이며, 사용자에게 허용된 작업을 파악하는 것입니다. 이를 안전하고 효율적으로 수행하는 부분이 어렵습니다. 이전에 엔터프라이즈는 IdP에서 SAML이라고 하는 프로토콜을 사용하여 내부 사용자에게 SSO(Single Sign-On) 기능을 제공했습니다. SAML은 XML에 기반한 언어로, 오늘날 애플리케이션은 클레임을 공유하기 위해 JSON 메커니즘에서 OIDC를 사용하기 시작했습니다. 개발자들은 Amazon Cognito의 SAML 지원을 통해 ALB에서 SAML을 사용할 수 있습니다. 웹 애플리케이션 또는 모바일 개발자는 보통 Facebook, Amazon 또는 Google과 같은 소셜 IdP를 통해 통합 자격 증명을 사용합니다. 이러한 자격 증명은 Amazon Cognito를 통해 간편하게 지원되기도 합니다.
ALB 인증은 리스너 규칙에서 인증 작업을 정의하여 작동합니다. ALB 인증 작업은 수신 요청에 세션 쿠키가 있는지 확인한 후에 해당 쿠키가 올바른지 검사합니다. 세션 쿠키가 설정되어 있고 올바른 경우 ALB는 해당 요청을 X-AMZN-OIDC-* 헤더가 설정된 대상 그룹으로 라우팅합니다. 헤더는 백엔드에서 사용자를 식별하는 데 사용할 수 있는 JWT(JSON Web Token) 형식의 자격 증명 정보를 포함합니다. 세션 쿠키가 설정되지 않았거나 올바르지 않으면 ALB는 OIDC 프로토콜에 따라 HTTP 302 리디렉션을 IdP에게 발행합니다. 프로토콜에 관해서는 이야기할 내용이 너무 많기 때문에, 관심이 있는 분들을 위해 관련 문서에서 자세히 다룹니다.
ALB 인증 프로세스
AWS Fargate 컨테이너에서 실행하는 Amazon ECS 클러스터에 간단한 Python Flask 앱이 하나 있습니다. 컨테이너는 ALB에서 라우팅하는 대상 그룹에 있습니다. 애플리케이션의 인증 부분에 액세스하기 전에 이 애플리케이션의 사용자가 로그인했는지 확인하고자 합니다. 먼저 콘솔에서 ALB로 이동하고 규칙을 편집하겠습니다.
그리고 엔드포인트와 일치시키도록 조건을 포함하는 새 규칙을 추가하기 위해 /account* 엔드포인트에 대한 모든 액세스가 인증되었는지 확인합니다.
이제 새 규칙을 추가하고 해당 규칙에서 Authenticate 작업을 생성합니다.
몇 가지 구성 세부 정보를 제공하여 ALB는 자동으로 새 Amazon Cognito 사용자 풀을 생성합니다.
Amazon Cognito 풀을 생성한 후에 고급 설정에서 몇 가지 추가 구성을 할 수 있습니다.
기본 쿠키 이름을 변경하고, 제한 시간을 조정하고, 범위를 조정하고 인증되지 않은 요청에 대한 작업을 선택할 수 있습니다.
인증되지 않은 모든 요청에 대해 401로 처리하도록 하려면 Deny를 선택하고, 인증되지 않은 경우 애플리케이션을 통과하도록 하려면 Allow를 선택할 수 있습니다. 이 기능은 SPA(Single Page App)에 유용합니다. 이제 Authenticate를 선택합니다. 그러면 이 경우 Amazon Cognito의 IdP에 사용자를 인증하고 기존 페이지를 다시 로드하라는 메시지가 표시됩니다.
그리고 대상 그룹에 대한 전달 작업을 추가하고 규칙을 저장합니다.
Facebook의 경우 화이트리스트에 추가된 OAuth 리디렉션 URL에 Amazon Cognito 사용자 풀 도메인을 추가해야 합니다.
다른 인증 제공자에 대해서도 비슷한 단계를 수행합니다.
이제 인증된 페이지로 이동하면 Fargate 컨테이너는 ALB가 설정한 X-Amzn-Oidc-* 헤더를 포함하는 원래 요청을 수신합니다. 이 헤더의 claims-data, identity, access-token 정보를 사용하여 애플리케이션에서 인증을 구현할 수 있습니다.
이 모든 작업이 각 IdP에서 처리할 한 줄의 코드를 작성하지 않고서도 가능합니다. 하지만 애플리케이션에서 JWT 헤더에서 서명을 확인하여 요청이 조작되지 않았는지 확인하는 기능을 구현하는 것이 중요합니다.
추가 리소스
물론, 오늘 살펴본 모든 내용은 API 및 AWS CLI(명령줄 인터페이스)에서도 가능합니다. 관련 문서에서 기능에 대한 추가 정보를 확인할 수 있습니다.
라이브 예제를 확인하는 것도 잊지 마세요.
ALB에 구축된 인증을 통해 개발자는 모든 애플리케이션에 대한 인증을 다시 구성하는 대신, ALB의 확장성, 가용성 및 안정성을 관리하면서 동시에 애플리케이션 구축에 집중할 수 있습니다. 정말 멋진 기능이라고 생각합니다. 고객들도 이 기능을 사용해 무엇을 구축할 수 있을지 굉장히 기대됩니다.
– Randall
Leave a Reply