인증 사용자 흐름

개요

인증 흐름의 목적은 사용자를 식별하고 결제 통합업체 (통합업체)에 인증하는 것입니다.

인증은 다른 방법에 대한 입력입니다. 특히 associateAccount 및 capture의 경우입니다. 즉, 인증 증명이 이 두 가지 방법에 대한 입력 (매개변수)으로 사용됩니다.

Google은 독립형 모드에서 인증 흐름을 사용하여 사용자를 확인할 수도 있습니다. 이 경우 다른 흐름에 대한 입력으로 사용되지 않으며, 사용자가 이 ID를 인증할 수 있는지 확인하기 위한 용도로만 사용됩니다.

온보딩 시 Google은 판매자와 협의하여 제품에 가장 적합한 인증 메커니즘을 선택합니다.

절차의 작동 방식

사용자를 인증하는 방법에는 두 가지가 있으며 각각 자체 흐름이 있습니다. 통합 시점에 어떤 방법을 사용할지 결정해야 합니다.

  1. 리디렉션 인증
  2. SMS-MT OTP 인증

리디렉션 인증

인증이 필요한 Google 사용자는 신원 확인을 위해 통합업체의 앱 또는 웹사이트로 리디렉션될 수 있습니다. 다음은 이 흐름의 단계에 대한 간략한 개요입니다.

  1. Google이 사용자를 인증할 수 있는 통합업체의 웹 또는 Android 앱으로 리디렉션합니다.
  2. 인증을 위해 AuthenticationRequest의 인증 requestId이 인증 증명으로 사용됩니다.
  3. 그러면 AuthenticationResponse이라는 서명된 응답이 생성됩니다.
  4. 그런 다음 앱 또는 웹사이트에서 사용자를 다시 Google로 리디렉션합니다.

리디렉션 인증은 웹 애플리케이션의 URL로 인코딩된 매개변수가 있는 HTTP GET 메서드를 사용합니다. Android 애플리케이션 인증에 Android 인텐트를 사용합니다. 인코딩에 관한 자세한 내용은 웹 인증을, Android 인텐트 매개변수에 관해서는 Android 인증을 참고하세요.

이러한 각 인증 메커니즘의 결과는 AuthenticationResponse이라는 서명된 응답입니다. 이 인텐트에는 인증 성공을 전달하기 위해 암호화되고 인코딩된 Google 표준 결제 인증 응답 (gspAuthenticationResponse)이 포함되어야 합니다. 독립형 모드에서 사용하는 경우 인증이 성공했는지 확인하는 데 gspResult 및 서명이 사용됩니다.

다음 시퀀스 다이어그램은 사용자의 브라우저, Google, 통합업체의 웹 애플리케이션 간의 상호작용을 보여줍니다.

리디렉션-웹 인증 흐름

웹 인증 흐름

객체의 목록과 각 객체가 나타내는 항목은 다음과 같습니다.

  • 사용자: Google 계정에 결제 수단을 추가하려는 사용자입니다.
  • Google UI: 이 경우 고객이 결제 수단 설정을 시작하는 Google 웹 인터페이스입니다.
  • Google 서버: 기타 인증 작업과 함께 인증 검사를 수행하는 Google의 백엔드 서버입니다.
  • 결제 통합업체 웹: 사용자가 계정을 보유한 통합업체의 웹사이트입니다.

이 인증 흐름에서는 이미 사용자가 Google 웹사이트 (Google UI)에 있고 결제 수단을 추가하려고 한다고 가정합니다. 모든 것이 여기에서 시작됩니다.

  1. Google UI가 인증 URL을 만들어 Google 서버 (백엔드)로 전송합니다. 이것이 인증 프로세스를 트리거하는 것입니다.
  2. Google 서버에서 인증 요청 (AuthenticationRequest)을 만듭니다.
  3. Google UI로 전송된 인증 요청입니다.
  4. 사용자에게 통합업체를 통해 ID를 인증해야 한다는 메시지가 표시됩니다.
  5. 사용자가 인증을 원한다고 응답하면 해당 메시지가 통합업체의 웹사이트로 전송됩니다.
  6. 결제 통합업체의 웹사이트에서 사용자 신원 확인을 요청합니다.
  7. 사용자가 신원을 증명하며 결제 통합업체의 웹사이트로 전송됩니다.
  8. 통합자는 제공된 증거 (메시지에서 인코딩된 authenticationResponse 사용)에 대한 응답 (authenticationResponse)을 생성합니다.
  9. 이 응답 URL은 사용자에게 전송됩니다.
  10. 응답 URL은 즉시 사용자로부터 Google UI로 전송됩니다.
  11. Google UI가 Google 서버에 응답을 보냅니다.
  12. Google 서버에서는 응답이 확인된 것으로 해석합니다.

