Android에서 원활한 로그인 및 디지털 사용자 인증 정보 제공

안녕하세요.

참여해 주셔서 감사합니다.

오늘은 인증과 디지털 ID의 미래에 대해 이야기해 보겠습니다.

저는 톰 콜빈입니다.

저는 Apptaura의 CTO이자 Android GDE입니다. Google의 수석 Android 개발자 관계 엔지니어인 치핑 예와 함께 진행하겠습니다.

오랫동안 사용되어 온 비밀번호는 이제 사라졌습니다.

적어도 그래야 합니다.

오늘은 비밀번호 없는 세상에 대해 이야기해 보려고 합니다.

비밀번호는 보안 인프라에서 잘 알려진 취약점입니다.

안전하게 저장되어 있더라도 피싱, 서버 침해, 크리덴셜 스터핑과 같은 자동화된 공격에 취약합니다.

업계에서는 특수문자, 숫자, 필수 순환 등 복잡성을 적용하여 이 문제를 해결하려고 노력해 왔습니다.

이러한 방식은 실패한 것으로 나타났습니다. 부분적으로는 어렵게 만들수록 역설적으로 안전하지 않은 행동을 조장하기 때문입니다.

정기적으로 변경되는 복잡한 비밀번호는 메모지에 적어둘 가능성이 높기 때문입니다.

SMS 기반 2단계 인증도 SIM 스와핑과 같은 가로채기에 취약한 것으로 입증되었습니다.

하지만 오늘날 이 문제는 대부분 해결되었습니다.

패스키는 FIDO 표준을 기반으로 하며 공개 키-비공개 키 암호화를 사용합니다.

피싱에 매우 강하고, 서버 침해 시 노출되지 않으며, 화면 잠금을 통해 사용자의 휴대전화 보안에 직접 연결됩니다. 대부분의 경우 생체 인식, 지문 등을 기반으로 합니다. 또한 플랫폼 전반에서 통합된 환경을 제공하고 복잡한 비밀번호를 기억할 필요가 없어 사용자 환경을 적극적으로 개선합니다.

오늘날 우리의 선언은 간단합니다.

비밀번호 없는 세상으로 전환할 때입니다.

이를 위한 도구는 이미 우리 손에 있습니다.

Android에서 이러한 도약을 이루는 데 핵심적인 역할을 하는 것이 바로 Jetpack 인증 관리자입니다.

Android 4.4까지 지원되며 Android 9부터 패스키가 지원됩니다. 패스키는 물론 Google 계정으로 로그인과 같은 제휴 로그인과 같은 기존 인증을 지원하는 단일 통합 API를 제공하며, 필요한 경우 비밀번호로 원활하게 대체할 수 있습니다.

Credential Manager API를 호출하면 사용자가 보려는 인증 방법을 선택하는 UI가 처리됩니다.

그런 다음 안전하게 가져온 올바른 사용자 인증 정보를 반환하는 어려운 작업을 수행합니다.

로그인, 가입, 사용자 인증 정보 백업을 지원합니다.

사용자 인증 정보를 업데이트하고 삭제하는 데 사용할 수 있습니다.

또한 사용자는 파일 다운로드 없이 몇 번의 클릭만으로 사용자 인증 정보 제공업체 간에 비밀번호와 패스키를 이동할 수 있습니다.

사용자가 자신의 데이터를 완전히 제어하고 필요할 때 언제든지 제공업체를 전환할 수 있도록 설계되었습니다.

인증 관리자는 시계, TV, XR, 자동차, 휴대전화, 폴더블, 태블릿 등 다양한 폼 팩터를 지원합니다.

그리고 가장 중요한 것은 패스키를 위한 전용 흐름이 있다는 것입니다.

가입 시 사용자에게 표시되는 화면은 다음과 같습니다.

앱은 인증 관리자에 패스키 인증을 사용할 수 있다고 알리고 백엔드에서 수집한 세부정보를 제공합니다.

등록을 누르면 인증 관리자가 화면 잠금 메시지가 표시된 하단 시트를 제공합니다.

