안녕하세요,
Apple의 Passkeys 시스템에 대한 지원을 제안드립니다.
Discourse Apple Authentication? 와 비교했을 때 큰 차이점은 무엇인가요?
2개의 좋아요
그러나 이전 구현 방식에서는 사용자가 비밀번호 없는 기능을 사용하려면 각 웹사이트나 앱에 모든 기기로 각각 로그인해야 했습니다. 이번 확장된 약속에 따라 사용자는 모든 계정을 다시 등록할 필요 없이, 새 기기를 포함한 여러 기기에서 자동으로 패스키에 접근할 수 있게 됩니다. 또한, 사용자는 모바일 기기의 FIDO 인증을 통해 가까운 기기의 앱이나 웹사이트에 로그인할 수 있으며, 이는 해당 기기의 OS 플랫폼이나 브라우저와 무관합니다.
아마도 단순하게 정교화된 프로토콜일 것 같습니다. 새로운 iOS 출시 시점에 가까워지면 더 자세히 알게 될 것이라고 확신합니다.
4개의 좋아요
CDCK가 직접 구현해야 하는 것인 줄 몰랐습니다. 웹 브라우저나 운영체제에 의존하는 기능인 줄 알았거든요?
그리고 명확히 하자면, Passkeys는 Apple이 만든 표준이 아닙니다. FIDO Alliance가 만든 것입니다. Apple은 이 표준을 채택하는 수많은 기업 중 하나일 뿐입니다.
Passkeys는 SSO(단일 로그인)의 일종이 아닙니다.
Apple의 구현 방식은 훨씬 더 다르고 흥미로워 보였는데, 키노트에서 무언가를 잘못 이해한 건지 모르겠습니다… 
Apple이 새로운 운영체제 버전을 출시하면 이 기능이 어떻게 발전해 나갈지 기대됩니다.
1개의 좋아요
일종의 공개/비공개 키 암호화를 사용하는 건가요?
애플이 관여되면 항상 조심하게 됩니다. 애플은 사용자를 자사 생태계에 묶어두기 위해 독점적인 방식을 만드는 걸 좋아하거든요 …
2개의 좋아요
FIDO 얼라이언스의 개방형 표준을 기반으로 해야 한다고 합니다. 구글, 마이크로소프트를 비롯한 주요 플랫폼들도 이에 동참하고 있습니다.
애플은 자사 웹사이트에서 애플 기기가 아닌 기기에서도 작동한다고 주장하지만, 이를 어떻게 구현할지에 대한 설명은 제공하지 않고 있습니다.
2개의 좋아요
이것은 사용자의 기기에서만 작동하도록 설계되었습니다.
다행히 이번에는 그렇지 않습니다. 이것은 오픈 표준입니다. 
마이크로소프트와 구글이 실제로 구현하기 전까지는 애플도 그들이 어떻게 구현할지 알 수 없습니다.
1개의 좋아요
논의한 대로, 패스키는 Apple의 자체 시스템이 아닙니다. 심지어 고유명사조차 아닙니다.
패스키는 실제로 Discourse에서 이미 지원되고 있지만, 완벽하지는 않습니다: WebAuthn 보안 키의 형태로 제공되는 것입니다. Discourse가 패스키를 적절히 지원하기 위해 해야 할 유일한 변경 사항은, 보안 키를 2단계 인증 수단으로 사용하는 것이 아니라 비밀번호 대신 사용할 수 있도록 하는 것입니다.
Apple은 UX 구현 방법에 대한 동영상을 보유하고 있으며, 다른 많은 회사들도 마찬가지일 것입니다. 하지만 여기에서 관련된 핵심 사항들을 요약하겠습니다.
패스키(이하 "등록된 보안 키"라고 함)에 대한 완벽한 지원을 구현하기 위해 Discourse는 다음 변경 사항만 수행하면 됩니다:
- 로그인 모달을 수정하여, 등록된 보안 키가 없는 계정의 이메일 주소를 입력한 경우에만 비밀번호 필드를 표시하도록 합니다. 패스키가 비밀번호가 아닌 기본 옵션으로 제시되어야 합니다. 사용자가 둘 다 가지고 있다면 비밀번호를 백업 옵션으로 취급해야 합니다: 패스키는 다른 기기를 인증하는 시스템이 있으므로, 비밀번호를 사용해야 하는 유일한 이유는 브라우저가 너무 오래되어 패스키 지원을 전혀 구현하지 않은 경우입니다. 이 경우는 점점 더 드물어질 것입니다.
- 등록된 보안 키를 유일한 인증 수단으로 허용합니다: 비밀번호를 요구하지 말고, 어떤 다중 인증 방법도 사용하지 마십시오. TOTP 코드를 요구하는 것은 의미가 없습니다. WebAuthn 개인 키를 가진 사람은 TOTP를 생성하는 데 사용되는 1회용 코드 생성용 공유 비밀키도 가지고 있기 때문입니다. 후자는 실제로는 Discourse 인스턴스에서 처음부터 생성되므로 훨씬 쉽게 탈취될 수 있습니다: 이것은 공유 비밀키이기 때문입니다.
- 등록된 보안 키를 가진 사용자가 비밀번호를 삭제할 수 있도록 허용합니다.
- 사용자가 비밀번호를 사용하는 경우에만 2단계 인증 방법을 사용하십시오.
이 내용은 이미 Webauthn의 원본 스펙에서 다루어졌습니다.
그러나 우리는 첫 번째, 그리고 가장 일반적인 Webauthn 방법만 구현했습니다.
음, 먼저 1차 인증인 WebAuthn은 이제 "패스키(passkeys)"라고 불리며, 이제 이를 고려할 시기가 되었습니다.
둘이 동일한 것임을 보여주기 위해, iOS 16에서 이메일과 비밀번호를 입력한 후 Safari를 통해 Tor 프로젝트의 Discourse 인스턴스에 로그인하는 현재 모습은 다음과 같습니다.
1개의 좋아요
그리고 macOS Monterey(한 세대 이전)의 Safari에서 동일한 키를 사용한 경우:
macOS Ventura가 iOS 16과 일치하도록 언어를 변경할 것으로 추정됩니다.
참고로, 사용자 관점에서 기존 WebAuthn 대비 가장 큰 혁신은 선택한 종단 간 암호화 비밀번호 관리자를 통해 개인 키를 동기화할 수 있다는 점입니다.
3개의 좋아요
벌써 3~4개월은 훌쩍 넘은 것 아닌가요? 그러면 1단계 인증(First Factor) 지원을 활성화할 수 있는 시기가 된 건가요?
관리자 옵션으로 선택적으로 추가하는 것은 괜찮지만, 1~2개월 동안 이 작업을 진행할 여유가 있다고 생각하지 않습니다.
1개의 좋아요
#marketplace에서 누군가 이 프로젝트에 기부를 해줄 의향이 있을까요?
안드로이드에도 출시 예정
3개의 좋아요
마이크로소프트의 구현 방식이 연말까지 Windows에 도입될 것이라고 단언할 수 있다.
1개의 좋아요
Android와 iOS 지원이 가능해지면, Discourse에 이를 구현해야 한다는 명확한 지시가 될 것 같습니다. Apple 측에서는 이미 출시되었으므로, 이제 Android를 기다리고 있습니다.
Google Play Services 베타에 가입하고 Chrome Canary를 사용하는 초기 채택자를 위해 오늘 두 가지 기능이 발표되었습니다. 안정 버전은 "올해 후반"에 출시될 예정입니다:
이 기사는 _이번 달_에 작성되었으므로, 2022년 말까지 출시될 수 있을까요?
7개의 좋아요
업데이트
- Passkeys는 이제 chromium에서 안정화되었습니다. (참고: Firefox는 아직 passkeys를 지원하지 않습니다)
- Dashlane, 1password와 같은 비밀번호 관리자가 passkeys 지원 소식을 발표했습니다
12월 11일 기준 passkeys 지원 현황입니다.
출처: Passkey support on Android and Chrome | Passkeys | Google for Developers
2개의 좋아요
또한 https://www.passwordless.dev/ 웹사이트에 멋진 데모 영상이 있습니다
4개의 좋아요
안드로이드도 이제 패스키를 지원한다고 생각합니다