Passkey 및 WebAuthn: 비밀번호 없이 로그인, 마법 없이 로그인

spinny:~/writing $ less passkeys-webauthn-passwordless-authentication.md

1 
2비밀번호는 수년 동안 함께 사용해왔기 때문에 정규화한 것 중 하나입니다. 사용자는 이를 잊어버리고, 재사용하고, 쓰지 말아야 할 곳에 기록합니다. 팀은 재설정, 정책, 해시, 유출, 피싱 및 지원을 관리해야 합니다.
3 
4passkey는 인증을 완벽하게 만들지는 못하지만 큰 문제를 제거합니다. 즉, 서버는 더 이상 사용자와 비밀을 공유할 필요가 없습니다.
5 
6## 실제로 무슨 일이 일어나는가
7 
8A passkey는 WebAuthn를 기반으로 한 자격 증명입니다. 사용자가 이를 생성하면 장치는 키 쌍을 생성합니다.
9 
10- 기기나 비밀번호 관리자에 남아 있는 개인 키
11- 서버가 저장할 수 있는 공개 키.
12 
13서버에 로그인할 때 "비밀번호를 알려주세요"라고 묻지 않습니다. 무작위 도전을 보내세요. 장치는 개인 키로 서명합니다. 서버는 공개 키로 서명을 확인합니다.
14 
15이것이 좋은 부분입니다. 데이터베이스가 도난당한 경우 내부에 해독할 비밀번호가 없습니다. 그리고 사용자가 가짜 도메인에 접속하게 되면 해당 도메인에서는 passkey가 유효하지 않습니다. 이는 단순한 편의성이 아니라 피싱에 대한 구체적인 보호 기능입니다.
16 
17## 브라우저는 브리지 역할을 합니다.
18 
19브라우저에서 두 가지 주요 API는 다음과 같습니다.
20 
21- `navigator.credentials.create()`를 사용하여 passkey를 생성합니다.
22- `navigator.credentials.get()` 로그인 시 사용합니다.
23 
24하지만 중요한 로직은 서버에 있습니다. 서버는 챌린지를 생성하고 임시로 저장한 후 응답을 확인하고 소스와 Relying Party ID를 확인한 다음 세션을 생성해야 합니다.
25 
26클라이언트 부분은 거의 지루할 것입니다.
27 
28```typescript
29const options = await fetch('/api/passkeys/login/options').then((r) => r.json());
30 
31const credential = await navigator.credentials.get({
32  publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options),
33});
34 
35await fetch('/api/passkeys/login/verify', {
36  method: 'POST',
37  headers: { 'Content-Type': 'application/json' },
38  body: JSON.stringify(credential?.toJSON()),
39});
40```
41 
42WebAuthn 암호화를 직접 구현하고 있다면 중지하세요. 강력한 서버 측 라이브러리를 사용하십시오. 여기서 오류는 "귀여운 버그"가 아니라 인증 허점입니다.
43 
44## 데이터베이스에 저장할 내용
45 
46세상의 절반을 구할 필요는 없습니다. 일반적으로 충분합니다.
47 
48- 자격 증명의 ID
49- 공개 키
50- 연결된 사용자;
51- 검증 카운터 또는 메타데이터
52- UX에 유용한 경우 전송;
53- 사용자가 선택한 이름
54- 생성 날짜 및 마지막 사용.
55 
56최소한의 테이블은 다음과 같습니다:
57 
58```sql
59create table passkey_credentials (
60  id uuid primary key default gen_random_uuid(),
61  user_id uuid not null references users(id),
62  credential_id text not null unique,
63  public_key text not null,
64  name text,
65  created_at timestamptz not null default now(),
66  last_used_at timestamptz
67);
68```
69 
70그런 다음 감사 로그와 알림을 추가합니다. 누군가 내 계정에 새 passkey를 생성하면 이에 대해 알고 싶습니다.
71 
72## UX는 데모보다 더 중요합니다
73 
74passkey의 데모는 항상 아름답습니다. 클릭하면 Face ID가 표시됩니다. 실제 제품은 더 복잡합니다.
75 
76누군가 휴대폰을 바꿨습니다. 누군가 잠긴 회사 컴퓨터를 사용하고 있습니다. 어떤 사람들은 브라우저가 passkey를 제안하는 이유를 이해하지 못합니다. 누군가 자신의 기기에 액세스할 수 없게 되었습니다.
77 
78이것이 바로 제가 "오늘부터 더 이상 모든 사람에게 비밀번호를 제공하지 않습니다"로 시작하지 않으려는 이유입니다. 나는 다음과 같이 시작할 것이다:
79 
801. passkey 내부 사용자의 경우 선택 사항입니다.
812. 성공적인 로그인 후 계정을 생성하라는 제안;
823. 이름을 바꾸고 제거할 수 있는 계정 페이지 passkey;
834. 명확한 대체;
845. 기본 로그인이 점진적으로 출시됩니다.
85 
86인터페이스의 텍스트는 단순해야 합니다. "기기의 잠금 화면을 사용하는 것"이 "주민 FIDO2 자격 증명으로 인증하는 것"보다 낫습니다.
87 
88## 피하고 싶은 실수
89 
90클라이언트에 챌린지를 생성하지 마세요. 챌린지는 서버에서 생성되며 한 번만 확인해야 합니다.
91 
92자격 증명 ID만 신뢰하지 마세요. 서명, 보안 질문, 출처 및 Relying Party ID를 확인해야 합니다.
93 
94복구 흐름이 양호해지기 전에는 대체를 삭제하지 마세요. Passwordless는 "휴대폰을 분실하면 영원히 외출을 할 수 없습니다"가 될 필요가 없습니다.
95 
96passkey를 순전히 프런트엔드 버튼으로 취급하지 마세요. 버튼을 숨기는 것은 보안이 아닙니다. 실제 확인은 서버 측에서 이루어집니다.
97 
98## Passkey-우선 또는 passkey-우선?
99 
100새 제품의 경우 passkey-먼저 생각해 보세요. 기존 앱의 경우 passkey 친화적을 선호합니다. 권장 방법으로 passkey을 추가하고 성공 여부와 문제를 측정한 다음 조용히 비밀번호 가중치를 줄입니다.
101 
102이상적인 마이그레이션이 느껴지지 않습니다. 사용자는 회사가 인증 프로토콜을 변경한 것이 아니라 로그인이 더 쉽다는 것을 알게 됩니다.
103 
104## 결론
105 
106passkey는 드물게 보안과 UX를 동시에 향상시키기 때문에 흥미롭습니다. 이는 마술 지팡이가 아닙니다. 복구, 호환성, 지원 및 롤아웃은 여전히 잘 설계되어야 합니다.
107 
108하지만 기본적인 변화는 강하다. 사용자에게 비밀을 만들고 보호하라고 요구하지 마세요. 장치가 도메인에 연결된 암호화 증명에 서명하도록 합니다. 인간의 기억력, 피싱 횟수, 비밀번호 재설정 횟수가 줄어듭니다. 나는 그것들이 진지하게 받아들일 가치가 있다고 말하고 싶습니다.
109 
110## 소스
111 
112- [MDN: Passkeys](https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/Passkeys)
113- [MDN: Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)
114- [W3C: Web Authentication](https://www.w3.org/TR/webauthn-3/)
115- [passkeys.dev](https://passkeys.dev/)
116

:Passkey 및 WebAuthn: 비밀번호 없이 로그인, 마법 없이 로그인lines 1-116 (END) — press q to close

2비밀번호는 수년 동안 함께 사용해왔기 때문에 정규화한 것 중 하나입니다. 사용자는 이를 잊어버리고, 재사용하고, 쓰지 말아야 할 곳에 기록합니다. 팀은 재설정, 정책, 해시, 유출, 피싱 및 지원을 관리해야 합니다.

4passkey는 인증을 완벽하게 만들지는 못하지만 큰 문제를 제거합니다. 즉, 서버는 더 이상 사용자와 비밀을 공유할 필요가 없습니다.

6## 실제로 무슨 일이 일어나는가

8A passkey는 WebAuthn를 기반으로 한 자격 증명입니다. 사용자가 이를 생성하면 장치는 키 쌍을 생성합니다.

10- 기기나 비밀번호 관리자에 남아 있는 개인 키

11- 서버가 저장할 수 있는 공개 키.

13서버에 로그인할 때 "비밀번호를 알려주세요"라고 묻지 않습니다. 무작위 도전을 보내세요. 장치는 개인 키로 서명합니다. 서버는 공개 키로 서명을 확인합니다.

15이것이 좋은 부분입니다. 데이터베이스가 도난당한 경우 내부에 해독할 비밀번호가 없습니다. 그리고 사용자가 가짜 도메인에 접속하게 되면 해당 도메인에서는 passkey가 유효하지 않습니다. 이는 단순한 편의성이 아니라 피싱에 대한 구체적인 보호 기능입니다.

17## 브라우저는 브리지 역할을 합니다.

19브라우저에서 두 가지 주요 API는 다음과 같습니다.

21- `navigator.credentials.create()`를 사용하여 passkey를 생성합니다.

22- `navigator.credentials.get()` 로그인 시 사용합니다.

24하지만 중요한 로직은 서버에 있습니다. 서버는 챌린지를 생성하고 임시로 저장한 후 응답을 확인하고 소스와 Relying Party ID를 확인한 다음 세션을 생성해야 합니다.

26클라이언트 부분은 거의 지루할 것입니다.

28```typescript

29const options = await fetch('/api/passkeys/login/options').then((r) => r.json());

31const credential = await navigator.credentials.get({

32 publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options),

33});

35await fetch('/api/passkeys/login/verify', {

36 method: 'POST',

37 headers: { 'Content-Type': 'application/json' },

38 body: JSON.stringify(credential?.toJSON()),

39});

40```

42WebAuthn 암호화를 직접 구현하고 있다면 중지하세요. 강력한 서버 측 라이브러리를 사용하십시오. 여기서 오류는 "귀여운 버그"가 아니라 인증 허점입니다.

44## 데이터베이스에 저장할 내용

46세상의 절반을 구할 필요는 없습니다. 일반적으로 충분합니다.

48- 자격 증명의 ID

49- 공개 키

50- 연결된 사용자;

51- 검증 카운터 또는 메타데이터

52- UX에 유용한 경우 전송;

53- 사용자가 선택한 이름

54- 생성 날짜 및 마지막 사용.

56최소한의 테이블은 다음과 같습니다:

58```sql

59create table passkey_credentials (

60 id uuid primary key default gen_random_uuid(),

61 user_id uuid not null references users(id),

62 credential_id text not null unique,

63 public_key text not null,

64 name text,

65 created_at timestamptz not null default now(),

66 last_used_at timestamptz

67);

68```

70그런 다음 감사 로그와 알림을 추가합니다. 누군가 내 계정에 새 passkey를 생성하면 이에 대해 알고 싶습니다.

72## UX는 데모보다 더 중요합니다

74passkey의 데모는 항상 아름답습니다. 클릭하면 Face ID가 표시됩니다. 실제 제품은 더 복잡합니다.

76누군가 휴대폰을 바꿨습니다. 누군가 잠긴 회사 컴퓨터를 사용하고 있습니다. 어떤 사람들은 브라우저가 passkey를 제안하는 이유를 이해하지 못합니다. 누군가 자신의 기기에 액세스할 수 없게 되었습니다.

78이것이 바로 제가 "오늘부터 더 이상 모든 사람에게 비밀번호를 제공하지 않습니다"로 시작하지 않으려는 이유입니다. 나는 다음과 같이 시작할 것이다:

801. passkey 내부 사용자의 경우 선택 사항입니다.

812. 성공적인 로그인 후 계정을 생성하라는 제안;

823. 이름을 바꾸고 제거할 수 있는 계정 페이지 passkey;

834. 명확한 대체;

845. 기본 로그인이 점진적으로 출시됩니다.

86인터페이스의 텍스트는 단순해야 합니다. "기기의 잠금 화면을 사용하는 것"이 "주민 FIDO2 자격 증명으로 인증하는 것"보다 낫습니다.

88## 피하고 싶은 실수

90클라이언트에 챌린지를 생성하지 마세요. 챌린지는 서버에서 생성되며 한 번만 확인해야 합니다.

92자격 증명 ID만 신뢰하지 마세요. 서명, 보안 질문, 출처 및 Relying Party ID를 확인해야 합니다.

94복구 흐름이 양호해지기 전에는 대체를 삭제하지 마세요. Passwordless는 "휴대폰을 분실하면 영원히 외출을 할 수 없습니다"가 될 필요가 없습니다.

96passkey를 순전히 프런트엔드 버튼으로 취급하지 마세요. 버튼을 숨기는 것은 보안이 아닙니다. 실제 확인은 서버 측에서 이루어집니다.

98## Passkey-우선 또는 passkey-우선?

100새 제품의 경우 passkey-먼저 생각해 보세요. 기존 앱의 경우 passkey 친화적을 선호합니다. 권장 방법으로 passkey을 추가하고 성공 여부와 문제를 측정한 다음 조용히 비밀번호 가중치를 줄입니다.

101

102이상적인 마이그레이션이 느껴지지 않습니다. 사용자는 회사가 인증 프로토콜을 변경한 것이 아니라 로그인이 더 쉽다는 것을 알게 됩니다.

103

104## 결론

105

106passkey는 드물게 보안과 UX를 동시에 향상시키기 때문에 흥미롭습니다. 이는 마술 지팡이가 아닙니다. 복구, 호환성, 지원 및 롤아웃은 여전히 잘 설계되어야 합니다.

107

108하지만 기본적인 변화는 강하다. 사용자에게 비밀을 만들고 보호하라고 요구하지 마세요. 장치가 도메인에 연결된 암호화 증명에 서명하도록 합니다. 인간의 기억력, 피싱 횟수, 비밀번호 재설정 횟수가 줄어듭니다. 나는 그것들이 진지하게 받아들일 가치가 있다고 말하고 싶습니다.

109

110## 소스

111

112- [MDN: Passkeys](https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/Passkeys)

113- [MDN: Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)

114- [W3C: Web Authentication](https://www.w3.org/TR/webauthn-3/)

115- [passkeys.dev](https://passkeys.dev/)

116