데스크톱 네이티브 로그인

호텔 프런트에 서 있다고 상상해 보세요. 직원이 신분증을 요구합니다. 복사본을 건넬 수도 있지만, 뭔가 불안하죠. 대신 실제 신분증을 보여주면 직원은 잠깐 훑어보고, 다시 주머니에 넣으면 됩니다. 네이티브 사인인이 앱에서 해주는 일이 바로 이것입니다. 열쇠를 넘겨주지 않고도 자신이 누구인지 증명할 수 있게 해주는 거죠.

Hermes Desktop 앱을 로그인 시스템(예: Google, GitHub)으로 보호되는 대시보드에 연결할 때, 앱은 사용자를 확인해야 합니다. 이를 위한 두 가지 방법이 있는데, 좋은 소식은 둘 중 하나를 선택할 필요가 없다는 것입니다. 앱이 자동으로 최적의 방법을 선택합니다.

기존 방식: 임베디드 사인인 (레거시)

과거에는 앱이 자체적으로 내부에 작은 브라우저 창을 열었습니다. 사용자 이름과 비밀번호를 다시 입력하고, 2단계 인증을 다시 수행하고, 비밀번호 관리자가 작동하기를 바라야 했죠. 하지만 안타깝게도 잘 작동하지 않는 경우가 많았습니다.

이 방식은 또한 미니 브라우저에서 “세션 쿠키”를 가져오는 데 의존했습니다. 마치 만료되거나 분실될 수 있는 임시 신분증과 같았죠.

새로운 방식: 네이티브 사인인 (RFC 8252)

네이티브 사인인은 현대적이고 안전한 접근 방식입니다. 간단히 설명하면 다음과 같습니다.

• 앱이 사용자의 실제 브라우저(Safari, Chrome, Firefox, Edge 등)를 엽니다.
• 거기서 로그인하면 저장된 비밀번호, 확장 프로그램, 패스키가 모두 정상적으로 작동합니다.
• 앱은 자신만의 특별한 토큰을 받습니다. 마치 자신의 방에서만 작동하는 키카드와 같죠.

임베디드 브라우저도, 세션 쿠키도 없습니다. 깔끔하고 안전한 핸드셰이크만 있을 뿐입니다.

실제 작동 방식

내부적으로 진행되는 흐름을 간단히 정리하면 다음과 같습니다.

1. 데스크톱 앱이 컴퓨터에 비공개 "수신" 지점(루프백 주소)을 엽니다.
2. 시스템 브라우저가 로그인 페이지를 엽니다.
3. 사용자가 승인하면 앱으로 다시 리디렉션됩니다.
4. 앱이 비밀 코드를 토큰으로 교환합니다.
5. 토큰은 OS 키체인에 안전하게 저장됩니다.
6. 이후 모든 요청은 해당 토큰을 사용합니다. 쿠키는 사용되지 않습니다.

게이트웨이(대시보드 서버)는 중개자 역할을 합니다. 사용자를 대신해 ID 공급자(예: Nous Portal)와 통신하지만, 로그인 경험 자체는 사용자만의 비공개 환경에서 이루어집니다.

이것이 왜 중요한가

• 비밀번호 재입력 불필요 — 브라우저가 이미 사용자를 알고 있습니다.
• 패스키 및 비밀번호 관리자 작동 — 더 이상 작은 임베디드 창과 씨름할 필요가 없습니다.
• 향상된 보안 — 앱은 수명이 짧은 토큰을 사용하므로, 유출되어도 빠르게 만료됩니다.
• OS 키체인이 모든 것을 보호 — 토큰은 저장 시 암호화됩니다.

게이트웨이가 오래된 경우는?

대시보드가 네이티브 사인인을 지원하지 않는 경우(이전 빌드), 앱은 자동으로 임베디드 브라우저 방식으로 대체됩니다. 사용자가 직접 할 일은 없습니다. 앱이 먼저 게이트웨이의 기능을 확인하기 때문입니다.

결론

네이티브 사인인은 복사본 대신 실제 신분증을 보여주는 것과 같습니다. 더 안전하고, 더 매끄럽고, 이미 사용 중인 도구를 존중합니다. 앱이 모든 기술적 결정을 처리하므로, 사용자는 로그인하고 다시 작업으로 돌아가기만 하면 됩니다.

실용적인 팁: Hermes Desktop을 자체 호스팅 게이트웨이와 함께 설정하는 경우, 최신 버전을 실행 중인지 확인하세요. 그러면 기본적으로 네이티브 사인인이 적용되어 임베디드 브라우저를 완전히 건너뛸 수 있습니다.

---