이는 지문이나 얼굴 스캔과 같은 생체 인식으로 잠금 해제하는 것이 가장 일반적입니다.

그러면 인증 관리자가 패스키를 실제로 생성하는 것과 같은 복잡한 암호화 작업을 처리합니다.

그리고 패스키를 인증 관리자에 저장합니다. 이 경우에는 Google 비밀번호 관리자이지만 다른 것일 수도 있습니다.

코드는 다음과 같습니다.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

val createCredentialResponse =  credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

먼저 백엔드에서 제공하는 세부정보를 사용하여 이 createPublicKeyCredentialRequest 객체를 만듭니다. 이 객체는 registerRequestJson입니다.

그런 다음 매직 메서드인 credentialManager.createCredential를 호출합니다.

이 요청과 로컬 컨텍스트를 전달하여 UI를 표시할 수 있습니다.

여기서 UI 코드를 작성할 필요가 없다는 점에 유의하세요.

인증 관리자가 이 모든 작업을 처리합니다.

로그인 절차는 다음과 같습니다.

사용자에게는 가입 절차와 매우 유사하게 보입니다.

잠금 해제 메시지가 한 번 표시되면 완료됩니다.

개발자의 경우 약간 다릅니다.

val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
   requestJson = authenticationRequestJson
)
val signInRequest =
   GetCredentialRequest(listOf(getPublicKeyCredentialOption))

val result =  credentialManager.getCredential  (
   context = localActivity,
   request = signInRequest
)

먼저 백엔드에서 로그인 세부정보를 가져와 GetPublicKeyCredential 인스턴스를 빌드합니다.

지원하는 사용자 인증 정보 유형을 인증 관리자에 알립니다.

여기서는 패스키만 표시됩니다.

하지만 원하는 경우 다른 유형의 사용자 인증 정보를 추가할 수도 있습니다.

그런 다음 방금 요청한 사용자 인증 정보 목록을 전달하는 credentialManager.getCredential를 호출합니다.

UI 코드가 없습니다.

UI 코드를 작성할 필요가 없습니다.

인증 관리자가 이 작업을 완전히 처리합니다.

가장 자주 사용하는 옵션을 사용자에게 제안하고 다른 옵션은 백업으로 남겨둡니다.

이렇게 하면 오늘날 가장 성가신 인증 문제 중 하나가 자동으로 해결됩니다.

눈치채셨나요?

마지막으로 로그인할 때 사용한 방법을 기억하는 것입니다.

하단 시트에 답변이 깔끔하게 표시됩니다.

이는 사용자에게 불편을 끼칠 뿐만 아니라

이는 실질적인 마찰 지점입니다.

불필요한 계정 복구를 유발하고 장바구니 이탈과 같은 상업적 영향을 미칩니다.

다음은 인증 관리자를 직접 사용해 볼 수 있는 데모 애플리케이션 코드입니다.

이러한 흐름은 내 기기에서 확인할 수 있습니다.

왼쪽에는 공식 Google 코드 샘플이 있습니다.

패스키 생성을 처리합니다.

기존 비밀번호 사용자를 패스키로 업그레이드하는 것은 어떤가요?

이를 위한 강력한 도구는 조건부 생성입니다.

사용자가 비밀번호를 사용하여 로그인했고 지원되는 사용자 인증 정보 제공업체에서 비밀번호를 자동 완성한 경우 사용자가 적극적으로 참여하고 있으며 사용자의 신원이 새로 확인되었음을 알 수 있습니다.

이 경우 조건부 생성을 사용하면 백그라운드에서 패스키 생성을 자동으로 요청할 수 있습니다.

사용자의 워크플로를 방해하지 않습니다.

패스키는 자동으로 생성되어 저장됩니다.

Google 비밀번호 관리자에 이 사실을 확인하는 알림이 표시됩니다.

다른 비밀번호 관리자는 다르게 작동할 수 있습니다.