다음 시퀀스 다이어그램은 사용자의 휴대전화, Google, 통합업체의 Android 애플리케이션 간의 상호작용을 보여줍니다.

리디렉션 Android 앱 인증 흐름

Android 앱 인증 흐름

객체와 각 객체가 나타내는 항목은 다음과 같습니다.

  • 사용자: Google 계정에 결제 수단을 추가하려는 사용자입니다.
  • Google UI: 고객이 결제 수단 설정을 시작하는 앱 인터페이스입니다.
  • Google 서버: 기타 인증 작업과 함께 인증 검사를 수행하는 Google의 백엔드 서버입니다.
  • 결제 통합업체 APK: 사용자가 통합업체 계정에 액세스할 수 있는 통합업체의 앱입니다.
  • 결제 통합업체 서버: 사용자 정보가 저장되는 통합업체의 백엔드 서버입니다.

이는 인증 흐름이므로 이미 사용자가 앱 (Google UI)을 사용하고 있으며 결제 수단을 추가하려고 한다고 가정합니다. 여기서 초기화가 시작됩니다.

  1. Google UI에서 인증 호출을 만들어 Google 서버 (백엔드)로 보냅니다.
  2. Google 서버에서 인증 요청 (AuthenticationRequest)을 만듭니다.
  3. Google 서버가 Google UI (앱)에 통화 APK를 보내 인증을 요청합니다.
  4. Google UI는 사용자 정보를 결제 통합업체 APK (AUTHENTICATE_V1(authReq))에 전송합니다.
  5. 결제 통합업체 APK가 결제 통합업체의 서버에 요청 (authReq)을 전송합니다.
  6. 결제 통합업체 서버가 결제 통합업체 APK에 챌린지를 다시 보냅니다.
  7. 결제 통합업체 APK가 사용자에게 챌린지를 다시 보냅니다.
  8. 사용자가 신원 증명을 제공하여 결제 통합업체 APK로 전송됩니다.
  9. 이 증명은 결제 통합업체 서버로 전송됩니다.
  10. 서버가 서명된 authenticationResponse를 만듭니다.
  11. 인증 응답이 성공하고 authResp 메시지가 결제 통합업체 APK로 전송됩니다.
  12. 성공 메시지 (authResp)는 결제 통합업체 APK에서 Google UI로 전송됩니다.
  13. Google UI가 Google 서버로 응답을 전송합니다.
  14. Google 서버는 성공 응답을 해석합니다.

SMS-MT OTP 인증

또 다른 인증 방법으로는 단문 메시지 서비스, 모바일 종료, 일회용 비밀번호 (SMS-MT OTP)가 있습니다. 이 메커니즘은 사용자의 전화번호를 활용하여 인증에 사용할 일회용 비밀번호를 전송합니다. Google은 통합업체에 사용자의 전화번호로 OTP를 전송하도록 요청하고 사용자가 OTP를 수신하여 Google 인터페이스에 입력하면 사용자를 인증합니다.

계정 만들기 절차는 다음과 같습니다.

  1. Google의 사용자 인터페이스 (UI)에 통합업체에 이미 등록된 전화번호를 입력하라는 메시지가 표시됩니다.
  2. 사용자가 Google UI에 전화번호를 입력합니다.
  3. Google은 통합업체 (sendOtp 메서드 호출)를 트리거하여 사용자에게 일회용 비밀번호 (OTP)를 전송합니다.
  4. 사용자가 OTP가 포함된 SMS 메시지를 수신합니다.
  5. 그런 다음 사용자는 받은 OTP (capture, associateAccount, verifyOtp의 입력으로 사용됨)를 Google 인터페이스에 입력하여 사용자를 인증합니다. 이는 인증을 증명하는 것입니다.

