일반적인 시나리오

일반적인 시나리오 (Common scenarios)

참고

사람 사용자가 AWS에 접근할 때는 임시 자격 증명을 사용하도록 요구하길 권장해요. AWS IAM Identity Center를 고려해 보셨나요? IAM Identity Center로 여러 AWS 계정에 대한 접근을 중앙에서 관리하고, 사용자에게 할당된 모든 계정에 MFA 보호, 싱글 사인온 접근을 한 곳에서 제공할 수 있어요. IAM Identity Center에서는 IAM Identity Center에 사용자 아이덴티티를 만들고 관리하거나, 기존 SAML 2.0 호환 아이덴티티 프로바이더에 쉽게 연결할 수 있어요. 자세한 내용은 AWS IAM Identity Center 사용자 가이드의 IAM Identity Center란 무엇인가요?를 참고하세요.

출처: 문서

본문

외부 아이덴티티 프로바이더(IdP)를 사용해 AWS와 외부 IdP 밖에서 사용자 아이덴티티를 관리할 수 있어요. 외부 IdP는 OpenID Connect(OIDC) 또는 **SAML(Security Assertion Markup Language)**을 사용해 AWS에 아이덴티티 정보를 제공할 수 있어요. OIDC는 AWS에서 실행되지 않는 애플리케이션이 AWS 리소스에 접근해야 할 때 흔히 사용돼요.

외부 IdP와 페더레이션을 구성하려면 IAM 아이덴티티 프로바이더를 만들어 AWS에 외부 IdP와 그 구성을 알려요. 이렇게 하면 AWS 계정과 외부 IdP 사이에 신뢰가 구축돼요. 다음 주제들은 IAM 아이덴티티 프로바이더를 사용하는 일반적인 시나리오를 제공해요.

다루는 주제

  • 모바일 앱용 Amazon Cognito
  • 모바일 앱용 OIDC 페더레이션

모바일 앱용 Amazon Cognito

OIDC 페더레이션을 사용하는 선호 방식은 Amazon Cognito를 사용하는 거예요. 예를 들어 개발자 Adele은 점수·프로필 같은 사용자 데이터가 Amazon S3와 Amazon DynamoDB에 저장되는 모바일 게임을 만들고 있어요. Adele은 이 데이터를 기기 로컬에 저장하고 Amazon Cognito로 기기 간 동기화할 수도 있어요. 그녀는 보안과 유지보수상의 이유로 장기 AWS 보안 자격 증명을 게임에 배포하면 안 된다는 걸 알고 있어요. 또한 게임은 대규모 사용자가 있을 수 있다는 것도 알고 있어요. 이런 모든 이유로 각 플레이어마다 IAM에 새 사용자 아이덴티티를 만들고 싶지 않아요. 대신 사용자가 Login with Amazon, Facebook, Google, 또는 OpenID Connect(OIDC) 호환 IdP 같은 잘 알려진 외부 IdP로 이미 확립한 아이덴티티로 로그인하게 게임을 만들어요. 그녀의 게임은 이 프로바이더 중 하나의 인증 메커니즘을 활용해 사용자의 아이덴티티를 검증할 수 있어요.

모바일 앱이 그녀의 AWS 리소스에 접근할 수 있게 하기 위해 Adele은 먼저 선택한 IdP에서 개발자 ID로 등록해요. 또한 각 프로바이더에 애플리케이션을 구성해요. 게임용 Amazon S3 버킷과 DynamoDB 테이블이 있는 그녀의 AWS 계정에서 Amazon Cognito로 게임이 필요로 하는 권한을 정확히 정의한 IAM 역할을 만들어요. OIDC IdP를 사용한다면, 그녀의 AWS 계정의 Amazon Cognito identity pool과 IdP 사이의 신뢰를 확립하기 위해 IAM OIDC 아이덴티티 프로바이더 엔터티도 만들어요.

앱 코드에서 Adele은 이전에 구성한 IdP의 로그인 인터페이스를 호출해요. IdP가 사용자 로그인에 대한 모든 세부 사항을 처리하고, 앱은 프로바이더에서 OAuth 접근 토큰이나 OIDC ID 토큰을 받아요. Adele의 앱은 이 인증 정보를 AWS 접근 키 ID, 비밀 접근 키, 세션 토큰으로 구성된 임시 보안 자격 증명 집합과 교환할 수 있어요. 그런 다음 앱은 이 자격 증명으로 AWS가 제공하는 웹 서비스에 접근할 수 있어요. 앱은 수임하는 역할에 정의된 권한으로 제한돼요.