조건부 생성 코드는 가입 코드와 매우 유사합니다.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson,
   preferImmediatelyAvailableCredentials = false,
   isConditional = true
)

val createCredentialResponse = credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

마법 플래그는 isConditional true로, 사용자가 해당 UI를 보지 못하도록 합니다.

그리고 기회주의적으로 작동하므로 try-catch에 넣습니다.

오류는 자동으로 처리되므로 프로세스가 실패해도 사용자에게 불편을 주지 않습니다.

그러면 패스키가 사용자의 인증 관리자에 저장되어 다음에 사용할 수 있습니다.

또한 인증 관리자를 사용하면 인증 정보 제공업체가 인증 정보를 안전하게 가져오고 내보낼 수 있습니다.

클릭 몇 번이면 됩니다.

다운로드할 필요가 없습니다.

이를 통해 정보를 안전하게 보호하면서도 더 유연하게 작업할 수 있습니다.

흐름은 다음과 같습니다.

사용자가 새 사용자 인증 정보 제공업체에서 사용자 인증 정보 가져오기를 요청합니다.

그런 다음 인증 관리자가 가져오기 UI를 처리하여 사용자가 사용자 인증 정보 데이터의 소스를 선택할 수 있도록 합니다.

그러면 내보내기 사용자 인증 정보 제공업체는 자체 UI를 제공할 수 있으며, 이를 통해 사용자에게 안내하고 관련 경고를 제공할 수 있습니다.

마지막으로 사용자의 새 사용자 인증 정보 제공업체에 보안 채널을 통해 데이터가 제공됩니다.

따라서 사용자 상호작용 없이 가져올 수 있습니다.

하지만 사용자가 앱이나 웹사이트에서 패스키를 취소하면 어떻게 될까요?

그러면 사용자 인증 정보 제공업체는 이러한 상황이 발생했는지 알 수 없습니다.

다음에 로그인하려고 하면 인증 관리자가 해당 패스키를 제공하고 시도가 거부됩니다.

마찬가지로 사용자가 사용자 이름 또는 표시 이름을 업데이트할 때도 동기화가 필요합니다.

이제 Signal API를 사용하면 앱에서 이러한 특정 상태를 인증 정보 제공자에게 신고할 수 있습니다.

취소된 비밀번호로 로그인하는 경우를 예로 들어보겠습니다.

앱은 이 특정 오류 상태를 포착하여 사용자의 사용자 인증 정보 제공업체에 알리는 데 사용할 수 있습니다.

그러면 사용자 인증 정보 제공업체는 해당 패스키가 제공되지 않도록 자체적으로 업데이트할 수 있습니다.

이것이 인증 관리자의 몇 가지 기능입니다. 사용자가 패스키를 사용하여 가입하도록 유도하고 로그인 시 다른 방법보다 패스키를 우선시하는 데 매우 유용합니다.

하지만 궁극적인 목표는 비밀번호를 완전히 없애는 것입니다.

인증 관리자는 이 목표를 달성하는 데 어떻게 도움이 되나요?

다음은 Google에서 제안하는 5단계 프로세스입니다.

처음 두 단계에서는 비밀번호 사용자를 패스키로 업그레이드합니다.

먼저 조건부 생성을 사용하여 기회주의적으로 시도합니다.

그러한 기회가 발생하지 않으면 결국 사용자의 개입이 필요하므로 인앱 초대를 통해 사용자에게 패스키를 설정하도록 요청합니다.

이러한 콘텐츠를 점차 더 눈에 띄게 표시할 수 있습니다.

결국 사용자 관점에서는 일반적으로 생체 인식과 같은 화면 잠금만 제공하면 됩니다.

분석 결과 대다수의 사용자가 패스키를 사용하는 계정을 보유하고 있는 것으로 나타나면 모든 신규 사용자에게 패스키를 의무화할 수 있습니다.

하지만 기존 사용자는 마지막 세 단계에서 처리합니다.

패스키 사용자는 비밀번호를 삭제하는 것이 좋습니다.

