View in English

  • 메뉴 열기 메뉴 닫기
  • Apple Developer
검색
검색 닫기
  • Apple Developer
  • 뉴스
  • 둘러보기
  • 디자인
  • 개발
  • 배포
  • 지원
  • 계정
페이지에서만 검색

빠른 링크

5 빠른 링크

비디오

메뉴 열기 메뉴 닫기
  • 컬렉션
  • 주제
  • 전체 비디오
  • 소개

더 많은 비디오

  • 소개
  • 요약
  • 자막 전문
  • 코드
  • 패스키의 새로운 기능

    iOS, iPadOS, macOS 및 visionOS 26로 패스키를 강화하는 방법을 알아보세요. 간소화된 가입을 위한 새로운 계정 생성 API, 비밀번호를 최신 상태로 유지하는 방법, 자동 패스키 업그레이드 및 패스키 관리 엔드포인트를 통한 패스키 업그레이드를 유도하는 새로운 방법, 안전하게 패스키 내보내기/가져오기 등 주요 업데이트를 살펴보겠습니다. 이번 개선 사항을 통해 사용자 경험과 보안을 향상하고 앱에서 이러한 업데이트를 구현하여 보다 원활하고 안전한 인증 경험을 제공하는 방법을 확인하세요. 이 비디오를 최대한 활용하려면 WWDC22의 ‘패스키 소개'를 먼저 시청하는 것이 좋습니다.

    챕터

    • 0:00 - 서론
    • 0:58 - 패스키 여정
    • 3:30 - 계정 생성 API
    • 10:48 - 패스키를 최신 상태로 유지하기
    • 14:41 - 자동 패스키 업그레이드
    • 16:59 - 패스키 관리 엔드포인트
    • 19:12 - 패스키 가져오기 및 내보내기

    리소스

    • ASCredentialExportManager
    • ASCredentialProviderViewController
    • Performing fast account creation with passkeys
      • HD 비디오
      • SD 비디오

    관련 비디오

    WWDC24

    • 패스키 업그레이드 및 자격 증명 관리 앱으로 로그인 간소화하기

    WWDC22

    • 패스키 소개
  • 비디오 검색…

    안녕하세요, 인증 경험 팀의 엔지니어 Andrew입니다 Apple은 간편하고 빠르며 안전한 로그인을 위해 노력합니다

    대부분의 로그인 및 계정 보안 문제에서 근본 원인은 암호입니다 업계는 이러한 문제를 근본적으로 해결하기 위해 온라인 계정에 암호 대신 패스키를 사용하는 방식을 도입했습니다 패스키는 암호의 보안 및 사용성 문제를 근본적으로 해결합니다 오늘날 우리가 알고 있는 피싱이 예방되며 동시에 로그인 환경도 원활해집니다

    이 비디오를 시청하고 계신다면 여러분도 이 부분을 담당하는 팀이시겠죠 암호를 패스키로 대체하는 중요하고 우선적인 목표를 위해 우리 모두 노력하고 있습니다

    패스키 여정은 이 목표를 향한 길입니다 피싱이 불가능한 요소로만 인증을 보호하는 업계 차원의 전환이죠 이를 위해 여러 단계를 거칩니다 패스키 이전에는 대다수의 계정이 피싱 가능한 요소로만 생성되었습니다 암호나 SMS 또는 이메일을 통해 전송되는 일회용 코드 말입니다

    이번 여정의 시작은 패스키처럼 피싱이 불가능한 방법을 로그인 방법으로 추가하는 거죠 현재 업계에서 대부분이 이 단계에 있습니다 목표는 모든 계정이 피싱 가능한 요소가 없는 상태에 도달하도록 하는 것이며 모두가 그 목표에 달성하도록 업계에서 도입한 게 패스키입니다 전반적으로 모멘텀이 엄청난데 사용자의 채택이 증가하고 서비스 지원도 확대되고 있습니다 패스키를 뒷받침하는 표준 기구 FIDO Alliance의 2025년 연구에 따르면 응답자 중 69%가 패스키를 하나 이상 보유했습니다

    Google은 패스키로 로그인하는 사용자가 암호 사용자보다 계정 로그인 성공 비율이 4배 더 높다고 발표한 바 있습니다 또한 TikTok에서 패스키 사용자의 로그인 성공 비율은 무려 97%에 달했습니다 이런 패스키 로그인 성공 비율은 업계에서 흔하며 암호 사용 시와 비교할 수 없는 수준입니다

    이처럼 채택이 늘고 성공을 거두는 것은 분명 패스키 여정의 진전이죠 iOS, iPadOS, macOS 및 visionOS 26은 패스키를 기반으로 빌드되었으며 앱과 웹사이트에서 패스코드를 더 쉽게 발견하고 생성하며 사용할 수 있도록 새 개선 사항을 포함하고 있습니다 주요 업데이트 5가지를 보겠습니다 첫째, 새 계정 생성 API입니다 새 계정을 만드는 가장 빠르고 쉬운 방법이며 처음부터 패스키가 제공됩니다

    그런 다음 암호를 최신으로 유지하는 방법을 다루며 자격 증명 관리자를 통한 계정 변경 사항 동기화 방법을 봅니다

    다음은 기존 암호 기반 계정에 패스키를 추가하는 데 원활한 경로 역할을 하는 자동 패스키 업그레이드입니다 이어서 패스키 관리 엔드포인트로, 자격 증명 관리자에서 바로 서비스의 패스키를 보여 주는 방법이죠

    마지막은 패스키 가져오기 및 내보내기인데 패스키를 더 유연하게 활용하고 효과적으로 제어할 수 있는 중요 에코시스템 개선 사항입니다

    첫 번째로 새 계정 생성 API입니다 기존의 암호 기반 가입과 달리 패스키 설정 과정은 길거나 복잡하지 않습니다 쉽게 빠르고 간단하게 가입합니다 패스키는 복잡한 암호를 만들고 기억해야 하는 방식이 아닙니다

    패스키로 빠르고 간편하게 로그인하고 피싱을 방지할 수 있죠 계정 생성 API 및 최신 OS 릴리즈를 통해 가입 경험이 원활하고 빠르며 근본적으로 더 안전해집니다

    iPhone에서 하루 한 장 귀여운 사진을 주는 데모 앱 Shiny를 사용해 보여 드리겠습니다

    새 앱에서 첫 번째 단계는 당연히 가입입니다 계정 생성 API를 채택하기 전의 기존 방식인데요 이메일로 새 계정을 만들어 보겠습니다

    이메일부터 시작해 양식을 작성하라고 하죠 다행히 자동 완성 기능이 도움이 됩니다 이메일을 입력했고요 이제 이름과 성을 입력해야 합니다

    물론 골칫거리인 암호도요 최선의 시나리오로 자동 생성된 강력한 암호를 사용하겠습니다

    모두 작성하고 마지막으로 Continue(계속)를 탭하면 완료죠 귀여운 사진이네요 사랑스러워요 이제 계정 생성 API를 채택하고 다시 해 보겠습니다 비슷하게 이메일로 새 계정을 만들겠습니다

    하지만 다단계 형식 대신 시스템에서 Shiny가 요청하는 정확한 항목의 시트를 표시합니다 이 경우에는 이름과 이메일 그리고 암호 앱에 저장될 패스키입니다 가장 좋은 점은 모든 내용이 미리 채워져 있다는 거죠 이것이 계정 생성 API 사용 시의 간소화된 새 흐름입니다 공유하는 정보는 편집 가능합니다 필드를 탭하면 제안 사항 선택기가 표시되어 항목 간에 전환하거나 수동으로 입력할 수 있습니다 저는 기본값에 만족합니다 Continue(계속)를 탭하면 Face ID 인증을 거쳐 완료됩니다 Shiny 가입이 끝났습니다 훨씬 빠르고 간단하며 안전하죠

    로그인도 마찬가지로 간편합니다

    나중에 iPad에서 Shiny를 처음으로 실행하면

    즉시 로그인 메시지가 표시되는데 앱 실행 시 기존 자격 증명을 확인하게 설정되어 있기 때문이죠 앞서 만든 패스키는 모든 기기에서 사용할 수 있습니다 Continue(계속)를 탭해 Face ID를 거쳐 로그인되니 정말 쉽죠! 이 경험은 iOS, iPadOS, macOS 및 visionOS의 앱에서 이용 가능하며 암호 앱과 타사 자격 증명 관리자에서도 작동합니다

    이제 가입 경험을 강화해 주는 구현을 살펴보겠습니다

    이것은 계정 생성의 핵심 단계를 보여 주는 함수입니다 먼저 새로운 계정 생성 제공자를 초기화합니다 이어서 해당 제공자로 패스키 등록 요청을 생성합니다 이 메서드에서 주요 세부 사항이 지정됩니다 첫 번째 매개변수는 acceptedContactIdentifiers입니다 앱에서 지원되는 계정 식별자를 시스템에 알려 주는 역할을 합니다 앱은 계정을 생성하는 데 하나의 선택된 식별자만 수신하며 이 식별자는 패스키의 사용자 이름 레이블로 사용됩니다 shouldRequestName은 사용자의 이름 요청 여부를 결정합니다 계정 생성에 필요할 때만 true로 설정해야 합니다 그 다음 세 가지는 생성될 패스키와 관련이 있습니다 표준 패스키 등록과 일치하며 해당 요청에 입력할 데이터를 그대로 입력하면 됩니다

    패스키를 등록할 신뢰 당사자는 일반적으로 도메인 이름이며 생성한 패스키로 서명해야 하는 일회용 챌린지는 서버에서 가져옵니다 사용자 ID는 계정에 대해 생성하는 안정적이고 고유한 식별자입니다 이어서 ASAuthorizationController에 대한 인스턴스를 가져옵니다 SwiftUI 보기에서 Environment 속성 래퍼로 접근할 수 있습니다 그런 다음 요청을 수행합니다 사용자가 성공적으로 가입 흐름을 완료하면 ASAuthorizationResult를 받게 됩니다 래핑을 해제하면 연락처 식별자, 요청된 경우 이름 그리고 패스키 객체에 접근할 수 있습니다 계속해서 서버에 계정을 만들고 로그인시킵니다

    여기까지가 채택의 핵심입니다 문제가 생기면 perform 메서드가 오류를 유발하며 이에 대처해 모든 경우에서 훌륭한 경험을 구축할 수 있습니다 일반적인 AuthenticationServices 오류 외에 이 API와 특히 관련이 있는 세 가지 오류를 처리해야 하는데요 첫 번째는 deviceNotConfiguredForPasskeyCreation입니다 기기가 패스키를 생성할 수 있는 상태가 아님을 의미합니다 암호가 설정되지 않은 경우처럼요 이때는 표준 가입 양식을 표시할 수 있습니다 현재 패스키 생성에 적합하지 않으니 말입니다 Shiny에서 Use email or phone number (이메일 또는 전화번호 사용) 버튼을 탭하면 맞춤형 가입 양식을 표시하여 이 오류가 처리됩니다 다음은 canceled입니다 사용자가 등록 시트를 완성하지 않고 닫으면 발생하는 오류입니다 이 경우에는 표준 가입 양식을 표시할 수 있습니다 Shiny에서 시스템 시트를 닫으면 맞춤형 가입 양식을 표시하여 이 오류가 처리됩니다 마지막은 preferSignInWithApple입니다 앱이 Apple로 로그인 기능을 지원할 때만 발생하는 오류인데요 실수로 계정이 중복되는 것을 방지하도록 설계된 것입니다 사용자가 계정 생성 흐름을 시작했지만 Apple로 로그인 기능을 사용하는 계정이 이미 서비스에 있다면 시스템에서 이러한 알림을 표시하여 안내해 줍니다 사용자는 기존 Apple로 로그인 계정 사용과 새 계정 생성 중 선택할 수 있는데 기존 계정을 사용하면 이 오류가 발생합니다 이 오류가 발생하면 Apple로 로그인 요청을 시작하는 것이 모범 사례입니다 그러면 Apple로 로그인 시트가 표시됩니다 사용자의 선택을 존중해 추가로 탭할 필요 없이 기존 계정에 로그인하게 하는 거죠 오류에 대한 설명은 여기까지고요 또 다른 모범 사례는 앱 실행 시 즉시 기존 계정을 제시하는 것입니다 사용자가 앱에 다시 로그인하게 안내하는 방식이죠 앞서 iPad 데모에서 패스키로 로그인하라는 메시지가 즉시 표시되었기 때문에 기존 계정이 있는지 또는 이전에 어떻게 로그인했는지 생각할 필요가 없었습니다 Shiny가 즉시 사용 가능한 자격 증명 선호 옵션이 설정된 통합된 로그인 요청을 사용했기 때문입니다 사용자의 기기에 자격 증명 관리자 앱이나 Apple로 로그인 기능을 사용하는 계정의 패스키 또는 암호처럼 사용 가능한 계정 자격 증명이 있다면 로그인 옵션이 표시됩니다 즉시 사용 가능한 자격 증명이 없다면 UI가 표시되지 않으며 로그인 화면을 중단 없이 진행할 수 있습니다 채택에 대한 자세한 내용은 WWDC22 “패스키 소개”를 시청하세요

    지금까지 간편하고 안전한 가입을 위한 새로운 기능인 계정 생성 API를 알아보았습니다

    계정이 생성된 후 자격 증명 관리자에서 패스키 정보가 정확하게 유지되도록 하면 원활한 경험을 지속할 수 있습니다 그래서 다음 주제는 패스키를 최신으로 유지하는 것입니다 계정은 정적 상태가 아닙니다 사용자는 사용자 이름, 이메일 주소 등의 정보를 업데이트하며 패스키를 취소할 수도 있습니다 로그인 중 자격 증명 관리자가 오래된 정보를 표시하면 혼란스러울 수 있으며 서비스에 로그인하는 것이 지체되거나 불가능해질 수 있습니다 앱 또는 웹사이트가 계정 변경 사항에 대해 자격 증명 관리자에 신호를 보낼 수 있는 새 API 컬렉션이 출시되었습니다 이러한 신호 API를 채택하면 항목이 정확하게 유지되므로 로그인이 빠르고 안정적이며 문제 없이 작동합니다

    Shiny에서 작동하는 방식을 보면 최근 대학교를 졸업해서 이전 학생 이메일 계정을 개인 이메일로 바꾼다고 해 보죠

    앱 설정으로 가서 이메일을 탭하고 새 이메일을 입력합니다

    그리고 저장합니다

    그 직후 자격 증명 관리자인 암호 앱에서 사용자 이름이 변경되었음을 알립니다

    이것을 탭하면 암호 앱에서 인증을 거친 후 계정의 세부 사항을 표시합니다

    사용자 이름에 새로운 개인 이메일이 반영되었습니다 이제 자격 증명 관리자의 내용이 앱 백엔드의 내용과 일치합니다 참 편리하죠! 앱과 웹에서 사용할 수 있는 새 API 덕분에 가능합니다 앱의 경우 새 ASCredentialUpdater 클래스가 특정 자격 증명 변경 사항을 보고하는 메서드를 제공합니다 웹의 경우 동등한 방법이 Safari 19 및 기타 브라우저의 지원 WebAuthn 표준에 속합니다

    첫 번째 신호는 사용자 이름을 변경하기 위한 것입니다 데모에서처럼 사용자가 사용자 이름이나 이메일 주소 또는 계정에 표시된 레이블을 업데이트하면 reportPublicKeyCredentialUpdate 메서드로 자격 증명 관리자에 알립니다 이를 통해 로그인 중 표시되는 레이블이 항상 최신으로 유지되어 혼란을 방지합니다 참고로 패스키의 사용자 이름은 로컬 전용 레이블입니다 인증 중에 서버로 반환되지 않습니다

    웹의 경우 같은 작업을 위해 PublicKeyCredential에 signalCurrentUserDetails 메서드를 사용합니다

    다음으로 패스키를 취소합니다 대다수의 앱 및 웹사이트에는 개별 패스키를 취소하거나 새 패스키를 만들 수 있는 패스키 관리 페이지가 있습니다 패스키가 취소되면 reportAllAcceptedPublicKeyCredentials 메서드를 호출해 유효한 상태로 남는 자격 증명 ID를 지정합니다 이로써 자격 증명 관리자에 있지만 사용자가 제공한 세트에는 없는 패스키를 자격 증명 관리자가 삭제합니다 따라서 로그인할 때 잘못된 패스키를 제안하지 않습니다 계정의 상태 확인차 주기적으로 이 메서드를 호출할 수도 있습니다 이렇게 하면 변경 사항이 있을 때 자격 증명 관리자가 바로 파악할 수 있습니다

    웹에서도 signalAllAcceptedCredentials 메서드로 동일한 작업을 수행할 수 있습니다

    궁극적으로 가장 안전한 계정은 암호가 아예 없는 계정입니다 새 계정 생성 API로 생성된 계정에는 애초에 암호가 없기 때문에 처음부터 안전합니다

    기존 계정의 경우 암호가 더 이상 필요하지 않으면 자격 증명 관리자에 알릴 수 있습니다 reportUnusedPasswordCredential API는 계정이 패스키 여정의 마지막 단계를 완료하여 더 이상 암호가 없다는 신호를 보냅니다

    물론 모든 자격 증명 관리자가 이 신호 처리에 참여 가능합니다 업데이트 신호를 듣고 최신 관리 대상 자격 증명을 유지하려면 새 API를 채택해야 합니다 자세한 내용은 ASCredentialProviderViewController에 대한 report 메서드를 다룬 개발자 문서를 확인하세요 이 새 API로 자격 증명의 정확성을 유지할 수 있습니다 다음으로는 특히 암호로 로그인하는 사용자를 위한 패스키 채택 장려 관련 내용을 주로 살펴보겠습니다 자동 패스키 업그레이드는 기존 암호 기반 계정에 패스키를 추가하는 데 원활한 경로 역할을 합니다 앱 또는 웹사이트에서 암호 로그인 직후 원활하게 패스키를 생성할 수 있습니다 지금 보여 드리겠습니다 Shiny로 돌아와서 아직 암호를 사용 중이며 로그인한다고 해 보죠 사용자 이름과 암호를 자동으로 채우고 Sign In(로그인)을 탭해 로그인합니다 Shiny에서 자동 패스키 업그레이드를 채택했기 때문에 이제 이렇게 됩니다 패스키 생성 알림을 받았습니다 업셀 화면이나 중단 없이 원활한 전환으로 더 간편하고 안전한 로그인 경험이 마련됩니다 방금 사용한 암호도 작동한다는 점에 유의하세요 이 과정은 안전한 로그인 방법으로 패스키를 추가할 뿐입니다 코드로 보면 이것이 자동 패스키 업그레이드입니다 사용자가 암호로 로그인하면 계정 세부 사항에 접근할 수 있죠 먼저 계정에 이미 패스키가 있지 않은지 확인합니다 없다면 패스키를 생성할 때처럼 패스키 등록 요청을 생성합니다 requestStyle을 conditional로 설정하면 자동 패스키 업그레이드가 활성화됩니다 이렇게 설정하고 요청을 수행하면 시스템과 자격 증명 관리자가 백그라운드에서 확인합니다 자격 증명 관리자가 사용 가능한지 계정 암호가 방금 사용되었는지, 기기가 패스키를 위해 설정되었는지 확인합니다 모든 사전 조건이 충족되면 시스템에서 패스키를 생성하고 알림을 표시하며 앱은 저장할 패스키 객체를 받습니다 모두 사용자 중단 또는 차단 없이 진행됩니다 사전 조건이 충족되지 않으면 호출이 조용히 실패합니다 시스템이 UI를 표시하지 않으며 오류 처리가 필요하지 않습니다 사용자에게 아직 패스키가 없다면 암호 로그인 시마다 앱이 업그레이드를 시도해야 합니다

    동등한 웹 API도 있습니다 자동 패스키 업그레이드에 대해 자세히 알아보려면 WWDC24 비디오 “패스키 업그레이드 및 자격 증명 관리 앱으로 로그인 간소화하기”를 시청하세요 자동 업그레이드는 이상적이고 원활한 경로에 해당합니다

    이를 보완하기 위해 잘 알려진 패스키 관리 엔드포인트용 URL을 채택하면 자격 증명 관리자에서 패스키 관리 페이지로의 직접 링크를 표시할 수 있습니다 패스키 채택을 강조하기에 좋은 방법이죠 지금 보여 드리겠습니다 현재 암호 앱에서 아직 암호를 사용하는 저장된 Shiny 항목을 검토 중입니다 사용 가능한 패스키 업그레이드가 있음이 새 섹션에 표시됩니다 Add Passkey(패스키 추가) 버튼을 탭하면 지정된 패스키 등록 페이지로 바로 웹사이트가 열립니다

    이 표준을 구현하면 자격 증명 관리자에서 패스키 등록 페이지로의 직접 링크가 생성됩니다 사용자가 자격 증명 관리자에서 바로 업그레이드할 수 있는 또 다른 방법이죠 표준에 기초해 빌드되어 있으므로 모든 참여 자격 증명 관리자에서 작동합니다

    이를 지원하기 위해 서버의 잘 알려진 패스키 엔드포인트 경로에서 JSON 응답을 조사합니다 응답은 리디렉션이 아니라 이 경로에서 직접 나와야 합니다

    상태 코드 200 OK, Content-Type 헤더 application/json으로 이 응답을 제공합니다

    응답 내용은 웹사이트 내 관련 페이지를 가리키는 JSON 딕셔너리입니다

    enroll은 사용자가 패스키를 계정에 추가하는 URL입니다 암호 앱의 Add Passkey(패스키 추가) 버튼이 여기에 연결됩니다 manage는 변경된 암호 페이지와 비슷하게 사용자가 기존 패스키를 관리하는 URL입니다 기존 패스키를 취소하거나 새 패스키를 추가할 수 있습니다

    모든 필드는 선택 사항이지만 모두 있는 것이 좋습니다 이러한 URL은 인증된 세션 없이 도착하는 사용자를 올바르게 처리해야 합니다 로그인이 필요하면 먼저 인증한 후 원래 요청된 URL로 리디렉션합니다

    페이지가 모든 사용자 에이전트에 접근 가능하고 제공되어야 합니다 이 페이지는 웹 브라우저에서만 요청하지 않고 자격 증명 관리자 같은 앱에서도 요청합니다

    패스키 관리 엔드포인트용으로 잘 알려진 URL을 구현하면 서비스의 패스키를 채택하도록 사용자를 안내하는 데 자격 증명 관리자에 힌트를 주는 것입니다

    다음은 패스키 가져오기 및 내보내기입니다

    사용자는 자신의 자격 증명을 소유하며, 원하는 곳에서 이를 관리할 수 있어야 합니다 이제 iOS, iPadOS, macOS 및 visionOS 26에서 자격 증명 관리자 앱 간에 패스키를 안전하게 전송할 수 있습니다 따라서 사용자가 데이터와 사용할 자격 증명 관리자 선택을 더 효과적으로 제어할 수 있습니다

    이 새로운 과정은 기존 자격 증명 내보내기 방법과 근본적으로 다르며 더 안전합니다 이전에는 암호화되지 않은 CSV 또는 JSON 파일을 내보낸 후 다른 앱에 수동으로 가져왔습니다 전송 과정은 사용자가 시작하며 참여 자격 증명 관리자 앱 간에 직접 이루어지고 Face ID 등 로컬 인증으로 보호됩니다 이 전송은 FIDO Alliance 구성원과의 협업으로 빌드된 데이터 스키마를 사용합니다 이 스키마는 패스키, 암호, 확인 코드와 기타 데이터 유형의 데이터 형식을 표준화합니다 시스템은 앱 간 데이터 이동에 안전한 메커니즘을 제공합니다 디스크에 안전하지 않은 파일이 생성되지 않아 내보낸 파일의 자격 증명 유출 위험이 없습니다 자격 증명을 이동하는 현대적이고 안전한 방법입니다

    앱과 웹사이트에서 자격 증명 전송 수용을 위해 취할 조치는 없죠 과정이 자격 증명 관리자 간에 직접 이루어지기 때문입니다 기존 패스키는 변경 없이 유지되고 계속 원활하게 작동합니다 자격 증명 전송 지원을 고려하는 자격 증명 관리자 앱은 ASCredentialExportManager 및 ASCredentialImportManager에 대한 개발자 문서를 참고하세요

    패스키는 계속 발전하면서 더 간편한 경험으로 더 강력한 보안을 제공하고 있습니다 새로운 OS 릴리즈로 더 쉽게 만들고 사용하고 발견할 수 있죠 암호 없는 미래를 향한 여정에 우리 모두 함께입니다 모두를 위해 이 미래를 현실로 만들려면 이 기능을 채택해 주셔야 합니다 최고의 인증 경험을 계속 제공하기 위한 다음 단계를 알려 드립니다 우선 안전하고 빠른 온보딩을 위해 계정 생성 API를 채택합니다 다음으로 업데이트된 사용자 이름, 패스키 제거 등 계정 변경 사항을 자격 증명 관리자에 알리는 Signal API로 패스키를 최신으로 유지하고, 가장 원활한 암호 전환을 위해 자동 패스키 업그레이드를 활성화합니다 마지막으로 웹사이트에서 패스키 관리 엔드포인트를 제공해 자격 증명 관리자가 패스키 업그레이드를 발견하도록 합니다 패스키의 새로운 기능 세션을 시청해 주셔서 감사합니다

    • 6:33 - Account creation

      // Account creation
      
      @Environment(\.authorizationController) var authorizationController
      
      func performPasskeySignUp() async throws {
          let provider = ASAuthorizationAccountCreationProvider()
          let request = provider.createPlatformPublicKeyCredentialRegistrationRequest(
              acceptedContactIdentifiers: [.email, .phoneNumber],
              shouldRequestName: true,
              relyingPartyIdentifier: "example.com",
              challenge: try await fetchChallenge(),
              userID: try await fetchUserID()
          )
      
          do {
              let result = try await authorizationController.performRequest(request)
              if case .passkeyAccountCreation(let account) = result {
                  // Register new account on backend
              }
          } catch
              ASAuthorizationError
              .deviceNotConfiguredForPasskeyCreation {
              showPasswordSignUpForm = true
          } catch ASAuthorizationError.canceled {
              showPasswordSignUpForm = true
          } catch
              ASAuthorizationError.preferSignInWithApple {
              await performSignInWithApple()
          } catch { ... }
      }
    • 12:30 - Changing the user name

      // Changing the user name
      
      try await ASCredentialUpdater()
          .reportPublicKeyCredentialUpdate(
              relyingPartyIdentifier: "example.com",
              userHandle: userHandle,
              newName: "andrew@example.com"
          )
    • 12:58 - Changing the user name

      // Changing the user name
      
      await PublicKeyCredential.signalCurrentUserDetails({
          rpId: "example.com",
          userId: userHandle,
          name: "andrew@example.com",
          displayName: "andrew@example.com"
      });
    • 13:07 - Revoking a passkey

      // Revoking a passkey
      
      try await ASCredentialUpdater()
          .reportAllAcceptedPublicKeyCredentials(
              relyingPartyIdentifier: "example.com",
              userHandle: userHandle,
              acceptedCredentialIDs: acceptedCredentialIDs
          )
    • 13:46 - Revoking a passkey

      // Revoking a passkey
      
      await PublicKeyCredential.signalAllAcceptedCredentials({
          rpId: "example.com",
          userId: userHandle,
          allAcceptedCredentalIds: acceptedCredentialIds
      });
    • 14:04 - Removing a password

      // Removing a password
      
      try await ASCredentialUpdater()
          .reportUnusedPasswordCredential(
              domain: "example.com",
              username: "andrew@example.com"
          )
    • 15:36 - Automatic passkey upgrade

      // Automatic passkey upgrade
      
      func signIn() async throws {
          let accountDetails = try await signInWithPassword()
          guard !accountDetails.hasPasskey else { return }
      
          let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
              relyingPartyIdentifier: "example.com")
      
          let request = provider.createCredentialRegistrationRequest(
              challenge: try await fetchChallenge(),
              name: accountDetails.userName,
              userID: accountDetails.userID,
              requestStyle: .conditional
          )
      
          do {
              let passkey = try await authorizationController.performRequest(request)
              // Save new passkey to the backend
          } catch { ... }
      }
    • 0:00 - 서론
    • 업계 전체가 암호를 폐지하고 패스키를 도입하기 위해 노력하고 있습니다. 패스키는 피싱을 예방하고 로그인 절차를 간소화하는 더 안전하고 사용자 친화적인 방법입니다.

    • 0:58 - 패스키 여정
    • iOS, iPadOS, macOS 및 visionOS 업데이트 덕분에 패스키를 더 쉽게 생성, 관리, 업그레이드할 수 있으므로 패스키를 더 빨리 채택할 수 있습니다. 업계는 피싱이 가능한 암호와 SMS/이메일 코드에서 피싱이 불가능한 패스키로 전환하고 있습니다. 여러 계정에서 추가 로그인 방법으로 패스키를 제공하지만, 패스키의 목적은 피싱 가능한 요소를 완전히 제거하는 것입니다. 패스키의 채택은 급속히 증가하고 있으며, 패스키를 사용하면 로그인 성공률이 높습니다. FIDO Alliance에 따르면 사용자의 69%가 최소한 1개의 패스키를 가지고 있으며, Google은 패스키로 로그인할 때가 암호를 사용할 때보다 로그인 성공 비율이 4배 더 높다고 발표한 바 있고, TikTok에서는 패스키를 사용한 로그인 성공 비율이 97%라고 밝혔습니다.

    • 3:30 - 계정 생성 API
    • 새로운 계정 생성 API는 앱의 가입 과정을 혁신했습니다. 이 API는 iOS, iPadOS, macOS, visionOS에서 사용할 수 있으며, 암호 앱과 타사 자격 증명 관리자와 호환됩니다. 이제 사용자는 패스키를 사용하여 직접 계정을 생성할 수 있으므로 사용자 경험이 더욱더 편리해졌으며 피싱 공격이 발생할 위험도 감소했습니다. 계정 생성 API를 통한 가입 절차는 매우 간소화되었습니다. 여러 단계로 구성된 양식 대신 미리 채워진 시트가 앱이 가입 시 요구하는 정보를 정확히 표시합니다. 사용자는 이 양식을 맞춤화할 수 있습니다. 완료되면 시스템에서 자동으로 패스키를 생성하여 암호 앱에 저장합니다. 패스키의 이점은 가입에만 국한되지 않습니다. 로그인이 매우 간편해지며, 패스키는 모든 기기에서 자동으로 동기화됩니다. 계정 생성 API는 채택하기 쉽고, 잠재적인 오류를 완벽하게 처리하므로 기기가 패스키 생성을 위해 구성되지 않았거나 이미 Apple로 로그인을 사용하는 계정이 있는 경우에도 원활한 가입 경험을 제공합니다.

    • 10:48 - 패스키를 최신 상태로 유지하기
    • 새로운 신호 API를 사용하면 앱 및 웹사이트에서 사용자 이름, 이메일 주소 또는 패스키가 취소된 경우와 같이 계정 정보가 변경되었을 때 자격 증명 관리자에 알릴 수 있습니다. 이렇게 하면 자격 증명 관리자가 최신 상태로 유지되므로 혼란과 로그인 문제를 방지할 수 있습니다. 예를 들어, 사용자가 앱에서 이메일 주소를 업데이트하면 앱이 즉시 자격 증명 관리자에 신호를 전송하며, 자격 증명 관리자는 자체 기록을 업데이트합니다. 이러한 API는 암호가 없는 계정을 지원합니다. 암호가 없는 계정이 가장 안전한 계정입니다. API는 암호가 더 이상 필요하지 않을 때 자격 증명 관리자에 이를 알려 전반적인 보안을 강화하고 사용자 경험을 개선합니다.

    • 14:41 - 자동 패스키 업그레이드
    • 자동 패스키 업그레이드는 암호를 사용하여 로그인하는 사용자를 위해 원활하게 계정 보안을 강화합니다. 암호로 로그인이 완료되면 앱과 웹사이트가 백그라운드에서 패스키를 생성할 수 있습니다. 암호 키가 추가되면 알림을 통해 알려 주므로, 앞으로 더 간편하고 안전한 로그인 옵션을 제공할 수 있습니다. 암호는 유효한 상태로 남으며, 패스키가 존재하지 않으면 암호로 로그인을 시도할 때마다 업그레이드 프로세스가 실행됩니다.

    • 16:59 - 패스키 관리 엔드포인트
    • 표준화된 잘 알려진 패스키 관리 엔드포인트용 URL을 구현하면 웹사이트가 자격 증명 관리자와 패스키 등록 및 관리 페이지를 직접 연결할 수 있습니다. 이러한 접근 방식은 암호 키 업그레이드 프로세스를 간소화하여 사용자가 자격 증명 관리자 내에서 암호를 쉽게 전환할 수 있도록 합니다. 서버에서 보내는 JSON 응답에는 등록 및 관리에 대한 URL이 포함되어야 하고, ‘200 OK’ 상태 코드와 함께 제공되어야 하며, 앱 및 웹 브라우저를 포함한 모든 사용자 에이전트에서 접근할 수 있어야 합니다.

    • 19:12 - 패스키 가져오기 및 내보내기
    • 패스키는 이제 iOS, iPadOS, macOS, visionOS 26에서 모든 참여 자격 증명 관리자 앱 간에 안전하게 전송될 수 있습니다. 사용자가 시작하는 이 프로세스는 Face ID와 같은 로컬 인증으로 보호되어 자격 증명 유출 위험을 줄입니다. 이 전송은 FIDO Alliance에서 개발한 표준화된 데이터 스키마를 사용하므로 앱 간의 호환성이 보장됩니다. 최고의 인증 경험을 제공하고 사용자가 암호가 없는 더 안전한 미래로 나아갈 수 있도록 도와주세요. 안전하고 빠른 온보딩을 위해 계정 생성 API를 채택하고, 신호 API를 사용하여 패스키를 최신 상태로 유지하고, 자동 패스키 업그레이드를 활성화하고, 패스키 관리 엔드포인트를 지원하세요.