다음 그림은 Login with Amazon을 IdP로 사용했을 때 이 방식이 동작하는 단순화된 흐름을 보여줘요. 2단계에서는 폭도 Facebook, Google, 또는 OIDC 호환 IdP를 사용할 수 있지만, 여기엔 표시되지 않았어요.

  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의 Basic(Classic) 워크플로를 사용해 AssumeRoleWithWebIdentity로 AWS STS에서 토큰을 가져올 수도 있어요. 자세한 내용은 Amazon Cognito 개발자 가이드의 Identity pools(페더레이션 아이덴티티) 인증 흐름을 참고하세요.
  5. 임시 보안 자격 증명은 앱이 작동하는 데 필요한 모든 AWS 리소스에 접근하는 데 사용될 수 있어요. 임시 보안 자격 증명에 연결된 역할과 할당된 정책이 무엇에 접근할 수 있는지 결정해요.

앱이 Amazon Cognito로 사용자를 인증하고 앱에 AWS 리소스 접근 권한을 주도록 구성하려면 다음 프로세스를 사용하세요. 이 시나리오의 구체적인 단계는 Amazon Cognito 문서를 참고하세요.

  1. (선택) Login with Amazon, Facebook, Google, 또는 다른 OpenID Connect(OIDC) 호환 IdP에서 개발자로 등록하고 프로바이더에 하나 이상의 앱을 구성해요. 이 단계는 선택 사항인데, Amazon Cognito가 사용자의 인증되지 않은(게스트) 접근도 지원하기 때문이에요.
  2. AWS Management Console에서 Amazon Cognito로 이동해요. Amazon Cognito 마법사로 identity pool을 만들어요. identity pool은 Amazon Cognito가 앱용 최종 사용자 아이덴티티를 정리해서 보관하는 컨테이너예요. identity pool을 앱 간에 공유할 수 있어요. identity pool을 설정하면 Amazon Cognito가 인증된 아이덴티티용과 인증되지 않은 "게스트" 아이덴티티용으로 하나 또는 두 개의 IAM 역할을 만들어, Amazon Cognito 사용자의 권한을 정의해요.
  3. 앱에 AWS Amplify를 통합하고 Amazon Cognito 사용에 필요한 파일을 import 해요.
  4. identity pool ID, AWS 계정 번호, identity pool과 연결한 역할의 ARN을 전달해 Amazon Cognito 자격 증명 프로바이더 인스턴스를 만들어요. AWS Management Console의 Amazon Cognito 마법사가 시작을 돕는 샘플 코드를 제공해요.
  5. 앱이 AWS 리소스에 접근할 때 자격 증명 프로바이더 인스턴스를 클라이언트 객체에 전달하면, 클라이언트에 임시 보안 자격 증명이 전달돼요. 자격 증명의 권한은 이전에 정의한 역할에 기반해요.

자세한 내용은 다음을 참고하세요.

  • AWS Amplify Framework 문서의 로그인(Android)
  • AWS Amplify Framework 문서의 로그인(iOS)

모바일 앱용 OIDC 페더레이션

최상의 결과를 위해 거의 모든 OIDC 페더레이션 시나리오에서 Amazon Cognito를 아이덴티티 브로커로 사용하세요. Amazon Cognito는 사용하기 쉽고 익명(인증되지 않은) 접근, 기기·프로바이더 간 사용자 데이터 동기화 같은 추가 기능을 제공해요. 하지만 AssumeRoleWithWebIdentity API를 수동으로 호출해 OIDC 페더레이션을 사용하는 앱을 이미 만들었다면 계속 사용해도 되고 앱은 정상 동작해요.