따라서 3단계에서는 계정 설정에서 명확한 비밀번호 삭제 옵션을 통해 수동으로 이 작업을 수행할 수 있도록 합니다.

4단계에서는 교육용 문구와 함께 인앱 알림 등을 사용하여 비밀번호 삭제를 유도하기 시작합니다.

마지막으로 비밀번호 삭제를 선택 해제에서 선택으로 전환합니다.

결국 마지막 선택 해제도 사라질 수 있습니다.

애널리틱스를 통해 앱에서 비밀번호 흐름을 완전히 삭제할 수 있다는 확신을 얻을 수 있습니다.

따라서 비밀번호가 없는 세상으로의 전환은 더 이상 미래의 이론적인 보안 개념이 아닙니다.

지원 수준이 높습니다.

API는 강력하고 사용자 환경은 우수합니다.

지금 바로 인증 관리자와 패스키 흐름을 통합해 보세요.

사용자 업그레이드를 시작하고 비밀번호를 과거의 유물로 남겨두세요.

감사합니다.

이제 치핑에게 마이크를 넘겨 기기 이전 및 ID의 다음 단계에 대해 이야기해 보겠습니다.

됐습니다

좋습니다. 감사합니다, 톰.

톰이 강조했듯이 사용자 기기에서 원활한 인증은 매우 중요합니다.

하지만 사용자가 휴대전화를 새것으로 바꾸면 어떻게 되나요?

오늘날 사용자 여정에서 가장 큰 이탈은 기기를 전환할 때 발생합니다.

오늘은 이 문제를 해결하는 방법을 먼저 설명하고, 사용자 인증 정보 복원과 관련해 예정된 Play 스토어 요구사항을 간단히 살펴보겠습니다.

2027년 4월부터 Google Play에서는 앱이 제로탭 로그인 요구사항을 충족해야 Play 스토어에서 전체 게시 기능과 최적의 공개 상태를 유지할 수 있습니다.

제로탭 로그인이란 무엇인가요?

즉, 사용자가 새 기기로 전환할 때 앱에서 수동으로 다시 인증할 필요가 없습니다.

이러한 기능을 어떻게 구현할 수 있을까요?

이를 위해 권장하는 기본 방법은 인증 관리자를 통해 Android의 Restore Credentials API를 사용하는 것입니다.

이 API를 사용하면 복원 키를 생성할 수 있으며, 이 키는 사용자의 백업 설정에 따라 사용자의 기기 또는 클라우드에 저장됩니다.

사용자가 로그인한 후 백그라운드에서 이 키를 생성하는 것이 좋습니다.

이 다이어그램은 사용자가 앱에 로그인하는 과정을 보여줍니다.

그런 다음 사용자가 앱을 사용하는 동안 복원 키가 생성됩니다.

이 키는 로컬에 저장되거나, 사용 설정된 경우 클라우드에 원격으로 저장됩니다.

사용자가 새 기기를 설정하면 기기 설정 프로세스 중에 백그라운드에서 복원 사용자 인증 정보가 자동으로 전송됩니다.

사용자는 클라우드 또는 기기 간 전송에서 데이터를 복원하도록 선택할 수 있습니다.

그런 다음 앱이 열리면 Credential Manager API를 호출하여 이 복원 키를 사용해 새 기기에서 처음 실행할 때 사용자를 로그인 처리할 수 있습니다.

이를 통해 사용자는 앱에 빠르고 안전하게 바로 로그인할 수 있습니다.

설정 후 앱을 열지 않고 즉시 복원하려면 맞춤 백업 에이전트를 구현하면 됩니다.

이렇게 하면 사용자가 앱을 직접 열지 않고도 앱에 로그인할 수 있습니다.

일부 파트너는 이미 앱에 이 기능을 구현했습니다.

Uber는 세계 최대의 차량 공유 회사로, 수백만 명의 사람들에게 교통수단을 제공하는 동시에 음식 배달, 의료 운송, 화물 물류도 지원합니다.

액세스의 단순성이 중요합니다.