Developer Footer

  • 비디오
  • WWDC25
  • 패스키의 새로운 기능
  • 메뉴 열기 메뉴 닫기
    • iOS
    • iPadOS
    • macOS
    • tvOS
    • visionOS
    • watchOS
    메뉴 열기 메뉴 닫기
    • Swift
    • SwiftUI
    • Swift Playground
    • TestFlight
    • Xcode
    • Xcode Cloud
    • SF Symbols
    메뉴 열기 메뉴 닫기
    • 손쉬운 사용
    • 액세서리
    • 앱 확장 프로그램
    • App Store
    • 오디오 및 비디오(영문)
    • 증강 현실
    • 디자인
    • 배포
    • 교육
    • 서체(영문)
    • 게임
    • 건강 및 피트니스
    • 앱 내 구입
    • 현지화
    • 지도 및 위치
    • 머신 러닝 및 AI
    • 오픈 소스(영문)
    • 보안
    • Safari 및 웹(영문)
    메뉴 열기 메뉴 닫기
    • 문서(영문)
    • 튜토리얼
    • 다운로드(영문)
    • 포럼(영문)
    • 비디오
    메뉴 열기 메뉴 닫기
    • 지원 문서
    • 문의하기
    • 버그 보고
    • 시스템 상태(영문)
    메뉴 열기 메뉴 닫기
    • Apple Developer
    • App Store Connect
    • 인증서, 식별자 및 프로파일(영문)
    • 피드백 지원
    메뉴 열기 메뉴 닫기
    • Apple Developer Program
    • Apple Developer Enterprise Program
    • App Store Small Business Program
    • MFi Program(영문)
    • News Partner Program(영문)
    • Video Partner Program(영문)
    • Security Bounty Program(영문)
    • Security Research Device Program(영문)
    메뉴 열기 메뉴 닫기
    • Apple과의 만남
    • Apple Developer Center
    • App Store 어워드(영문)
    • Apple 디자인 어워드
    • Apple Developer Academy(영문)
    • WWDC
    Apple Developer 앱 받기
    Copyright © 2025 Apple Inc. 모든 권리 보유.
    약관 개인정보 처리방침 계약 및 지침