AWS Cognito를 사용하여 웹 및 iOS 앱에 대한 사용자 인증(1부)

수년에 걸쳐 저는 처음부터 최소 3개의 사용자 관리 시스템을 구축했습니다. 접근 방식의 대부분은 상용구를 기반으로 할 수 있지만 항상 특정 클라이언트에 맞게 사용자 지정해야 하는 몇 가지 핵심 항목이 있습니다. 이것은 사용자 관리, 인증 및 권한 부여 서비스의 전체 범주가 이러한 요구를 충족시키기 위해 생겨난 것에 대한 우려로 충분합니다. Auth0와 같은 서비스에는 개발자가 통합할 수 있는 사용자 및 ID 관리를 기반으로 하는 전체 솔루션이 있습니다.

이 기능을 제공하는 서비스 중 하나는 Amazon Web Services(AWS') Cognito입니다. Cognito는 사용자가 귀하가 만든 웹 및 모바일 애플리케이션에 가입하고 로그인할 수 있도록 하는 도구입니다. 이 기능 외에도 사용자 데이터를 오프라인으로 저장할 수 있으며 이 데이터의 동기화를 제공합니다. Amazon이 말했듯이 "Amazon Cognito를 사용하면 사용자 관리, 인증 및 장치 간 동기화를 처리하는 솔루션을 구축, 보호 및 확장하는 것에 대해 걱정하는 대신 훌륭한 앱 경험을 만드는 데 집중할 수 있습니다."

작년에 Amazon은 Cognito 서비스에 맞춤형 사용자 풀을 추가했습니다. 이 기능은 이제 나와 다른 개발자가 대부분의 사용 사례에 맞는 유연성과 함께 완벽하고 사용자 지정 가능한 크로스 플랫폼 사용자 관리 시스템을 갖추는 데 필요한 것을 제공합니다. 그 이유를 이해하려면 사용자 관리가 무엇이며 어떤 문제를 해결하는지 간단히 살펴봐야 합니다.

이 기사에서는 대부분의 시간을 필요에 맞게 사용자 풀을 구성하는 프로세스를 살펴보는 데 할애할 것입니다. 그런 다음 이 사용자 풀을 iOS 애플리케이션과 통합하고 사용자가 로그인하여 사용자 계정과 연결된 속성을 가져올 수 있도록 합니다. 결국 우리는 제한된 데모 애플리케이션을 갖게 될 것이지만 사용자 관리의 핵심을 처리하는 애플리케이션이 될 것입니다. 또한, 이것이 적용된 후에는 이에 대해 좀 더 자세히 설명하는 후속 기사가 있을 것입니다.

사용자 관리에서 무엇이 필요합니까?

모바일 또는 웹 앱이 있는 경우 사용자 관리 측면에서 정확히 무엇이 필요합니까? 사용자 로그인이 가장 먼저 생각할 수 있지만 여기서 멈출 수는 없습니다. 대부분의 웹 및 모바일 앱 사용 사례에서 작동하는 유연한 사용자 관리 시스템을 원한다면 다음 기능이 필요합니다.

• 사용자 이름 및 비밀번호 로그인;
• 안전한 암호 해싱 및 저장
• 비밀번호 변경
• 암호 정책 및 유효성 검사
• 사용자 수명 주기 트리거(환영 이메일, 작별 이메일 등)
• 사용자 속성(이름, 성 등)
• 사용자별 필수 구성 및 선택적 속성
• 잊어버린 비밀번호 처리
• SMS를 통한 전화번호 확인
• 이메일 확인;
• 권한에 기반한 엔드포인트에 대한 API 액세스
• 모바일 장치에 대한 액세스 토큰의 보안 저장
• 모바일 장치에 대한 사용자 속성의 오프라인 저장;
• 온라인 및 오프라인 상태에 대한 사용자 속성 동기화
• 다단계 인증.

사용자 관리가 처음에는 로그인 시스템처럼 보일 수 있지만 시스템이 대부분의 사용 사례를 처리할 수 있을 만큼 충분히 유연하려면 기능이 그 이상이어야 합니다. 이것은 분명히 사용자 이름과 암호를 훨씬 능가합니다.

여기서 한 가지 추가 항목이 필요합니다. 바로 보안입니다. 모든 사용자 관리 시스템의 요구 사항 중 하나는 시스템 전체의 보안에 대해 지속적으로 평가되어야 한다는 것입니다. 많은 사용자 지정 사용자 관리 시스템에는 단순히 수정되지 않은 취약점이 있습니다. 작년 한 해 동안 Dropbox, Dailymotion, Twitter 및 Yahoo와 같은 회사의 사용자 관리 시스템에 대한 보안 침해가 있었습니다. 사용자 지정 솔루션을 구축하기로 선택한 경우 시스템 보안을 유지해야 합니다.

Amazon Cognito 입력

Amazon Cognito는 유연하고 확장 가능한 사용자 관리 시스템을 웹 및 모바일 애플리케이션에 통합할 수 있는 관리형 서비스입니다. Cognito는 서비스를 활용하는 두 가지 고유한 방법을 제공합니다. Facebook과 같은 소셜 네트워크를 통한 로그인을 허용하는 연합 ID와 특정 앱 또는 애플리케이션 제품군에 대해 완전히 맞춤화된 사용자 관리 기능을 제공하는 사용자 풀입니다.

연합 ID는 사용자가 Facebook(또는 Google, Amazon 등)으로 로그인할 수 있도록 하려는 경우에 적합하지만, 이는 사용자 관리 프로세스의 일부가 Facebook에 아웃소싱됨을 의미합니다. 어떤 경우에는 이것이 허용될 수 있지만 사용자는 Facebook 계정을 애플리케이션에 연결하는 것을 원하지 않을 수 있습니다. 또한 더 많은 사용자 수명 주기를 직접 관리할 수 있으며 이를 위해 연합 ID는 유연하지 않습니다. 오늘 기사에서는 대부분의 사용 사례에 맞는 강력한 사용자 관리 플랫폼에 필요한 유연성을 제공하기 때문에 사용자 풀에 중점을 둘 것입니다. 이러한 방식으로 대부분의 프로젝트에서 사용할 수 있는 접근 방식을 갖게 됩니다.

이것은 AWS 서비스이기 때문에 Cognito를 사용하면 다른 이점이 있습니다. Cognito는 API Gateway와 통합하여 Cognito 로그인에서 반환된 토큰을 기반으로 API 액세스 권한을 부여하는 간편한 방법을 제공합니다. 또한 모바일 애플리케이션에 이미 다른 AWS 서비스를 활용하고 있는 경우 사용자 풀을 AWS 자격 증명에 대한 자격 증명 공급자로 사용할 수 있습니다.

다른 AWS 서비스와 마찬가지로 관련 비용이 있습니다. Cognito의 가격은 월간 활성 사용자(MAU)를 기준으로 합니다. 대부분의 개발자에게 희소식은 사용자 지정 사용자 풀을 사용할 때 50,000 MAU로 제한되는 무기한 무료 계층이 있다는 것입니다. 대규모 응용 프로그램이 있는 경우 많은 수의 사용자가 사용자 관리에 대한 새로운 접근 방식을 시험해 볼 수 있습니다. 하지만 사용자가 50,000명을 넘지 않는 경험을 하신 분들이 많을 거라 생각합니다. 이 경우 핵심 사용자 관리는 거의 무료입니다. 이에 대한 유일한 예외는 Lambda, SNS 및 S3와 같이 사용자 관리 프로세스의 일부로 활용하게 될 다른 AWS 서비스입니다.

사용자 풀 생성

사용자 풀을 모바일 애플리케이션에 통합하는 첫 번째 단계는 Cognito 사용자 풀을 만드는 것입니다. 이렇게 하면 예제 애플리케이션에 연결하는 데 필요한 구성 값이 제공됩니다. 새 사용자 풀을 생성하려면 Amazon Cognito 콘솔에서 제공되는 마법사를 살펴보십시오.

사용자 풀을 만드는 과정을 살펴보겠습니다. 이것은 긴 과정이라는 것을 경고해야 합니다. 여러면에서 이것은 유연성의 영역을 보여주기 때문에 좋은 것입니다. 그러나, 당신은 이것을 위해 커피 한 잔을 들고 버클을 채우고 싶을 것입니다.

1. 이름

사용자 풀 생성의 초기 단계에는 사용자 풀의 이름을 설정하고 사용자 풀을 생성하기 위해 취할 접근 방식을 선택하는 작업이 포함됩니다. 기본값을 검토하거나 설정을 "단계별로" 검토할 수 있습니다. 사용자 풀이 구성되는 방식에 대해 제대로 알고 싶기 때문에 "단계별 설정" 옵션을 선택합니다.

2. 속성

속성을 구성하려면 약간의 생각이 필요합니다. 각 사용자 풀에 대해 시스템에 저장할 속성과 필요한 속성을 결정해야 합니다. 시스템에서 필수 값을 적용하므로 나중에 변경할 수 없습니다. 여기에서 가장 좋은 방법은 여기에서 필요에 따라 진정으로 필수적인 값만 표시하는 것입니다. 또한 사용자가 자신의 이메일 주소로 로그인할 수 있도록 하려면 해당 주소를 별칭으로 표시해야 합니다.

사용자 정의 값을 포함하려면 여기에서도 수행해야 합니다. 각 사용자 정의 값에는 유형, 선택적 유효성 검사 규칙 및 변경 가능(변경 가능) 또는 변경 불가(변경 불가) 옵션이 있습니다. 사용자 정의 속성은 25개로 제한됩니다.

마지막으로 여기에서 사용자 이름에 대해 짚고 넘어갈 필요가 있습니다. 각 사용자의 사용자 이름 값은 변경할 수 없습니다(변경 불가능). 즉, 대부분의 경우 이 값을 자동으로 생성하는 것이 합리적입니다. 이것이 "선호하는 사용자 이름" 값이 존재하는 이유입니다. 사용자가 편집할 수 있는 사용자 이름 값을 갖도록 하려면 "선호하는 사용자 이름" 속성을 별칭으로 표시하기만 하면 됩니다. 사용자가 단순히 자신의 이메일 주소로 로그인하도록 하려면 "email" 속성을 필수 및 별칭으로 모두 표시해야 합니다.

데모 응용 프로그램의 경우 "이메일", "이름" 및 "성"을 필수 항목으로 지정했습니다.

3. 정책

속성을 구성한 후 계정에 대한 정책을 구성할 수 있습니다. 구성할 첫 번째 정책은 암호 정책입니다. 이 정책을 사용하면 길이와 숫자, 특수 문자, 대문자 또는 소문자가 필요한지 여부를 모두 구성할 수 있습니다. 이 정책은 사용자가 입력한 암호와 관리자가 사용자에게 할당한 암호 모두에 적용됩니다.

다음 정책은 사용자 가입에 관한 것입니다. 공개 응용 프로그램의 경우 사용자가 직접 등록하도록 허용할 수 있습니다. 그러나 응용 프로그램 유형에 따라 가입을 제한하고 시스템을 초대 전용으로 설정할 수 있습니다. 또한 이러한 초대가 사용되지 않을 경우 만료되는 시간을 구성해야 합니다.

데모 응용 프로그램의 경우 사용자가 스스로 등록할 수 없도록 하는 것을 제외하고 기본값만 사용하도록 선택했습니다. 이러한 값이 있으면 검증을 진행할 수 있습니다.

4. 검증

확인 단계에서는 이메일 및 전화 확인은 물론 다단계 인증을 설정할 수 있습니다. 이 기능은 콘솔에서 비교적 쉽게 설정할 수 있지만 전화번호를 확인하거나 다단계 인증을 사용하려면 AWS SNS에 대한 지출 증가를 요청해야 합니다.

데모 애플리케이션의 경우 기본값만 사용하도록 선택했습니다.

5. 메시지 사용자 정의

이 단계를 통해 사용자 풀이 보낼 이메일 및 SMS 메시지는 물론 "보낸 사람" 및 "답장" 이메일 주소를 사용자 지정할 수 있습니다. 데모 응용 프로그램의 목적을 위해 여기에 기본값을 그대로 두고 진행하겠습니다.

6. 태그

AWS를 처음 사용하는 경우 태그를 지정하지 않아도 됩니다. 그러나 조직에서 AWS를 정기적으로 사용하는 경우 태그를 통해 지출을 분석하고 IAM으로 권한을 할당할 수 있습니다. 예를 들어 일부 조직에서는 환경(개발, 스테이징, 프로덕션) 및 프로젝트별로 태그를 지정합니다.

이 단계에서 무엇을 입력하든 데모 애플리케이션에는 영향을 미치지 않습니다.

7. 장치

다음 단계에서는 사용자 풀이 사용자의 장치를 기억할지 여부를 정의할 수 있습니다. 이것은 특정 계정에 로그인한 기기를 확인할 수 있는 추가 보안 단계입니다. 이것은 다단계 인증(MFA)을 활용할 때 추가적인 가치가 있습니다. 장치가 기억되면 로그인할 때마다 MFA 토큰을 요구하지 않도록 선택할 수 있습니다.

데모 응용 프로그램의 목적을 위해 값을 "항상"으로 설정하기로 선택했습니다.

8. 앱 클라이언트

사용자 풀을 사용하려는 각 애플리케이션(iOS 애플리케이션, 웹 애플리케이션, Android 애플리케이션 등)에 대해 앱을 생성해야 합니다. 그러나 사용자 풀이 생성된 후에 돌아와서 생성할 수 있으므로 아직 모두 추가할 필요는 없습니다.

각 응용 프로그램에는 구성할 수 있는 여러 값이 있습니다. 이 데모 애플리케이션의 경우 앱에 이름을 지정한 다음 기본값을 그대로 둡니다. 다음으로 각 앱이 읽고 쓸 수 있는 사용자 속성을 구성할 수 있습니다.

이메일 주소, 성 및 이름이 애플리케이션에서 모두 읽고 쓸 수 있는 한 이 단계에서 원하는 값을 설정할 수 있습니다. 계속하기 전에 "앱 클라이언트 만들기" 옵션을 클릭해야 합니다.

9. 방아쇠

트리거를 사용하면 Lambda 함수를 사용하여 사용자 수명 주기 프로세스를 완전히 사용자 지정할 수 있습니다. 예를 들어 회사 도메인의 이메일 주소를 가진 사용자만 가입할 수 있도록 하려면 "사전 가입" 트리거에 대한 Lambda 함수를 추가하여 이 검증을 수행하고 다음과 같은 가입 요청을 거부할 수 있습니다. 통과하지 않습니다.

데모 애플리케이션의 경우 트리거를 추가하지 않습니다.

10. 검토

나는 이것이 길고 힘든 과정처럼 보였을 수도 있다는 것을 깨달았습니다. 그러나 사용자 풀을 만드는 각 단계에는 솔루션이 더 많은 사용 사례에 맞도록 하는 유연성이 있다는 점을 명심하십시오. 그리고 이제 여러분이 듣고 싶어 하는 소식이 있습니다. 이것이 마지막 단계입니다.

설정을 검토하여 데모 애플리케이션에 대해 올바르게 구성했는지 확인하십시오. 이 화면에서 돌아가서 이전 설정을 편집할 수 있습니다. 사용자 풀이 생성되면 필수 속성과 같은 일부 구성 값을 변경할 수 없습니다.

새 사용자 풀이 생성되면 이제 iOS용 AWS SDK를 사용하여 샘플 iOS 애플리케이션에 통합할 수 있습니다.

사용자 풀에 대한 iOS 애플리케이션 설정

Cognito와 통합되어 사용자가 로그인, 로그아웃, 이름과 성을 입력하고 암호를 설정할 수 있도록 하는 샘플 iOS 애플리케이션을 만들었습니다. 이 초기 데모에서는 사용자 등록이 포함되어 있지 않으므로 Cognito의 콘솔을 사용하여 테스트할 새 사용자를 추가했습니다.

이 애플리케이션의 코드는 내 GitHub 리포지토리에서 찾을 수 있습니다.

종속성 구성

이 애플리케이션은 종속성을 관리하기 위해 CocoaPods를 사용합니다. 이 시점에서 유일한 종속성은 Cognito 사용자 풀과 관련된 AWS iOS SDK의 특정 부분입니다.

(CocoaPods에 대한 전체 설명은 이 기사의 범위를 벗어납니다. 그러나 이 개념이 생소한 경우 CocoaPods 웹사이트의 리소스가 시작 및 실행에 도움이 될 것입니다.)

이 응용 프로그램에 대한 Podfile의 내용은 아래에서 볼 수 있습니다.

 source 'https://github.com/CocoaPods/Specs.git' platform :ios, '10.0' use_frameworks! target 'CognitoApplication' do pod 'AWSCore', '~> 2.5.5' pod 'AWSCognitoIdentityProvider', '~> 2.5.5' end

CocoaPods가 컴퓨터에 설치되어 있다고 가정하고 pod install 을 실행하면 필요한 종속 항목이 자동으로 설치됩니다.

사용자 풀 구성

다음 단계는 사용자 풀 및 클라이언트 응용 프로그램에 대한 값을 포함하는 것입니다. 데모 애플리케이션은 이 정보를 가져올 CognitoApplication/CognitoConfig.plist 파일을 사용하도록 구성되어 있습니다. 4가지 값을 정의해야 합니다.

• region (문자열)
  사용자 풀을 생성한 지역입니다. 이것은 us-east-1 또는 ap-southeast-1 과 같은 표준 지역 식별자여야 합니다.
• poolId (문자열)
  생성한 사용자 풀의 ID입니다.
• clientId (문자열)
  이것은 사용자 풀에 연결한 앱의 일부로 구성된 clientId 입니다.
• clientSecret (문자열)
  이것은 사용자 풀에 연결한 앱의 일부로 구성된 clientSecret 입니다.

해당 파일과 적절한 값이 있으면 데모 응용 프로그램을 시작할 수 있습니다. 시작하는 동안 예외가 발생하면 아래에 표시된 4가지 값을 각각 포함하고 파일이 올바른 디렉토리에 있는지 확인하십시오.

앱 대리인 통합

Amazon Cognito와의 통합의 핵심은 애플리케이션의 AppDelegate 내에서 발생합니다. 첫 번째 단계는 로깅을 설정하고 사용자 풀에 연결했는지 확인하는 것입니다. 해당 프로세스의 일부로 AppDelegate 를 사용자 풀의 대리자로 할당합니다. 이 기본 예제의 경우 AppDelegate 내에서 이 논리를 유지할 수 있습니다. 더 큰 프로젝트의 경우 이것을 다른 곳에서 처리하는 것이 합리적일 수 있습니다.

 func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool { // set up logging for AWS and Cognito AWSDDLog.sharedInstance.logLevel = .verbose AWSDDLog.add(AWSDDTTYLogger.sharedInstance) // set up Cognito config self.cognitoConfig = CognitoConfig() // set up Cognito setupCognitoUserPool() return true } func setupCognitoUserPool() { // we pull the needed values from the CognitoConfig object // this just pulls the values in from the plist let clientId:String = self.cognitoConfig!.getClientId() let poolId:String = self.cognitoConfig!.getPoolId() let clientSecret:String = self.cognitoConfig!.getClientSecret() let region:AWSRegionType = self.cognitoConfig!.getRegion() // we need to let Cognito know which region we plan to connect to let serviceConfiguration:AWSServiceConfiguration = AWSServiceConfiguration(region: region, credentialsProvider: nil) // we need to pass it the clientId and clientSecret from the app and the poolId for the user pool let cognitoConfiguration:AWSCognitoIdentityUserPoolConfiguration = AWSCognitoIdentityUserPoolConfiguration(clientId: clientId, clientSecret: clientSecret, poolId: poolId) AWSCognitoIdentityUserPool.register(with: serviceConfiguration, userPoolConfiguration: cognitoConfiguration, forKey: userPoolID) let pool:AWSCognitoIdentityUserPool = AppDelegate.defaultUserPool() // we need to set the AppDelegate as the user pool's delegate, which will get called when events occur pool.delegate = self }

이 구성이 완료되면 사용자 풀에 대한 대리자 메서드를 구성해야 합니다. 우리가 구현하는 프로토콜은 AWSCognitoIdentityInteractiveAuthenticationDelegate 입니다. 이 대리자는 사용자가 로그인하거나, 비밀번호를 재설정하거나, 다단계 인증 코드를 제공해야 하거나, 사용자에게 기기를 기억하기를 원하는지 여부를 사용자에게 쿼리해야 할 때마다 호출됩니다. 이 예에서는 startPasswordAuthentication 및 startNewPasswordRequired 메서드만 구현하면 됩니다.

 extension AppDelegate: AWSCognitoIdentityInteractiveAuthenticationDelegate { // This method is called when we need to log into the application. // It will grab the view controller from the storyboard and present it. func startPasswordAuthentication() -> AWSCognitoIdentityPasswordAuthentication { if(self.navigationController == nil) { self.navigationController = self.window?.rootViewController as? UINavigationController } if(self.loginViewController == nil) { self.loginViewController = self.storyboard?.instantiateViewController(withIdentifier: "LoginViewController") as? LoginViewController } DispatchQueue.main.async { if(self.loginViewController!.isViewLoaded || self.loginViewController!.view.window == nil) { self.navigationController?.present(self.loginViewController!, animated: true, completion: nil) } } return self.loginViewController! } // This method is called when we need to reset a password. // It will grab the view controller from the storyboard and present it. func startNewPasswordRequired() -> AWSCognitoIdentityNewPasswordRequired { if (self.resetPasswordViewController == nil) { self.resetPasswordViewController = self.storyboard?.instantiateViewController(withIdentifier: "ResetPasswordController") as? ResetPasswordViewController } DispatchQueue.main.async { if(self.resetPasswordViewController!.isViewLoaded || self.resetPasswordViewController!.view.window == nil) { self.navigationController?.present(self.resetPasswordViewController!, animated: true, completion: nil) } } return self.resetPasswordViewController! } }

주목해야 할 한 가지 중요한 점은 이 두 메서드 모두 특정 프로토콜을 구현하는 뷰 컨트롤러를 반환한다는 것입니다. 예를 들어, LoginViewController 는 사용자가 로그인 프로세스를 완료할 수 있도록 하는 데 필요한 매개변수와 함께 호출되는 단일 메서드가 있는 AWSCognitoIdentityPasswordAuthentication 을 구현합니다.

인증 흐름

데모 애플리케이션에 이러한 모든 부분이 있으면 이제 로그인 프로세스 작업을 처음부터 끝까지 볼 수 있습니다. 응용 프로그램의 기본 보기에는 사용자 이름과 사용자의 이름과 성이 표시됩니다. 이를 수행하려면 다음 단계가 수행됩니다.

1. AppViewController 에서 viewDidLoad 메소드에서 fetchUserAttributes 메소드를 호출합니다. 사용자가 로그인하지 않은 경우 로그인 프로세스가 트리거됩니다.
2. AppDelegate 의 startPasswordAuthentication 메서드가 트리거됩니다. 이 메서드는 LoginViewController 를 로드하고 표시합니다.
3. LoginViewController 의 getDetails 메소드는 AWS SDK에 의해 호출됩니다. 여기에는 사용자가 로그인을 시도하도록 허용하는 데 사용할 수 있는 AWSTaskCompletionSource 의 인스턴스인 객체가 포함됩니다.
4. 사용자가 "로그인" 버튼을 누르면 로그인 자격 증명을 해당 개체에 전달합니다. 그러면 didCompleteStepWithError 메서드가 호출되고 그에 따라 결과를 처리할 수 있습니다. 오류가 없으면 뷰 컨트롤러를 닫을 수 있습니다.
5. 콘솔에서 사용자를 만든 경우 여기에서 처리할 또 다른 단계가 있습니다. 사용자에게 임시 비밀번호를 주었으므로 더 영구적인 비밀번호를 설정해야 합니다. 또한 주어진 이름과 성을 필수 매개변수로 설정했기 때문에 사용자도 입력할 수 있도록 해야 합니다. AWS SDK는 이를 감지하고 AppDelegate 에서 startNewPasswordRequired 메서드를 호출합니다. 그러면 ResetPasswordViewController 가 표시되고 AWSTaskCompletionSource 의 인스턴스가 설정됩니다.
6. ResetPasswordViewController 는 LoginViewController 와 거의 동일하게 작동합니다. 사용자에게 올바른 값을 요청한 다음 해당 값을 제출하기만 하면 됩니다. 이 프로세스가 성공적으로 완료되면 뷰 컨트롤러를 닫습니다.
7. 전체 로그인 프로세스가 완료되면 SDK는 Cognito에서 반환한 토큰을 안전하게 저장합니다. 그런 다음 마지막으로 사용자 세부 정보를 검색하고 이를 사용하여 AppViewController 에 사용자의 사용자 이름, 이름 및 성을 채울 수 있습니다.

결론

사용자 풀 설정 프로세스에는 여러 단계가 있을 수 있지만 이러한 단계는 탐색하기 쉽습니다. 또한 가능한 구성의 양은 대부분의 사용 사례를 지원할 수 있다는 확신을 줄 것입니다. Universal Mind에서 근무하는 동안 저는 Cognito가 사용자 관리를 위해 제공하는 기능을 활용하기 위해 기존 애플리케이션을 이전하는 여러 클라이언트와 협력했습니다.

사용자 관리 시스템을 정기적으로 구현해야 하는지 여부에 관계없이 모든 모바일 및 웹 개발자가 도구 상자에 있어야 하는 도구 입니다. 이 시리즈의 다음 기사에서는 더 많은 일반적인 사용자 관리 사용 사례를 구현하는 더 완전한 기능을 갖춘 데모 애플리케이션을 구현하여 Cognito의 기능을 좀 더 탐색하기 시작할 것입니다.

약간의 연습을 통해 하루 만에 이러한 모든 사용자 관리 사용 사례를 충족하는 새 애플리케이션을 설정하여 친구들에게 깊은 인상을 남길 수 있습니다. 하루 일과에 아주 좋습니다.

링크 및 리소스

• 아마존 코그니토
• "개발자 리소스", Amazon Cognito
• AWS 모바일 SDK
• "Swift용 CocoaPods 자습서: 시작하기", Joshua Greene, raywenderlich.com