또한 사용자가 새 기기로 전환할 때 Uber 앱에 다시 로그인하거나 매번 SMS 기반 일회성 인증을 거치지 않고도 원활하게 전환할 수 있기를 기대합니다.

이러한 빈번한 기기 교체는 사용자 유지에 어려움을 초래합니다.

Uber는 사용자 요구사항을 평가하고 코드 프로토타입을 제작한 후 Uber Rider 앱에 사용자 인증 정보 복원 지원을 도입했으며, 그 결과는 매우 긍정적이었습니다.

이로 인해 일평균 로그인 횟수가 400만 회 감소할 것으로 예상되며, 도입이 확대됨에 따라 이 수치는 증가할 것으로 예상됩니다.

이 QR 코드와 링크를 통해 예정된 정책과 앱이 제로 탭 복원 요구사항을 충족하는 방법을 자세히 알아보세요.

이 변경사항은 2027년 4월에 적용될 예정이니 캘린더에 표시해 두시기 바랍니다.

앱에 복원 사용자 인증 정보를 구현하는 방법을 미리 알아보고 싶다면 이 QR 코드와 링크를 통해 복원 사용자 인증 정보 기술에 액세스하세요.

이 기술은 선택한 에이전트로 기능을 빠르게 개발하거나 테스트하는 데 사용할 수 있습니다.

이제 디지털 신원 확인의 다음 단계인 인증 관리자를 통한 Digital Credentials API를 살펴보겠습니다.

디지털 사용자 인증 정보가 무엇이고 어떻게 작동하는지 살펴보겠습니다.

디지털 인증서는 사용자가 자신에 관한 정보를 제공하는 데 사용할 수 있는 암호화 방식으로 확인 가능한 디지털 문서입니다.

이러한 문서는 사용자 기기의 디지털 홀더에 저장되며 기기의 다른 앱에서 요청하거나 QR 코드와 같은 하이브리드 방식으로 세상에 표시할 수 있습니다.

신원 확인부터 서비스 액세스, 온라인 상품 구매에 이르기까지 다양한 용도로 사용됩니다.

디지털 자격 증명은 실물 카드 없이도 정보를 안전하고 편리하게 공유할 수 있는 방법을 제공합니다.

디지털 자격 증명에는 발급기관, 소지자, 검증자라는 세 당사자가 관여합니다.

디지털 사용자 인증 정보의 수명 주기는 일반적으로 왼쪽에서 오른쪽으로 진행됩니다.

각 항목과 그 역할을 살펴보겠습니다.

첫 번째는 발급기관입니다. 이름에서 알 수 있듯이 정부에서 여권을 발급하는 것처럼 사용자 인증 정보를 발급하는 주체입니다.

하지만 디지털 세계에서는 스푸핑을 방지하기 위해 발급기관이 디지털 인증서로 이러한 인증서에 서명하므로 인증서를 받는 사람은 누구든지 인증서가 누구로부터 발급되었는지 정확히 알 수 있습니다.

체육관, 호텔, 개인 등 누구나 발급기관이 될 수 있습니다.

사용자 인증 정보를 만들고 서명하기만 하면 됩니다.

발급기관은 사용자 인증 정보를 생성하고 발급하지만, 정부 발급 신분증을 지갑에 보관해야 하는 것처럼 사용자 인증 정보도 어딘가에 저장해야 합니다.

다음은 소지자라고 하는 당사자로, 일반적으로 디지털 지갑이라고도 합니다.

소지자는 이름에서 알 수 있듯이 주로 발급기관에서 발급한 사용자 인증 정보를 소지합니다.

기기에 앱으로 저장되며, 요청하는 당사자에게 제시할 수 있습니다.

발급기관과 마찬가지로 누구나 소지자가 될 수 있습니다.

실제로 발급기관과 소지자가 동일한 법인에서 관리되는 경우가 많습니다.

자체 디지털 멤버십 사용자 인증 정보를 만들고 자체 앱을 통해 관리하려는 체육관을 생각해 보세요.