독립형 모드에서는 OTP 값을 확인하기 위해 verifyOtp 메서드만 호출됩니다.

다음 시퀀스 다이어그램은 OTP를 보낼 때 사용자 휴대전화, Google, 통합업체 간의 상호작용을 보여줍니다.

전화 (OTP 전송) 인증 흐름

전화 (OTP) 인증 흐름

다음은 다이어그램에 포함된 객체 목록과 각 객체가 나타내는 의미입니다.

  • 사용자: Google 계정에 결제 수단을 추가하려는 사용자입니다.
  • Google UI: 이 경우 고객이 결제 수단을 설정하기 시작하는 Google 웹사이트 또는 전화 앱입니다. 참고: Google UI가 전화 앱인 경우 휴대전화가 이미 사용자의 전화번호를 알고 있으므로 처음 몇 단계는 건너뜁니다.
  • Google 서버: 기타 인증 작업과 함께 인증 검사를 수행하는 Google의 백엔드 서버입니다.
  • 결제 통합업체 서버: 사용자 정보가 저장되는 통합업체의 백엔드 서버입니다.

OTP 인증 흐름이므로 이미 사용자가 Google 전화 앱 또는 웹사이트 (Google UI)에서 결제 수단을 추가하려고 한다고 가정합니다. 여기서 초기화가 시작됩니다.

  1. Google UI (전화 또는 웹사이트)에서 사용자에게 전화번호를 묻습니다.
  2. 사용자가 Google UI에 전화번호를 입력합니다.
  3. Google UI는 번호 (sendChallenge(phoneNum))를 Google 서버로 전송합니다.
  4. Google 서버가 결제 통합업체 서버 (SendOtp(phoneNum))에 일회용 비밀번호를 전송하라는 요청을 보냅니다.
  5. 결제 통합업체 서버가 사용자에게 일회용 비밀번호 (OTP)를 전송합니다.
  6. 결제 통합업체 서버는 5번에서 Google의 요청에 OTP가 성공적으로 전송되었음을 알립니다.
  7. 사용자가 이 OTP를 Google UI (전화 또는 웹사이트)에 입력합니다.
  8. Google UI는 OTP를 Google 서버로 전송하며, 최종적으로 확인을 위해 결제 통합업체에 OTP를 전송합니다. 이를 통해 사용자의 신원을 확인하고 사용자를 인증합니다.

인증 및 재인증

인증이 발생할 수 있는 시점은 다음 두 가지입니다.

  1. 초기 인증—사용자를 식별하고 인증하는 데 사용됩니다. 초기 인증이 associateAccount 메서드에 대한 입력으로 사용됩니다.
  2. 재인증: 독립형 또는 capture에 대한 입력과 같은 다른 모든 컨텍스트에서 사용됩니다.

재인증은 초기 인증과 다릅니다. 사용자를 재식별할 필요 없이 단순히 재인증하기 위함입니다. 재인증은 Google에서 사용자에게 특정 계정을 소유하고 있음을 증명하는 데 사용되며 이는 Google의 재량에 따라 이루어집니다.

이 프로세스에서는 associationId라는 참조가 (연결 흐름에서) 원래 연결에 제공됩니다. 연결 흐름 중에 associateAccount 메서드 호출을 통해 제공됩니다. associationId는 챌린지할 계정을 식별합니다. 보안을 위해 사용자는 로그인 질문이 표시되는 계정을 변경할 수 없어야 합니다.

SMS-MT OTP 재인증을 위해 Google에서는 sendOtp에 처음 통화할 때 제공받은 전화번호를 고정 번호로 보관합니다. 보안을 위해 다시 변경할 수 없습니다.

다음은 Google에서 구매하기 전에 본인 확인 요청 (재인증)을 하기로 하는 흐름의 예입니다.

