Skip to content

로그인·문자 인증·비밀번호 재설정 ​

제품 개발 기록으로 · 가입·초대·워크스페이스 · 내 정보 · 운영자 콘솔 인증

공용 폼·스토어·인증 API를 대조한 사용 설명입니다. 문자·이메일 발송이나 비밀번호 변경은 실행 검증하지 않았습니다.

진입과 구분 ​

각 업무 앱의 /signin에서 로그인합니다. 인증이 필요한 화면에 비로그인 상태로 진입하면 라우터가 로그인 화면으로 보냅니다. 관리자 앱은 통합 Account 로그인과 워크스페이스 선택을 사용하고, 다른 앱의 공용 폼은 조직의 직원 로그인 경로를 사용합니다. 운영자 콘솔은 별도 system-admin 절차를 따릅니다.

공용 폼은 사번·이메일·전화번호 식별자를 받습니다. 현재 방식 조회는 조직 코드 없이 호출해 모든 조직에서 사용하는 방식의 합집합을 표시합니다. 실제 인증 요청에서는 해당 직원 조직과 직원에게 허용된 방식을 다시 확인하므로, 탭이 보인다는 사실만으로 해당 직원이 사용할 수 있다고 판단하지 않습니다. 방식 조회 실패 시 비밀번호 방식으로 남을 수 있습니다.

제공 조작 ​

조작입력·조건결과
비밀번호 로그인식별자와 현재 비밀번호 필수세션 취득, 강제 변경 또는 업무 화면/워크스페이스 선택
비밀번호 표시비밀번호 칸의 보기 버튼입력 표시 방식만 변경
로그인 방식 전환조회 결과에 표시된 비밀번호/문자 인증 탭방식 전환, 화면 오류 초기화; 실제 허용 여부는 요청 시 검사
문자 인증번호 요청·재요청등록 식별자, 조직·직원 OTP 허용등록 번호로 요청, 화면 재요청 대기 60초
인증번호 로그인식별자와 숫자 6자리코드 검증 후 세션 취득
비밀번호 찾기기능이 활성화된 조직, 등록 식별자임시 비밀번호 전달 요청
강제 비밀번호 변경로그인 후 변경 요구 상태새 비밀번호 검증·저장 후 업무 진입
가입·초대앱별 제공 링크조직과 계정의 별도 절차
로그아웃헤더 또는 직원 앱 메뉴현재 인증 상태 종료

비밀번호로 로그인하기 ​

  1. 사용하려는 조직의 앱 주소를 열고 로그인 화면을 확인합니다. 잘못된 조직·운영 환경 주소인지 먼저 구분합니다.
  2. 사번·이메일·전화번호 중 등록된 식별자와 비밀번호를 입력합니다. 식별자의 앞뒤 공백은 제출 시 제거하지만 비밀번호는 입력값을 유지합니다. 비밀번호 보기 버튼은 저장이나 변경을 하지 않습니다.
  3. 로그인 버튼 또는 폼 제출을 실행합니다. 빈 식별자/비밀번호는 오류로 남고 전송하지 않습니다. 요청 중에는 처리 상태를 확인합니다.
  4. 성공하면 권한과 소속에 따라 업무 화면 또는 워크스페이스 허브로 이동합니다. 강제 변경 플래그가 있으면 /change-password로 먼저 이동합니다. 계정 로그인 성공과 특정 조직 업무 권한 취득은 별도 단계입니다.
  5. 오류 시 식별자·비밀번호·서버 연결 안내를 확인합니다. 네트워크 요청 실패는 연결 오류로 안내합니다. 반복 새로고침을 로그인 복구 절차로 삼지 않습니다.

문자 인증으로 로그인하기 ​

  1. 로그인 화면에서 문자 인증 방식을 선택합니다. 조직과 해당 직원 모두 이 방식이 허용돼 있어야 합니다.
  2. 등록 식별자를 입력하고 인증번호 요청 버튼을 누릅니다. 성공 응답 후 화면에서 번호 입력이 가능해지고 재요청 대기 시간이 시작됩니다.
  3. 실제 휴대폰에 도착한 최근 인증번호 숫자 6자리를 입력하고 로그인합니다. 영문·자리수 오류는 폼에서 거절합니다. 번호 요청의 성공 응답은 식별자 존재나 실제 문자 배달을 확정해 주지 않습니다.
  4. 만료·오입력 시 안내를 확인하고 대기 시간이 끝난 뒤 다시 요청합니다. 서버는 최근 미사용·미만료 코드를 검사하고 5회 오입력하면 해당 코드를 소모 처리합니다. 사용된 코드는 재사용할 수 없습니다.
  5. 문자 로그인이 성공해도 강제 비밀번호 변경 상태가 있으면 변경 화면으로 연결될 수 있습니다. 문자 인증이 조직 보안 설정이나 비밀번호 변경 의무를 우회하지 않습니다.