이 경우 발급기관이자 소지자가 됩니다.

서드 파티는 인증자, 즉 디지털 사용자 인증 정보를 요청하는 당사자입니다.

검증자는 일반적으로 연령 요건, 성 등 사용자에 관한 속성을 확인하기 위해 사용자 인증 정보 요청을 합니다.

주류 구매 또는 최소 연령 확인과 같은 서비스를 수행하기 위해 추가 사용자 데이터가 필요한 비즈니스 또는 앱입니다.

Android에서는 이 세 당사자와 사용자 간의 상호작용이 Digital Credentials API를 사용하는 인증 관리자를 통해 조정됩니다.

발급기관은 API를 호출하여 소지자에게 사용자 인증 정보를 발급할 수 있지만, 동일한 법인인 경우에는 이 작업이 필요하지 않습니다.

사용자 인증 정보가 발급되면 검증자는 API를 호출하여 사용자 인증 정보를 요청할 수 있습니다.

인증 관리자는 요청을 사용 가능한 모든 소지자와 일치시키고 사용자에게 표시하여 사용자 인증 정보를 선택하고 동의를 제공하도록 합니다.

홀더가 선택되면 호출되며, 필요한 경우 최종적으로 검증자와 사용자 인증 정보를 공유하기 전에 추가 검사를 실행할 수 있습니다.

검증자는 사용자 인증 정보를 수신한 후 원본 발급기관 확인을 포함하여 사용자 인증 정보의 적법성에 대한 다양한 검사를 수행할 수도 있습니다.

그렇다면 디지털 자격 증명은 어떻게 안전하게 보호될까요?

프로세스의 각 단계에는 보안이 내장되어 있으며, 지금부터 몇 가지를 살펴보겠습니다.

따라서 발급기관 측에서 소지자와 사용자 인증 정보를 공유하려면 소지자가 변조되거나 복사될 수 없는지, 기본적으로 신뢰할 수 있는지 확인해야 합니다.

이를 어떻게 확인할 수 있나요?

발급기관은 사용자 인증 정보를 발급하기 전에 소지자가 자신의 신원과 사용 중인 기기의 보안을 증명하도록 요구합니다.

소지자는 일반적으로 확인 가능한 인증서 체인으로 월렛 증명을 전송합니다.

소지자는 하드웨어 바인딩 키 쌍도 생성합니다.

발급기관이 하드웨어의 적법성을 검증할 수 있도록 Android 키 증명과 함께 이 키 쌍의 공개 키를 발급기관에 전송합니다.

발급기관은 이 공개 키를 발급된 사용자 인증 정보에 서명하여 사용자 인증 정보가 단일 기기에 공식적으로 결합되도록 합니다.

소지자 측에서는 소지자가 새 사용자 인증 정보를 보유하면 인증 관리자에 사용자 인증 정보 메타데이터만 등록합니다.

인증 관리자는 이 메타데이터를 사용하여 검증자가 사용자 인증 정보를 요청할 때 표시할 소지자를 결정합니다.

실제 사용자 데이터는 인증 관리자에 등록되거나 Google에 노출되지 않습니다.

인증 관리자가 사용자에게 표시할 월렛을 선택할 때도 각 월렛의 콘텐츠는 해당 시점에 표시되지 않습니다.

이제 사용자 인증 정보 요청이 이루어지고 사용자가 사용자 인증 정보 공유에 사용자 동의를 하면 선택된 소지자가 호출되고 워크플로 제어가 소지자에게 전달됩니다.

기억하시겠지만 홀더는 앱일 뿐이므로 앱이 호출됩니다.

이때 소지자는 요청하는 검증자와 요청된 사용자 인증 정보 등을 확인할 수 있으며, 사용자가 이미 권한을 부여했더라도 해당 사용자 인증 정보를 해당 검증자와 공유할지 결정할 수 있습니다.

Google은 사용자 인증 정보 데이터 자체에 액세스할 수 없습니다.

