일반적인 시나리오 - AWS Identity and Access Management
모바일 앱용 Amazon Cognito모바일 앱용 OIDC 페더레이션

일반적인 시나리오

참고

인간 사용자가 AWS에 액세스할 때 임시 보안 인증을 사용하도록 하는 것이 좋습니다. AWS IAM Identity Center 사용을 고려해 보셨나요? IAM Identity Center를 사용하여 여러 AWS 계정에 대한 액세스를 중앙에서 관리하고 사용자에게 한 곳에서 할당된 모든 계정에 대한 MFA 보호 Single Sign-On 액세스를 제공할 수 있습니다. IAM Identity Center를 사용하면 IAM Identity Center에서 사용자 자격 증명을 생성하고 관리하거나 기존 SAML 2.0 호환 자격 증명 제공업체에 쉽게 연결할 수 있습니다. 자세한 정보는 AWS IAM Identity Center 사용 설명서의 IAM Identity Center란 무엇인가요? 섹션을 참조하세요.

외부 ID 제공업체(IdP)를 이용하여 AWS 외부 및 외부 IdP에서 사용자 ID를 관리할 수 있습니다. 외부 IdP는 OpenID Connect(OIDC) 또는 Security Assertion Markup Language(SAML)을 사용하여 AWS에 ID 정보를 제공할 수 있습니다. OIDC는 일반적으로 AWS에서 실행되지 않는 애플리케이션이 AWS 리소스에 액세스해야 할 때 사용됩니다.

외부 idP와의 페더레이션을 구성하려는 경우 IAM ID 제공업체를 생성하여 외부 IdP 및 구성에 대해 AWS에 알려줍니다. 이를 통해 AWS 계정과 외부 IdP 사이에 신뢰가 구축됩니다. 다음 항목에서는 IAM ID 공급자를 사용하는 일반적인 시나리오를 제공합니다.

모바일 앱용 Amazon Cognito

OIDC 페더레이션을 사용하는 기본 방법은 Amazon Cognito를 사용하는 것입니다. 예를 들어 개발자 Adele이 점수, 프로필과 같은 사용자 데이터가 Amazon S3와 Amazon DynamoDB에 저장되는 모바일 디바이스를 위한 게임을 만들고 있다고 합시다. 또한 Adele은 이 데이터를 디바이스에 로컬로 저장하고 Amazon Cognito를 사용해 여러 디바이스 간에 동기화된 상태로 유지할 수 있습니다. Adele은 보안 및 유지 보수 상의 이유로 장기 AWS 보안 자격 증명은 게임과 함께 배포되어서는 안 된다는 것을 알고 있습니다. 또한, 게임 사용자가 아주 많을 수도 있다는 것을 알고 있습니다. 이 모든 이유로 Adele은 각 플레이어에 대해 IAM에서 새로운 사용자 자격 증명을 생성하길 원하지 않습니다. 대신에 사용자가 Login with Amazon, Facebook, Google 또는 OpenID Connect(OIDC) 호환 자격 증명 공급자(IdP)와 같은 널리 알려진 외부 IdP를 통해 이미 설정한 자격 증명을 사용해 로그인할 수 있도록 게임을 구축합니다. Adele의 게임은 이러한 공급자 중 하나의 인증 메커니즘을 이용해 사용자의 자격 증명을 확인할 수 있습니다.

모바일 앱이 자신의 AWS 리소스에 액세스할 수 있도록 하기 위해 Adele은 먼저 선택한 IdP에 개발자 ID를 등록합니다. Adele은 이들 각 공급자로 애플리케이션을 구성하기도 합니다. Adele은 게임용 Amazon S3 버킷 및 DynamoDB 테이블을 포함하는 AWS 계정에서 Amazon Cognito를 사용해 게임에 필요한 권한을 정확하게 정의하는 IAM 역할을 생성합니다. Adele이 OIDC IdP를 사용하는 경우 IAM OIDC ID 제공자 엔터티도 생성하여 AWS 계정의 Amazon Cognito 아이덴티티 풀과 IdP 간에 신뢰를 구축합니다.