재인증 흐름

재인증 흐름

객체 목록과 객체가 나타내는 내용은 다음과 같습니다.

  • 사용자: 구매하려는 사용자입니다.
  • Google UI: 이 경우 고객이 구매를 시작하는 Google 웹사이트 또는 전화 앱입니다.
  • 결제 통합업체 UI: 사용자가 통합업체를 통해 계정 정보에 액세스할 수 있는 고객 대상 웹사이트 또는 앱입니다.
  • Google 서버: 다른 작업과 함께 재인증 검사를 수행하는 Google의 백엔드 서버입니다.
  • 결제 통합업체 서버: 사용자 정보가 저장되는 통합업체의 백엔드 서버입니다.

재인증 흐름은 고객이 구매를 시작하면 시작됩니다. 이렇게 하면 사용자를 다시 인증하는 흐름이 초기화됩니다.

  1. 사용자가 상품 또는 서비스를 구매하기로 결정합니다.
  2. 요청은 Google UI에서 Google 서버로 전송됩니다.
  3. Google 서버가 Google UI에 인증 요청 (authenticationRequest)을 다시 전송합니다.
  4. Google UI는 결제 통합업체 UI에 사용자 인증 (associationId, authenticationRequest) 요청을 보냅니다.
  5. 결제 통합업체 UI가 신원을 확인하기 위해 사용자 (LookupIdentity(associationId))를 조회합니다.
  6. 결제 통합업체 UI가 사용자에게 UI (통합업체의 웹사이트 또는 앱)에서 사용자 인증 정보를 요청하는 메시지를 표시합니다.
  7. 인증 응답이 결제 통합업체 서버로 전송됩니다.
  8. 서명된 인증 응답 (authenticationResponse)이 결제 통합업체 UI로 다시 전송됩니다.
  9. 인증 응답 (authenticationResponse)이 결제 통합업체 UI에서 Google UI로 전송됩니다.
  10. Google UI는 구매 정보가 포함된 응답을 Google 서버에 전송합니다.
  11. Google 서버에서 결제 통합업체 서버(authenticationRequestId, GPT, 금액)에 사용 가능한 자금을 찾기 위한 capture 메시지를 전송합니다.
  12. 결제 통합업체 서버가 Google 서버로 성공 메시지를 다시 보냅니다.
  13. Google 서버가 Google UI에 성공 메시지를 보냅니다.
  14. Google UI가 고객에게 상품을 배송하거나 상품이 곧 배송될 것임을 알립니다.

SMS-MO 인증

모바일 기반 인증 흐름은 Short Message Service에서 결제 통합업체로 사용자의 휴대폰에서 전송된 인증 요청 ID가 포함된 SMS를 활용하여 사용자를 인증합니다.

SMS-MO 인증 흐름

다음은 다이어그램에 포함된 객체 목록과 각 객체가 나타내는 의미입니다.

  • 사용자: Google 계정에 결제 수단을 추가하려는 사용자입니다.
  • Google UI/기기: 이 경우 고객이 결제 수단을 설정하기 시작하는 Google 전화 앱입니다.
  • Google 서버: 인증 요청 ID (ARID)가 포함된 SMS 명령을 생성하고 통합업체로부터 인증 결과를 수신하는 Google의 백엔드 서버입니다.
  • 결제 통합업체 서버: 인증 SMS를 수신하고 인증 요청 ID를 Google에 반환하는 통합업체의 백엔드 서버입니다.

이는 인증 흐름이므로 이미 사용자가 앱 (Google UI)을 사용하고 있으며 결제 수단을 추가하려고 한다고 가정합니다. 여기서 초기화가 시작됩니다.

  1. 사용자가 추가할 토큰화된 결제 수단을 선택합니다.
  2. Google UI가 Google 서버를 호출하여 SMS-MO 챌린지를 시작합니다.
  3. Google 서버는 인증 요청 ID가 포함된 대상과 본문으로 구성된 SMS 안내를 반환합니다.
  4. Google UI가 결제 통합업체에 SMS를 보냅니다.
  5. 결제 통합업체 서버가 인증 요청 ID를 사용하여 Google 서버의 AuthenticationResultNotification 엔드포인트를 호출합니다.
  6. Google 서버에서 인증 요청 ID를 확인하고 그러면 SUCCESS라고 응답합니다.
  7. Google UI는 Google 서버를 호출하여 인증 시도 결과를 가져옵니다.
  8. Google 서버 응답 성공