라우팅 메타데이터만 등록되며 페이로드는 소지자와 검증자 간에 엔드 투 엔드로 암호화됩니다.

이를 통해 소지자는 사용자 인증 정보를 공유할 당사자를 제어할 수 있습니다.

마지막으로, 검증자 측에서 사용자 인증 정보가 요청되고 소지자가 사용자 인증 정보를 공유하면 검증자는 소지자로부터 사용자 인증 정보 프레젠테이션을 받습니다.

이제 검증자는 응답이 요청에 대해 원래 사용자 인증 정보 소유자에 의해 새로 생성되었는지 확인할 수 있습니다.

일회성 토큰 요청 및 소지자가 관찰한 호출 출처를 포함하여 소지자의 기기 바인딩 키를 사용하여 사용자 인증 정보 응답이 서명되었는지 확인할 수 있습니다.

또한 검증자는 발급기관 인증서를 확인하여 사용자 인증 정보 발급기관의 진위 여부를 확인하고 신뢰할 수 있는 출처에서 발급되었는지 확인할 수 있습니다.

요약하자면 발급기관은 하드웨어 보증을 받고, 소지자는 공유할 사용자 인증 정보를 제어할 수 있으며, 검증자는 발급기관과 소지자의 암호화 증명을 받고, 사용자는 공유할 데이터에 대한 완전한 동의를 유지합니다.

디지털 인증이 안전한 이유를 살펴봤으니 이제 Android의 Digital Credentials API를 통해 현재 사용할 수 있는 디지털 인증의 사용 사례를 살펴보겠습니다.

첫 번째로 다룰 것은 이메일 인증입니다.

이 API는 사용자의 로그인된 Gmail을 기기에서 직접 가져와 Google에서 인증한 디지털 사용자 인증 정보로 앱에 표시하므로 일회성 비밀번호나 매직 링크를 전송할 필요가 없습니다.

즉, 사용자는 앱을 떠나지 않고 익숙한 인증 관리자 하단 시트를 한 번 탭하여 동의만 제공하면 됩니다.

다음은 API가 작동하는 모습을 보여주는 데모 녹화입니다.

이 앱은 Digital Credentials API를 통해 이메일 인증을 구현하는 샘플 앱입니다.

'인증된 이메일 요청'을 탭하면 인증 관리자가 이 유형의 사용자 인증 정보를 보유한 기기의 소유자에게 인증된 이메일 디지털 사용자 인증 정보를 요청합니다.

이 경우 Google만 이 인증된 이메일 사용자 인증 정보의 소유자이며, 이는 하단 시트에 표시됩니다.

사용자가 기기에서 로그인한 이메일 중 하나입니다.

이 경우 Google은 디지털 사용자 인증 정보의 발급자이자 소유자입니다.

공유할 사용자 인증 정보를 선택하면 앱으로 반환되며, 현재는 사용자 인증 정보에 포함된 필드인 인증된 이메일만 표시됩니다.

앱에서 이 정보를 사용하여 패스키 생성 또는 기타 계정 생성 단계와 같은 다음 앱 화면으로 진행할 수 있습니다.

사용자는 동의를 제공하고 다음 화면으로 이동하기만 하면 됩니다.

사용해 보려면 GitHub 샘플로 이동하여 자체 기기에 설치하면 됩니다.

실제 기기에서 사용해 보세요. 기기에서 하나 이상의 Gmail 계정에 로그인해야 합니다.

관심이 있는 분들을 위해 시간을 조금 더 드리겠습니다.

좋습니다.

재미있을 것 같지 않으세요?

이메일 인증을 생각할 때 다음으로 떠오르는 사용자 인증 방식은 무엇인가요?

맞습니다. 전화번호 인증입니다.

Digital Credentials API는 전화번호 인증도 기본적으로 지원하므로 SMS OTP의 불편함과 취약점을 없앨 수 있습니다.

전화번호 인증도 Digital Credentials API를 통해 작동하며, 이 경우 기기의 전화번호가 요청되고 디지털 사용자 인증 정보로 제공됩니다.

