Firebase user 객체는 프로젝트의 앱에 가입한 사용자 계정을 나타냅니다. 앱에는 일반적으로 등록된 사용자가 많으며 한 프로젝트 내의 모든 앱이 사용자 데이터베이스 하나를 공유합니다.
사용자 인스턴스는 Firebase Authentication 인스턴스와 별개이므로 같은 컨텍스트 내에 여러 사용자에 대한 참조가 여러 개 있을 수 있으며 이러한 사용자의 메서드를 어떤 것이나 호출할 수 있습니다.
사용자 속성
Firebase 사용자는 프로젝트의 사용자 데이터베이스에 고유 ID, 기본 이메일 주소, 이름, 사진 URL과 같은 고정된 기본 속성 집합을 저장하며 사용자가 이러한 속성을 업데이트(iOS, Android, 웹)할 수 있습니다. user 객체에 직접 다른 속성을 추가할 수는 없으며 대신 추가 속성을 Google Cloud Firestore와 같은 다른 스토리지 서비스에 저장할 수 있습니다.
사용자가 앱에 처음 가입할 때 사용자의 프로필 데이터에 정보를 채웁니다.
- 사용자가 이메일 주소와 비밀번호로 가입했다면 기본 이메일 주소 속성만 채웁니다.
- 사용자가 Google 또는 Facebook 등의 제휴 ID 공급업체를 사용해 가입했다면 업체에서 제공하는 계정 정보를 가져와 사용자의 프로필을 채웁니다.
- 사용자가 맞춤 인증 시스템으로 가입했다면 원하는 정보를 사용자의 프로필에 명시적으로 추가해야 합니다.
사용자 계정이 생성되면 사용자의 정보를 다시 불러와서 사용자가 다른 기기에서 변경한 내역을 반영할 수 있습니다.
로그인 제공업체
앱에 사용자를 로그인 처리하는 데는 이메일 주소 및 비밀번호, 제휴 ID 공급업체, 맞춤 인증 시스템 등의 방법이 있습니다. 한 명의 사용자에게 2가지 이상의 로그인 방법을 연결할 수 있습니다. 예를 들면 한 명의 사용자가 이메일 주소, 비밀번호, Google 로그인을 사용해서 같은 계정에 로그인할 수 있습니다.
사용자 인스턴스는 해당 사용자에게 연결된 모든 공급업체를 추적합니다. 따라서 공급업체가 전달하는 정보를 이용해 프로필의 빈 속성을 업데이트할 수 있습니다. 사용자 관리(iOS, Android, 웹)를 참조하세요.
현재 사용자
가입하거나 로그인한 사용자는 Auth 인스턴스의 현재 사용자가 됩니다. 이 인스턴스는 사용자의 상태를 유지하여 브라우저에서 페이지를 새로고침하거나 애플리케이션을 재시작해도 사용자의 정보가 사라지지 않게 합니다.
사용자가 로그아웃하면 인증 인스턴스가 user 객체에 대한 참조 유지를 중단하고 사용자 상태를 유지하지 않습니다. 즉, 현재 사용자가 없는 것입니다. 그러나 사용자 인스턴스는 계속 온전히 작동합니다. 이 인스턴스에 대한 참조를 유지하면 사용자의 데이터에 계속 액세스하고 업데이트할 수 있습니다.
사용자 처리 과정
인증 인스턴스의 현재 상태를 추적할 때 권장하는 방법은 리스너(자바스크립트에서는 '관찰자'라고 함)를 사용하는 것입니다. Auth 리스너는 Auth 객체에 유의미한 사건이 발생할 때마다 알림을 받습니다. 사용자 관리(iOS, Android, 웹)를 참조하세요.
다음과 같은 경우에 Auth 리스너가 알림을 받습니다.
- 인증 객체가 초기화를 완료하고 사용자가 이미 이전 세션을 통해 로그인해 있거나 ID 공급업체의 로그인 흐름에서 리디렉션되었을 때
- 사용자가 로그인할 때(현재 사용자가 설정될 때)
- 사용자가 로그아웃할 때(현재 사용자가 null이 될 때)
- 현재 사용자의 액세스 토큰이 갱신될 때. 갱신이 일어나는 상황은 다음과 같습니다.
- 액세스 토큰이 만료되었을 때: 흔한 경우입니다. 갱신 토큰을 사용해 유효한 토큰 세트를 새로 가져옵니다.
- 사용자가 비밀번호를 변경할 때: Firebase가 새 액세스 및 갱신 토큰을 발급하고 기존 토큰을 만료시킵니다. 이때 보안상의 이유로 자동으로 사용자의 토큰이 만료되거나 사용자가 모든 기기에서 로그아웃됩니다.
- 사용자가 다시 인증할 때: 일부 작업은 사용자의 인증 정보가 최근에 발급된 경우에만 진행될 수 있습니다. 이런 작업으로는 계정 삭제, 기본 이메일 주소 설정, 비밀번호 변경 등이 있습니다. 사용자를 로그아웃 처리하고 다시 로그인 처리할 필요는 없고 사용자에게서 새로운 인증 정보를 받아서 user 객체의 reauthenticate 메서드에 전달하면 됩니다.
사용자 셀프서비스
기본적으로 Firebase를 사용하면 사용자가 관리 작업 없이 계정을 만들고 삭제할 수 있습니다. 이렇게 하면 최종 사용자가 애플리케이션 또는 서비스를 검색하고 최소한의 마찰로 온보딩(또는 오프보딩)할 수 있습니다.
하지만 Admin SDK 또는 Firebase Console을 사용하여 관리자를 통해 수동으로 또는 프로그래매틱 방식으로 사용자를 생성하려는 경우도 있습니다. 이러한 경우 Firebase Authentication 설정 페이지에서 사용자 작업을 사용 중지하여 최종 사용자의 계정 생성 및 삭제를 방지할 수 있습니다. 멀티테넌시를 사용하는 경우 테넌트별로 이러한 기능을 사용 중지하도록 HTTP 요청을 수행해야 합니다.
최종 사용자가 시스템 내에서 계정을 만들거나 삭제하려고 시도하면 Firebase 서비스가 오류 코드를 반환합니다(웹 API 호출의 경우 auth/admin-restricted-operation, Android 및 iOS의 경우 ERROR_ADMIN_RESTRICTED_OPERATION). 사용자에게 서비스의 적절한 작업을 요청하여 프런트엔드의 오류를 적절하게 처리해야 합니다.
인증 토큰
Firebase로 인증을 진행할 때 다루는 인증 토큰에는 3가지 유형이 있습니다.
| Firebase ID 토큰 | 사용자가 앱에 로그인할 때 Firebase가 만드는 토큰입니다. 이 토큰은 서명된 JWT로, Firebase 프로젝트에서 사용자의 신원을 안전하게 식별합니다. 이 토큰은 Firebase 프로젝트에 고유한 사용자의 ID 문자열을 비롯하여, 사용자의 기본 프로필 정보를 담고 있습니다. ID 토큰의 무결성을 확인할 수 있으므로 이 토큰을 백엔드 서버로 전송하여 현재 로그인한 사용자를 식별할 수 있습니다. |
| ID 공급업체 토큰 | Google과 Facebook 등의 제휴 ID 공급업체에서 생성하는 토큰입니다. 이러한 토큰의 형식은 다양하지만 주로 OAuth 2.0 액세스 토큰입니다. 앱은 이러한 토큰을 통해 ID 공급업체에서 사용자를 성공적으로 인증했음을 확인한 후 토큰을 Firebase 서비스에서 사용할 수 있는 사용자 인증 정보로 변환합니다. |
| Firebase 커스텀 토큰 | 사용자가 자체 인증 시스템을 통해 앱에 로그인할 수 있게 해 주는 맞춤 인증 시스템이 만드는 토큰입니다. 맞춤 토큰은 서비스 계정의 비공개 키를 사용해 서명한 JWT입니다. 앱은 제휴 ID 공급업체에서 반환한 토큰을 사용할 때와 유사한 방식으로 이 토큰을 사용합니다. |
인증된 이메일 주소
Firebase는 다음 두 가지 조건을 충족하는 경우 이메일이 인증된 것으로 간주합니다.
- 사용자가 Firebase 인증 과정을 완료합니다.
- 신뢰할 수 있는 ID 공급업체(줄여서 IdP)에 의해 이메일이 인증되었습니다.
이메일을 한 번 인증한 다음 사용자가 재인증하지 않고 이메일 주소를 변경할 수 있도록 허용하는 IdP는 신뢰할 수 없습니다. 도메인을 소유하거나 항상 인증이 필요한 IdP는 신뢰할 수 있는 것으로 간주됩니다.
신뢰할 수 있는 제공업체:
- Google(@gmail.com 주소의 경우)
- Yahoo(@yahoo.com 주소의 경우)
- Microsoft(@outlook.com 및 @hotmail.com 주소의 경우)
- Apple(계정이 항상 인증되며 다중 인증(MFA)을 사용하므로 항상 신뢰할 수 있음)
신뢰할 수 없는 제공업체:
- GitHub
- 해당 ID 공급업체에서 발급하지 않은 도메인에 대한 Google, Yahoo, Microsoft
- 이메일 인증이 없는 이메일/비밀번호
사용자가 동일한 이메일 주소를 사용하여 다른 제공업체로 로그인하면 Firebase에서 계정을 자동으로 연결하기도 합니다. 하지만 이 방법은 특정 기준이 충족되는 경우에만 가능합니다. 그 이유를 알아보려면 다음과 같은 경우를 생각해 보세요. 사용자가 @gmail.com 계정으로 Google을 사용하여 로그인하고 악의적인 행위자가 동일한 @gmail.com 주소를 사용하여 계정을 만들지만 Facebook을 통해 로그인합니다. 이 두 계정이 자동으로 연결되면 악의적인 행위자가 사용자 계정에 액세스할 수 있게 됩니다.
다음은 Google에서 자동으로 계정을 연결하는 경우와 사용자 또는 개발자 조치가 필요한 오류가 발생하는 경우를 설명합니다.
- 사용자가 신뢰할 수 없는 제공업체로 로그인한 후 동일한 이메일을 사용하여 신뢰할 수 없는 다른 제공업체로 로그인합니다(예: Facebook으로 로그인한 후 GitHub로 로그인). 이 경우 계정 연결을 요구하는 오류가 발생합니다.
- 사용자가 신뢰할 수 있는 제공업체로 로그인한 후 동일한 이메일을 사용하여 신뢰할 수 없는 제공업체로 로그인합니다(예: Google로 로그인한 후 Facebook으로 로그인). 이 경우 계정 연결을 요구하는 오류가 발생합니다.
- 사용자가 신뢰할 수 없는 공급업체로 로그인한 후 동일한 이메일을 사용하여 신뢰할 수 있는 공급업체로 로그인합니다(예: Facebook으로 로그인한 후 Google로 로그인). 신뢰할 수 있는 제공업체가 신뢰할 수 없는 제공업체를 덮어씁니다. 사용자가 Facebook으로 다시 로그인을 시도하는 경우 계정 연결을 요구하는 오류가 발생합니다.
- 사용자가 신뢰할 수 있는 제공업체로 로그인한 후 동일한 이메일을 사용하여 신뢰할 수 있는 다른 제공업체로 로그인합니다(예: Apple로 로그인한 후 Google로 로그인). 두 제공업체 모두 오류 없이 연결됩니다.
Admin SDK를 사용하여 이메일을 인증된 것으로 직접 설정할 수 있지만 사용자가 해당 이메일을 실제로 소유하고 있음을 알고 있는 경우에만 이를 설정하는 것이 좋습니다.