Firebase 사용자 객체는 앱에서 살펴보겠습니다 앱에는 일반적으로 등록된 사용자가 많으며 한 프로젝트 내의 모든 앱이 사용자 데이터베이스 하나를 공유합니다.
사용자 인스턴스는 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 콘솔. 이 경우 사용자 작업을 사용 중지할 수 있습니다. Firebase Authentication 설정에서 페이지가 표시되어 최종 사용자의 계정 생성 및 삭제를 방지합니다. 멀티테넌시를 사용하는 경우 HTTP 요청을 해야 합니다. 사용 중지 이러한 기능을 테넌트 단위로 지정할 수 있습니다
최종 사용자가 시스템 내에서 계정을 만들거나 삭제하려고 하면
Firebase 서비스는 다음과 같은 오류 코드를 반환합니다.
웹 API 호출의 경우 auth/admin-restricted-operation 또는 Android 및 iOS의 경우 ERROR_ADMIN_RESTRICTED_OPERATION입니다. 사용자에게 서비스의 적절한 작업을 요청하여 프런트엔드의 오류를 적절하게 처리해야 합니다.
인증 토큰
Firebase로 인증을 수행하면 다음과 같은 인증 토큰의 종류가 있습니다.
| ID 토큰 Firebase개 | 사용자가 앱에 로그인할 때 Firebase에 의해 생성됩니다. 이러한 토큰은 서명된 JWT로 Firebase 프로젝트. 이 토큰에는 공개 IP 주소가 있는 사용자의 ID 문자열을 포함하며, Firebase 프로젝트. 왜냐하면 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를 사용하여 이메일을 인증된 것으로 직접 설정할 수 있지만 사용자가 해당 이메일을 실제로 소유하고 있음을 알고 있는 경우에만 이를 설정하는 것이 좋습니다.