사용자는 익숙한 인증 관리자 하단 시트만 보고 전화번호를 공유하거나 인증할 수 있으며, 앱 내에서 몇 번의 탭만으로 인증을 완료할 수 있습니다.

여기에서는 고객이 앱을 종료하지 않고도 탭 한 번으로 전화번호를 공유할 수 있는 앱의 예를 볼 수 있습니다.

그렇다면 이 설정은 어떻게 작동할까요?

이를 디지털 사용자 인증 정보 당사자에 매핑하면 이 경우 발급기관은 기기 SIM 카드의 전화번호를 제공하는 이동통신사이고, 소지자는 Android Telephony입니다.

앱과 같은 인증자가 사용자의 전화번호를 요청하면 Digital Credentials API 호출을 통해 Google Telephony에서 전화번호를 가져옵니다.

결제 방식이 궁금하실 수 있습니다.

이 흐름에는 결제를 위해 사용자 인증 정보가 이동통신사 또는 애그리게이터로 전달되는 추가 단계가 있습니다.

이는 Google Telephony에서 전화번호를 가져온 후 발생하며, 전화번호는 암호화된 상태로 저장됩니다.

그런 다음 이동통신사로 전달되며, 이동통신사는 이를 복호화하여 전화번호를 앱의 백엔드로 직접 반환합니다. 이 과정에서 요금이 청구됩니다.

이 방법의 장점은 이동통신사가 데이터 또는 Wi-Fi를 통해 전송되고 SMS보다 훨씬 안정적인 인증에 대해서만 요금을 청구한다는 것입니다.

여기에서는 Firebase를 이동통신사 애그리게이터로 사용하여 전화번호 인증이 작동하는 모습을 보여주는 데모가 있습니다.

앱에서 로그인 절차의 일부로 사용자의 전화번호를 요청합니다.

이 사용자는 SIM 카드가 여러 개 있으며 앱과 공유할 SIM 카드를 하나 선택합니다.

사용자가 선택을 확인하면 교환이 백그라운드에서 모두 진행됩니다.

그러면 검색된 전화번호가 입력된 다음 화면이 표시됩니다.

사용자는 앱을 나갈 필요 없이 공유할 전화번호를 선택하고 확인하기만 하면 몇 번의 탭만으로 원활하게 절차를 진행할 수 있었습니다.

완료를 한 번 더 볼 수 있도록 완료될 때까지 기다리겠습니다.

최종 화면에 전화번호가 표시됩니다.

이제 모든 작업이 완료되었습니다.

오늘 많은 내용을 다루었습니다.

먼저 인증 관리자를 사용하여 패스키 구현을 개선하고 비밀번호 없는 환경으로 전환하는 방법을 살펴보았습니다.

여기에서 인증 관리자 및 패스키에 관한 리소스를 참고하여 자세히 알아보고 샘플 앱에 액세스하세요.

다음으로, 사용자가 새 기기를 설정할 때 원활하게 로그인할 수 있도록 하는 앱의 제로탭 로그인 요구사항을 다뤘습니다.

이 요구사항은 2027년 4월까지 Play 스토어에서 의무화될 예정이므로 일정에 참고하시기 바랍니다.

마지막으로 디지털 사용자 인증 정보의 작동 방식과 Android에서 가장 유용한 몇 가지 기능을 살펴보았습니다.

콘텐츠를 심층 분석하고 샘플에 액세스하려면 여기에서 디지털 사용자 인증 정보에 관한 리소스를 참고하세요.

오늘 공유해 드린 모든 기능은 현재 사용 가능하며, 이를 활용해 개발을 시작하실 수 있습니다.

Android의 ID 미래가 여기에 있으며 그 어느 때보다 흥미롭습니다.

시간을 내주셔서 감사합니다. 점심시간이니 밖에 준비된 음식을 즐기시기 바랍니다.

패스키나 디지털 사용자 인증 정보에 관해 궁금한 점이 있으면 언제든지 저나 톰에게 문의해 주세요.

감사합니다.