임시 비밀번호를 요청하고 변경하기 ​

  1. 로그인 화면의 비밀번호 찾기를 엽니다. 현재 노출 API는 어느 조직이든 자체 재설정을 허용하면 전체 공용 로그인 화면에 링크를 제공합니다. 링크 표시가 본인 조직의 허용을 뜻하지 않으며 실제 요청에서는 대상 직원 조직 설정을 확인합니다. 링크가 없거나 수신하지 못하면 관리자에게 계정 상태를 확인합니다.
  2. 등록 식별자를 입력해 제출합니다. 이메일 형식 식별자는 이메일 우선, 다른 식별자는 문자 우선으로 전달을 시도하고 가능한 대체 연락 수단으로 재시도합니다. 과거 폼 주석의 '항상 SMS' 설명과 현재 서버는 다릅니다.
  3. 화면의 요청 처리 완료는 실제 수신 성공 증거가 아닙니다. 서버는 미등록 식별자·비활성 설정·연락 수단 실패에도 동일한 일반 응답을 사용합니다. 실제 등록 연락처에서 수신 여부를 확인합니다.
  4. 전달에 성공한 경우 서버는 연결된 Account의 비밀번호를 갱신하고 Employee에 강제 변경 상태를 표시합니다. 모든 전달 시도가 실패하면 현재 비밀번호를 바꾸지 않습니다.
  5. 로그인 화면으로 돌아가 임시 비밀번호로 로그인합니다. 이어지는 변경 화면에서 새 비밀번호와 확인값을 입력합니다. 공용 폼은 병원 설정의 일반 비밀번호 규칙(기본 8자 이상·대문자·소문자·숫자·특수문자, 병원이 최소 길이 4~20과 필수 문자를 조정)을 안내하고 같은 규칙으로 검사하며, 두 입력의 일치도 확인합니다. 서버도 같은 규칙으로 다시 검증합니다.
  6. 저장 성공 안내 후 업무 화면으로 이동합니다. 실패하면 안내된 필드를 수정하고 재시도합니다. 일반적인 본인 정보에서의 비밀번호 변경은 내 정보의 현재 비밀번호 입력 절차를 따릅니다.

세션·다중 소속·재진입 ​

액세스 토큰 갱신과 최초 사용자 정보 로딩은 공용 스토어·SDK가 담당합니다. 최초 로딩 전에 업무 조회를 실행하면 인증 전 빈 화면이나 권한 오류로 굳을 수 있으므로 각 앱은 인증 완료 이후 데이터를 읽어야 합니다. 새로고침을 연속해서 실행할 때의 갱신 경쟁은 인증 변경 기록에서 다룹니다.

로그아웃 후 재진입에는 다시 인증이 필요합니다. 역할 변경·소속 선택·계정 잠금은 조직과 권한과 연결됩니다. 직접 링크·임베드·모바일 푸시를 통한 복귀는 앱별 라우터가 달라, 로그인 성공만으로 원래 상세 화면이 복원됐다고 판단하지 않습니다.

근거와 검증 경계 ​

공용 로그인과 관리자 계정 흐름을 구분하고, 일반 성공 응답과 실제 문자/이메일 배달을 분리했습니다. 필요한 새 증거는 각 허용 방식의 로그인 전후, OTP 오류·대기, 임시 비밀번호 수신, 강제 변경 후 재로그인입니다. 계정·문자/메일 발송 환경이 확보된 검증에서 수행하며 이번에는 실행하지 않았습니다.

직원 로그인 기능 영상 ​

Codex가 비밀번호 로그인을 실제 ID·비밀번호 입력 → 로그인 제출 → 직원 앱 진입 → 더보기·내 정보에서 사번 확인까지 촬영했습니다. 비밀번호는 표시하지 않았습니다. 390×844 웹 화면이며 네이티브 설치·PWA 설치·강제 변경 계정 분기는 별도 촬영 대상입니다.

휴대폰 인증은 조직의 settings.loginMethods에 phone_otp가 포함된 격리 예제 환경에서 탭 선택·식별자 입력·인증번호 요청 버튼 활성화까지만 촬영했습니다. 실제 SMS 발송·수신·6자리 검증을 실행하지 않았습니다. 처음에는 비밀번호 전용이라 두 방식 탭 자체가 숨겨져 있었고, 이 차이에 맞춰 사용자 가이드의 ‘항상 두 탭이 표시됨’ 설명을 고쳤습니다. availableLoginMethods는 조직 코드 없는 조회에서 전체 조직 방식의 합집합을 반환하고 LoginForm.ts는 둘 이상일 때 탭을 표시합니다. 탭 표시와 본인 조직·직원의 OTP 허용은 같은 검사가 아닙니다.

설치 직원 앱의 시작 전 버전 확인 ​

직원 첫 로그인 가이드에 웹과 설치 앱, 필수 업데이트와 재확인 절차를 구분했습니다. PR #698·#721·#785·#796의 시작 흐름에서 설치 앱의 최소 빌드 확인과 화면 묶음 선택은 로그인과 별도입니다. 웹은 설치 앱 버전 검사에서 제외됩니다. iOS 의존성 변경을 사용자 조작 변경으로 따로 안내하지 않습니다.