Amazon Cognito 없이 OIDC 페더레이션을 사용하는 일반적인 과정은 다음과 같아요.

  1. 외부 아이덴티티 프로바이더(IdP)에서 개발자로 등록하고 앱에 IdP를 구성해요. IdP가 앱에 고유 ID를 줘요. (IdP마다 이 과정에 다른 용어를 써요. 이 개요는 앱을 IdP에 식별하는 과정을 위해 configure라는 용어를 써요.) 각 IdP는 그 IdP에 고유한 앱 ID를 주므로, 같은 앱을 여러 IdP에 구성하면 앱이 여러 앱 ID를 가지게 돼요. 각 프로바이더에 여러 앱을 구성할 수 있어요.
    • 다음 외부 링크는 흔히 쓰는 아이덴티티 프로바이더(IdP) 사용에 대한 정보를 제공해요:
      • Login with Amazon Developer Center
      • Facebook 개발자 사이트의 Facebook 로그인을 앱·웹사이트에 추가
      • Google 개발자 사이트의 로그인에 OAuth 2.0(OpenID Connect) 사용
    • 중요
      Google, Facebook, Amazon Cognito의 OIDC 아이덴티티 프로바이더를 사용한다면, AWS Management Console에 별도의 IAM 아이덴티티 프로바이더를 만들지 마세요. AWS는 이 OIDC 아이덴티티 프로바이더를 내장해 사용할 수 있게 제공해요. 다음 단계를 건너뛰고 아이덴티티 프로바이더로 새 역할 만들기로 바로 이동하세요. Google, Facebook, Amazon Cognito가 아닌 OIDC 호환 IdP를 사용한다면 그 IdP용 IAM 아이덴티티 프로바이더 엔터티를 만들어요.
  2. IAM에서 하나 이상의 역할을 만들어요. 각 역할에 대해 누가 역할을 수임할 수 있는지(트러스트 정책)와 앱 사용자가 가진 권한(권한 정책)을 정의해요. 일반적으로 앱이 지원하는 각 IdP마다 역할 하나를 만들어요. 예를 들어 사용자가 Login with Amazon으로 로그인하면 앱이 수임하는 역할 하나, 같은 앱이 Facebook으로 로그인하면 두 번째 역할, Google로 로그인하면 세 번째 역할을 만들 수 있어요. 신뢰 관계의 경우 IdP(예: Amazon.com)를 Principal(신뢰할 수 있는 엔터티)로 지정하고, IdP가 할당한 앱 ID와 일치하는 Condition을 포함해요. 다른 프로바이더용 역할의 예시는 제3자 아이덴티티 프로바이더용 역할 만들기를 참고하세요.
  3. 애플리케이션에서 IdP로 사용자를 인증해요. 구체적인 방법은 사용하는 IdP(Login with Amazon, Facebook, Google)와 앱이 실행되는 플랫폼에 따라 달라져요. 예를 들어 Android 앱의 인증 방식은 iOS 앱이나 JavaScript 기반 웹 앱과 다를 수 있어요.
  4. 일반적으로 사용자가 아직 로그인하지 않았다면 IdP가 로그인 페이지 표시를 처리해요. IdP가 사용자를 인증한 뒤에는 사용자에 대한 정보가 담긴 인증 토큰을 앱에 반환해요. 포함되는 정보는 IdP가 노출하는 것과 사용자가 공유하려는 정보에 따라 달라져요. 이 정보를 앱에서 사용할 수 있어요.
  5. 앱에서 임시 보안 자격 증명을 요청하기 위해 AssumeRoleWithWebIdentity 작업에 서명되지 않은 호출을 만들어요. 요청에서 IdP의 인증 토큰을 전달하고, 그 IdP용으로 만든 IAM 역할의 ARN을 지정해요. AWS는 토큰이 신뢰되고 유효한지 확인하고, 유효하다면 요청에서 지명한 역할의 권한을 가진 임시 보안 자격 증명을 앱에 반환해요. 응답에는 IdP가 사용자와 연결한 고유 사용자 ID 같은 IdP의 사용자 메타데이터도 포함돼요.
  6. AssumeRoleWithWebIdentity 응답의 임시 보안 자격 증명으로 앱은 AWS API 작업에 서명된 요청을 보내요. IdP의 사용자 ID 정보로 앱에서 사용자를 구분할 수 있어요. 예를 들어 사용자 ID를 접두사나 접미사로 포함한 Amazon S3 폴더에 객체를 넣을 수 있어요. 이렇게 하면 그 ID를 가진 사용자만 접근할 수 있도록 폴더를 잠그는 접근 제어 정책을 만들 수 있어요. 자세한 내용은 AWS STS 페더레이션 사용자 프린시펄을 참고하세요.
  7. 앱은 임시 보안 자격 증명을 캐시해서, 앱이 AWS에 요청을 보낼 때마다 새 자격 증명을 받지 않아도 되게 해요. 기본적으로 자격 증명은 1시간 동안 유효해요. 자격 증명이 만료되면(또는 그 전에) AssumeRoleWithWebIdentity를 다시 호출해 새 임시 보안 자격 증명 집합을 얻어요. IdP와 그들이 토큰을 관리하는 방식에 따라, 새 AssumeRoleWithWebIdentity 호출 전에 IdP의 토큰을 새로 고쳐야 할 수도 있어요 — IdP의 토큰도 보통 고정 시간 후에 만료되기 때문이에요. AWS SDK for iOS나 AWS SDK for Android를 사용한다면 AmazonSTSCredentialsProvider 동작을 사용할 수 있는데, 이 동작이 IAM 임시 자격 증명을 필요에 따라 새로 고치는 것을 포함해 관리해요.

더 알아보기 (Learn more)