SMS-MO 인증 시뮬레이션

Google에서는 SMS-MO 인증 흐름의 진단 테스트를 실행하기 위해 SMS 시뮬레이션 엔드포인트를 정의합니다. 따라서 샌드박스 환경에서 테스트 연결을 수행할 때 실제 SMS를 전송하고 확인할 필요가 없습니다.

SMS-MO 인증 흐름 시뮬레이션

다음은 다이어그램에 포함된 객체 목록과 각 객체가 나타내는 의미입니다.

  • 테스터: SMS-MO 연결 진단 테스트를 시작하는 사람입니다.
  • Google UI: 테스터가 SMS-MO 진단 테스트를 시작하고 상태를 모니터링하는 Google UI입니다.
  • Google 서버: 인증 요청 ID (ARID)로 SMS 명령을 생성하고 시뮬레이션된 SMS 메시지를 전송하고 통합업체로부터 인증 결과를 수신하는 Google의 백엔드 서버
  • 결제 통합업체 서버: 시뮬레이션된 인증 SMS를 수신하고 인증 요청 ID를 Google에 반환하는 통합업체의 백엔드 서버입니다.

이 흐름의 단계는 다음과 같습니다.

  1. 테스터는 테스트에 사용할 테스트 구독자 ID (SID)를 제공하여 SMS-MO 진단 테스트를 시작합니다. 이 SID는 결제 통합업체에 대한 simulateSms 호출에 포함됩니다.
  2. Google UI가 Google 서버를 호출하여 SMS-MO 챌린지를 시작합니다.
  3. Google 서버는 인증 요청 ID가 포함된 대상과 본문으로 구성된 SMS 안내를 반환합니다. 이 테스트의 목적상 목적지는 결제 통합업체의 샌드박스 HTTPS 연결에 의해 재정의됩니다.
  4. Google UI는 Google 서버를 호출하여 시뮬레이션된 SMS 메시지를 전송합니다.
  5. simulateSms 호출은 Google 서버에서 결제 통합업체 서버로 이루어집니다. 인증 요청 ID 및 구독자 ID (1단계에서 제공)가 모두 API 호출에 포함됩니다.
  6. 결제 통합업체 서버가 ACKNOWLEDGED를 응답합니다.
  7. Google 서버가 Google UI에 SUCCESS라고 응답합니다.
  8. 결제 통합업체 서버가 인증 요청 ID를 사용하여 Google 서버의 AuthenticationResultNotification 엔드포인트를 호출합니다.
  9. Google 서버가 SUCCESS로 응답합니다.
  10. Google UI는 Google 서버를 호출하여 인증 시도 결과를 가져옵니다.
  11. Google 서버가 COMPLETED로 응답합니다.
  12. Google UI는 Google 서버를 호출하여 연결 시도를 실행합니다.
  13. associateAccount 호출은 Google 서버에서 결제 통합업체 서버로 이루어집니다.
  14. 결제 통합업체 서버가 SUCCESS를 응답합니다.
  15. Google 서버가 SUCCESS로 응답합니다.
  16. 테스터에게 SMS-MO 진단 테스트가 완료되었음을 알리기 위해 Google UI가 업데이트됩니다.

권장사항 및 기타 고려사항

플랫폼 선택

모바일 앱과 데스크톱 웹 인증 흐름을 제공하면 통합업체가 대부분의 사용자에게 도달할 수 있습니다. Android 애플리케이션은 최상의 사용자 경험과 가장 높은 전환율을 제공하므로 통합업체에서 Android 애플리케이션을 지원하는 것이 좋습니다. 웹 및 Android 애플리케이션의 인증 API에 전달되는 매개변수는 동일합니다.