apps/employee-app/src/stores/app-version-policy-store.ts, native-bundle-resolver.ts, views/update-required.html과 운영 앱 시작 규약을 대조했습니다. 실제 iOS/Android의 강제 업데이트·다운로드·재시작은 이번 주간 작업에서 검증·촬영하지 않았습니다. 서버 정책 게시만으로 앱 실기기 검증 완료를 표시하지 않습니다.

로그인 ID의 영문 대소문자 ​

로그인 ID는 영문 대소문자를 구분하지 않고, 비밀번호는 입력한 대소문자를 그대로 검증합니다. 직원 앱 첫 로그인에 구분을 적었습니다. 근거는 PR #647의 auth-session.service.ts와 auth.router.ts입니다. 대소문자만 다른 ID 입력과 잘못된 비밀번호 거부의 실제 로그인 대조는 미완료입니다.

직원 앱 시작 안내에 가입 링크 확인, 다시 검색하기, 로그인 화면의 조직 변경을 연결했습니다. 연결하기와 다시 검색하기 모두 현재 실행에 사용한 가입 링크를 처리한 것으로 표시합니다. 다시 검색하기는 입력 코드도 비웁니다. 화면을 다시 불러와도 같은 실행 주소의 코드를 복원하지 않으며, 사용자가 링크를 새로 누르면 새 진입으로 처리합니다.

PR #1047의 app-link.ts와 backend-discovery.ts를 대조했습니다. 실제 설치 앱의 가입 링크 검증에는 해당 배포 환경에 등록된 예제 회사 코드가 필요합니다. 브라우저에서 코드를 미리 넣거나 가짜 연결 응답을 주입한 장면을 설치 앱 촬영으로 소개하지 않습니다.

인증·보안 설정에서 관리하기 ​

항목안내
사용자본인 계정을 관리하는 직원·관리자
시작 위치웹 앱 프로필 메뉴의 인증/보안 설정, 직원 앱 더보기 > 인증/보안 설정
관련 화면로그인, 내 정보, 메신저 대화 잠금, 조직의 보안 정책
  1. 계정과 연결된 휴대폰 정보를 확인합니다. 휴대폰 인증 로그인 스위치는 바꾸면 저장됩니다. 계정 연결 정보 자체를 이 화면에서 자유롭게 바꾸는 기능은 아닙니다.
  2. 비밀번호 변경에서 현재 비밀번호 확인 후 새 비밀번호와 확인값을 입력합니다. 확인 전 취소하면 비밀번호를 바꾸지 않습니다. 오류가 나면 안내를 읽고 해당 입력을 수정합니다.
  3. 2단계 인증의 등록에서 인증 앱으로 QR을 읽고 6자리 번호로 확인합니다. 완료 전 취소하면 등록을 마치지 않습니다. 복구용 코드는 개인이 보관하며 문서·영상에 노출하지 않습니다. 끄기에도 본인 확인이 필요하며 조직에서 필수로 정하면 해제할 수 없습니다.
  4. 웹에서는 패스키, 지원되는 설치 앱에서는 기기 키를 등록하고 목록에서 개별 해제합니다. 기기 인증 창을 취소하면 등록되지 않습니다. 목록을 다시 확인해 등록·해제 결과를 확인합니다. 설치 앱에 필요한 기능이 없으면 업데이트 후 사용합니다.
  5. 키가 등록된 계정은 키로만 로그인하는 설정을 사용할 수 있습니다. 켜면 비밀번호와 문자 로그인은 사용할 수 없으므로 등록된 기기를 사용할 수 있는지 먼저 확인합니다. 접근하지 못하면 관리자에게 복구를 요청합니다.
  6. 로그인한 기기에서 개별 기기 또는 현재 기기를 제외한 나머지 기기의 로그아웃을 선택합니다. 확인창의 취소는 세션을 유지합니다. 확정한 기기에서는 다시 로그인해야 합니다.
  7. 대화 잠금은 메시지 열람용 키의 설정입니다. 계정 로그인용 패스키·2단계 인증과 별개이며 메신저를 따릅니다.

로그인 실패가 반복되면 잠시 시도가 제한됩니다. 비밀번호 재설정만으로 제한이 해제되는 것은 아닙니다. 추가 인증이나 보안 확인이 나타나면 화면 안내를 따릅니다. 로그아웃 직후에는 기기 인증이 자동으로 다시 시작되지 않지만 로그인 버튼으로 직접 인증할 수 있습니다.

구현 근거는 packages/components/src/components/SecuritySettings.ts, packages/components/html/security-settings.html, apps/employee-app/src/views/modals/security.html와 PR #1223·#1227·#1229·#1230·#1231·#1235·#1239입니다. 실제 촬영은 계정 확인·비밀번호 변경 열기/취소·기기 목록·다른 기기 로그아웃 취소까지입니다. 2단계 인증 활성화·실제 기기 키·로그인 제한 해제·외부 문자는 촬영 완료로 취급하지 않습니다.