앱의 코드에서 Adele은 자신이 이전에 구성한 IdP에 대한 로그인 인터페이스를 호출합니다. IdP는 사용자가 로그인하도록 허용하는 모든 세부 정보를 처리하고 앱은 공급자에게서 OAuth 액세스 토큰 또는 OIDC ID 토큰을 얻습니다. Adele의 앱은 이 인증 정보를 주고 AWS 액세스 키 ID, 보안 액세스 키 및 세션 토큰으로 구성된 임시 보안 자격 증명 집합을 얻을 수 있습니다. 그러면 앱은 이러한 자격 증명을 사용하여 AWS가 제공하는 웹 서비스에 액세스할 수 있습니다. 앱은 수임하는 역할에 정의된 권한으로 제한됩니다.

다음 그림은 Login with Amazon을 IdP로 사용하는 경우 이것이 어떻게 작동하는지 그 흐름을 단순화해 보여줍니다. 2단계에서 앱은 Facebook, Google 또는 OIDC 호환 IdP를 사용할 수도 있지만, 여기에서는 생략했습니다.

모바일 애플리케이션을 위해 Amazon Cognito를 사용하여 사용자를 페더레이션하는 샘플 워크플로우

  1. 고객은 모바일 디바이스에서 앱을 시작합니다. 앱은 사용자에게 로그인하도록 요청합니다.

  2. 앱은 Login with Amazon 리소스를 사용해 사용자의 자격 증명을 수락합니다.

  3. 앱이 Amazon Cognito API 작업 GetId 및 GetCredentialsForIdentity를 사용하여 Login with Amazon ID 토큰을 Amazon Cognito 토큰으로 교환합니다. Login with Amazon 프로젝트를 신뢰하도록 구성된 Amazon Cognito는 AWS STS와의 임시 세션 자격 증명과 교환하는 토큰을 생성합니다.

  4. 앱은 Amazon Cognito에서 임시 보안 자격 증명을 받습니다. 또한 앱은 Amazon Cognito의 기본(클래식) 워크플로를 사용하여 AssumeRoleWithWebIdentity로 AWS STS에서 토큰을 검색할 수 있습니다. 자세한 내용은 Amazon Cognito 개발자 안내서의 자격 증명 풀(페더레이션 아이덴티티) 인증 흐름을 참조하세요.

  5. 임시 보안 자격 증명은 앱에 의해 사용됨으로써 앱이 작동을 요청하는 어떤 AWS 리소스에도 액세스할 수 있습니다. 임시 보안 자격 증명과 연결된 역할 및 할당된 정책에 따라 액세스할 수 있는 항목이 결정됩니다.

다음 절차에 따라 Amazon Cognito를 사용해 사용자를 인증하도록 앱을 구성하고 앱에 AWS 리소스에 대한 액세스 권한을 부여합니다. 이 시나리오를 완수하기 위한 특정 단계에 대해서는 Amazon Cognito 설명서를 참조하세요.

  1. (선택 사항) Login with Amazon, Facebook, Google 또는 기타 OpenID Connect(OIDC) 호환 IdP에 개발자로 가입하여 해당 공급자를 통해 1개 이상의 앱을 구성합니다. Amazon Cognito에서는 사용자의 인증되지 않은(게스트) 액세스도 지원하므로 이 단계는 선택 사항입니다.

  2. AWS Management Console에서 Amazon Cognito로 이동합니다. Amazon Cognito 마법사를 사용해 자격 증명 풀을 생성합니다. 이 풀은 Amazon Cognito가 앱을 위해 최종 사용자 자격 증명을 정돈된 상태로 유지할 목적으로 사용하는 컨테이너입니다. 앱 간에 자격 증명 풀을 공유할 수 있습니다. 자격 증명 풀을 설정할 때 Amazon Cognito는 사용자에 대한 권한을 정의하는 1~2개의 IAM 역할(인증된 자격 증명용 한 개, 인증되지 않은 "게스트" 자격 증명용 한 개)을 생성합니다.

  3. AWSAmplify를 앱과 통합하고 Amazon Cognito를 사용하는 데 필요한 파일을 가져옵니다.

  4. 자격 증명 풀 ID, AWS 계정 번호 및 자격 증명 풀과 연결한 역할의 Amazon 리소스 이름(ARN)을 전달하여 Amazon Cognito 보안 인증 공급자의 인스턴스를 생성합니다. AWS Management Console의 Amazon Cognito 마법사에서 제공하는 샘플 코드를 사용하면 시작하는 데 도움이 됩니다.

  5. 앱이 AWS 리소스에 액세스할 때 클라이언트 객체에 자격 증명 공급자 인스턴스를 전달합니다. 이렇게 하면 클라이언트에 임시 보안 자격 증명이 전달됩니다. 자격 증명에 대한 권한은 앞서 정의한 역할 또는 역할들에 기반을 두고 있습니다.

자세한 내용은 다음 자료를 참조하세요.

  • AWS Amplify Framework Documentation의 로그인(Android).

  • AWS Amplify Framework Documentation( 프레임워크 설명서)의 Sign in (iOS)(로그인(iOS))

모바일 앱용 OIDC 페더레이션

최상의 결과를 얻으려면 거의 모든 OIDC 페더레이션 시나리오에서 Amazon Cognito를 ID 브로커로 사용하는 것이 좋습니다. Amazon Cognito는 사용하기 쉽고 익명(인증되지 않은) 액세스, 디바이스 및 공급자 간에 사용자 데이터 동기화 등의 추가 기능을 제공합니다. 그러나 이미 수동으로 AssumeRoleWithWebIdentity API를 호출하여 OIDC 페더레이션을 사용하는 앱을 생성한 경우에는 계속 사용할 수 있으며 앱이 계속 정상적으로 작동합니다.

Amazon Cognito를 사용하지 않고 OIDC 페더레이션을 사용하는 프로세스의 경우 다음과 같은 일반적인 개요를 따릅니다

  1. 외부 자격 증명 공급자(IdP)에서 개발자로 로그인하여 앱을 위한 고유 ID를 부여하는 IdP에서 앱을 구성합니다. (IdP마다 이 프로세스에 대해 다른 용어를 사용합니다. 이 개요에서는 IdP에 앱을 식별하는 프로세스를 구성이라는 용어로 설명합니다.) 각 IdP는 IdP 고유의 앱 ID를 제공함으로써, 동일한 앱을 다수의 IdP로 구성하는 경우 앱은 여러 개의 앱 ID를 갖게 됩니다. 각 공급자로 여러 개의 앱을 구성할 수 있습니다.

    다음 외부 링크는 흔히 사용되는 자격 증명 공급자(IdP) 중 일부를 사용하는 것에 대한 정보를 제공합니다.

    중요

    Google, Facebook 또는 Amazon Cognito의 OIDC 자격 증명 공급자를 사용하는 경우 AWS Management Console에서 IAM 자격 증명 공급자를 별도로 생성하지 마세요. AWS에 내장된 OIDC 자격 증명 공급자를 사용하면 됩니다. 다음 단계를 건너뛰고 자격 증명 공급자를 사용하여 새 역할을 생성하는 단계로 바로 이동합니다.

  2. Google, Facebook 또는 Amazon Cognito 외에 OIDC와 호환되는 다른 IdP를 사용하는 경우 IdP를 위한 IAM 자격 증명 공급자 엔터티를 생성합니다.

  3. IAM에서 하나 이상의 역할을 생성합니다. 각 역할에 대해 그 역할을 위임할 수 있는 대상(신뢰 정책)과 앱 사용자가 가지는 권한(권한 정책)을 정의합니다. 일반적으로 앱이 지원하는 각 IdP마다 하나의 역할을 생성합니다. 예를 들면 사용자가 Login with Amazon을 통해 로그인할 때 앱이 수임할 수 있는 역할, 사용자가 Facebook을 통해 로그인하는 경우 동일한 앱의 두 번째 역할, 사용자가 Google을 통해 로그인하는 경우 앱의 세 번째 역할 등을 생성할 수 있습니다. 신뢰 관계를 위해서는 IdP(예: Amazon.com)를 Principal(신뢰받는 개체)로 지정하고 앱 ID에 할당된 IdP와 일치하는 Condition을 포함시키세요. 여러 공급자의 역할에 대한 예는 타사 ID 제공업체의 역할 생성(페더레이션)에 설명되어 있습니다.

  4. 애플리케이션에서 IdP로 사용자를 인증하세요. 이렇게 하는 방법의 구체적인 내용은 사용 중인 IdP(Login with Amazon, Facebook 또는 Google)와 앱이 실행되는 플랫폼에 따라 달라집니다. 예를 들어 Android 앱의 인증 방법은 iOS 앱 또는 JavaScript 기반 웹 앱과 다를 수 있습니다.

    일반적으로 사용자가 아직 로그인하지 않은 경우 IdP가 로그인 페이지 표시를 처리합니다. IdP가 사용자를 인증한 후에 IdP는 사용자에 대한 정보가 담긴 인증 토큰을 앱에 반환합니다. 포함된 정보의 내용은 IdP가 노출하는 것과 사용자가 공유하고자 하는 정보가 무엇인지에 달려 있습니다. 앱에서 이 정보를 사용할 수 있습니다.

  5. 앱에서 AssumeRoleWithWebIdentity 작업에 대한 서명되지 않은 호출을 수행하여 임시 보안 자격 증명을 요청합니다. 요청 시 IdP의 인증 토큰을 전달하고 해당 IdP에 대해 생성한 IAM 역할의 Amazon 리소스 이름(ARN)을 지정합니다. AWS는 그 토큰이 신뢰할 수 있고 유효한지 확인하여, 그럴 경우에는 요청에서 명명하는 역할에 대한 권한을 포함하는 임시 보안 자격 증명을 앱에 반환합니다. 그 응답에는 IdP가 사용자에게 연결하는 고유 사용자 ID와 같은, IdP에서 오는 사용자에 대한 메타데이터도 포함되어 있습니다.

  6. AssumeRoleWithWebIdentity 응답의 임시 보안 자격 증명을 사용하여 앱에서 AWS API 작업에 대한 서명된 요청을 생성합니다. IdP의 사용자 ID 정보는 앱에서 사용자를 구분할 수 있습니다. 예를 들어 사용자 ID가 접두사 또는 접미사로 포함된 Amazon S3 폴더에 객체를 넣을 수 있습니다. 이렇게 함으로써 폴더를 잠그는 액세스 제어 정책을 생성해 그 ID를 지닌 사용자만 그 폴더에 액세스할 수 있게 됩니다. 자세한 내용은 AWS STS 페더레이션 사용자 세션 보안 주체 단원을 참조하십시오.

  7. 앱은 AWS에 요청할 필요가 있을 때마다 새 임시 보안 자격 증명을 받지 않아도 되도록 임시 보안 자격 증명을 캐시해야 합니다. 기본적으로 자격 증명은 1시간 동안 유효합니다. 자격 증명이 만료되면(또는 그 전에) AssumeRoleWithWebIdentity에 또 한 번 호출을 하여 새로운 임시 보안 자격 증명 집합을 얻으세요. IdP의 토큰 역시 보통 설정된 시간이 지나면 만료되기 때문에, IdP 및 IdP가 토큰을 어떻게 관리하느냐에 따라 AssumeRoleWithWebIdentity에 새로운 호출을 하기 전에 IdP의 토큰을 갱신해야 할 수도 있습니다. AWS SDK for iOS 또는 AWS SDK for Android를 사용하는 경우 AmazonSTSCredentialsProvider 작업을 사용해 IAM 임시 자격 증명을 필요에 따라 갱신하는 등 관리할 수 있습니다.