Firebase Summit에서 발표된 모든 내용을 살펴보고 Firebase로 앱을 빠르게 개발하고 안심하고 앱을 실행하는 방법을 알아보세요. 자세히 알아보기

Firebase 프로젝트의 사용자

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

Firebase 사용자 객체는 프로젝트의 앱에 가입한 사용자 계정을 나타냅니다. 앱에는 일반적으로 많은 등록 사용자가 있으며 프로젝트의 모든 앱은 사용자 데이터베이스를 공유합니다.

사용자 인스턴스는 Firebase 인증 인스턴스와 별개이므로 동일한 컨텍스트 내에서 여러 사용자에 대한 참조를 여러 개 가질 수 있으며 여전히 해당 메서드를 호출할 수 있습니다.

사용자 속성

Firebase 사용자는 고유 ID, 기본 이메일 주소, 이름 및 사진 URL과 같은 고정된 기본 속성 집합이 프로젝트의 사용자 데이터베이스에 저장되며 사용자가 업데이트할 수 있습니다( iOS , Android , web ). 사용자 개체에 다른 속성을 직접 추가할 수 없습니다. 대신 Google Cloud Firestore와 같은 다른 스토리지 서비스에 추가 속성을 저장할 수 있습니다.

사용자가 앱에 처음 가입할 때 사용 가능한 정보를 사용하여 사용자의 프로필 데이터가 채워집니다.

  • 사용자가 이메일 주소와 비밀번호로 가입한 경우 기본 이메일 주소 속성만 채워집니다.
  • 사용자가 Google 또는 Facebook과 같은 연합 ID 공급자에 가입한 경우 공급자가 제공한 계정 정보를 사용하여 사용자 프로필을 채웁니다.
  • 사용자가 사용자 정의 인증 시스템으로 등록한 경우 원하는 정보를 사용자 프로필에 명시적으로 추가해야 합니다.

사용자 계정이 생성되면 사용자 정보를 다시 로드하여 사용자가 다른 장치에서 변경했을 수 있는 모든 변경 사항을 통합할 수 있습니다.

로그인 제공업체

이메일 주소 및 비밀번호, 연합 ID 공급자, 사용자 지정 인증 시스템 등 여러 방법을 사용하여 사용자를 앱에 로그인할 수 있습니다. 하나 이상의 로그인 방법을 사용자와 연결할 수 있습니다. 예를 들어 사용자는 이메일 주소와 비밀번호를 사용하거나 Google 로그인을 사용하여 동일한 계정에 로그인할 수 있습니다.

사용자 인스턴스는 사용자에게 연결된 모든 공급자를 추적합니다. 이를 통해 공급자가 제공한 정보를 사용하여 빈 프로필의 속성을 업데이트할 수 있습니다. 사용자 관리( iOS , Android , )를 참조하십시오.

현재 사용자

사용자가 가입하거나 로그인하면 해당 사용자는 Auth 인스턴스의 현재 사용자가 됩니다. 인스턴스는 사용자의 상태를 유지하므로 페이지를 새로 고치거나(브라우저에서) 애플리케이션을 다시 시작해도 사용자 정보가 손실되지 않습니다.

사용자가 로그아웃하면 Auth 인스턴스가 사용자 개체에 대한 참조 유지를 중지하고 해당 상태를 더 이상 유지하지 않습니다. 현재 사용자가 없습니다. 그러나 사용자 인스턴스는 계속해서 완벽하게 작동합니다. 참조를 유지하면 사용자 데이터에 계속 액세스하고 업데이트할 수 있습니다.

사용자 수명 주기

Auth 인스턴스의 현재 상태를 추적하는 권장 방법은 리스너(JavaScript에서는 "관찰자"라고도 함)를 사용하는 것입니다. Auth 리스너는 Auth 객체와 관련된 일이 발생할 때마다 알림을 받습니다. 사용자 관리( iOS , Android , )를 참조하십시오.

인증 수신기는 다음 상황에서 알림을 받습니다.

  • Auth 개체가 초기화를 완료하고 사용자가 이미 이전 세션에서 로그인했거나 ID 공급자의 로그인 흐름에서 리디렉션되었습니다.
  • 사용자가 로그인합니다(현재 사용자가 설정됨)
  • 사용자가 로그아웃(현재 사용자가 null이 됨)
  • 현재 사용자의 액세스 토큰이 새로 고쳐집니다. 이 경우는 다음 조건에서 발생할 수 있습니다.
    • 액세스 토큰이 만료됨: 이것은 일반적인 상황입니다. 새로 고침 토큰은 유효한 새 토큰 세트를 가져오는 데 사용됩니다.
    • 사용자가 비밀번호를 변경함: Firebase에서 새 액세스 및 새로 고침 토큰을 발급하고 이전 토큰이 만료되도록 렌더링합니다. 이렇게 하면 보안상의 이유로 사용자의 토큰이 자동으로 만료되거나 모든 장치에서 사용자가 로그아웃됩니다.
    • 사용자가 재인증합니다. 일부 작업에서는 사용자의 자격 증명이 최근에 발급되어야 합니다. 이러한 작업에는 계정 삭제, 기본 이메일 주소 설정 및 암호 변경이 포함됩니다. 사용자를 로그아웃한 다음 사용자를 다시 로그인하는 대신 사용자로부터 새 자격 증명을 얻고 새 자격 증명을 사용자 개체의 reauthenticate 메서드에 전달합니다.

사용자 셀프 서비스

기본적으로 Firebase를 사용하면 사용자가 관리 개입 없이 계정에 가입하고 삭제할 수 있습니다. 많은 상황에서 이를 통해 최종 사용자는 최소한의 마찰로 애플리케이션 또는 서비스를 발견하고 온보드(또는 오프보드)할 수 있습니다.

그러나 관리자가 Admin SDK 또는 Firebase 콘솔을 사용하여 수동으로 또는 프로그래밍 방식으로 사용자를 생성해야 하는 상황이 있습니다. 이러한 경우 Firebase 인증 설정 페이지에서 사용자 작업을 비활성화하여 최종 사용자의 계정 생성 및 삭제를 방지할 수 있습니다. 멀티 테넌시를 사용하는 경우 테넌트별로 이러한 기능 을 비활성화하려면 HTTP 요청을 해야 합니다.

최종 사용자가 시스템 내에서 계정을 만들거나 삭제하려고 하면 Firebase 서비스에서 오류 코드를 반환합니다. Web API 호출의 경우 auth/admin-restricted-operation , Android 및 iOS의 경우 ERROR_ADMIN_RESTRICTED_OPERATION 입니다. 사용자에게 서비스에 대한 적절한 조치를 취하도록 요청하여 프런트 엔드에서 오류를 정상적으로 처리해야 합니다.

인증 토큰

Firebase로 인증을 수행할 때 세 가지 유형의 인증 토큰이 발생할 수 있습니다.

Firebase ID 토큰 사용자가 앱에 로그인할 때 Firebase에서 생성합니다. 이러한 토큰은 Firebase 프로젝트에서 사용자를 안전하게 식별하는 서명된 JWT입니다. 이러한 토큰에는 Firebase 프로젝트에 고유한 사용자 ID 문자열을 비롯한 사용자의 기본 프로필 정보가 포함되어 있습니다. ID 토큰의 무결성을 확인할 수 있으므로 백엔드 서버로 보내 현재 로그인한 사용자를 식별할 수 있습니다.
ID 제공자 토큰 Google 및 Facebook과 같은 연합 ID 제공업체에서 생성합니다. 이러한 토큰은 다른 형식을 가질 수 있지만 종종 OAuth 2.0 액세스 토큰입니다. 앱은 이러한 토큰을 사용하여 사용자가 ID 공급업체에 성공적으로 인증되었는지 확인한 다음 Firebase 서비스에서 사용할 수 있는 자격 증명으로 변환합니다.
Firebase 맞춤 토큰 사용자가 인증 시스템을 사용하여 앱에 로그인할 수 있도록 사용자 지정 인증 시스템에서 생성합니다. 맞춤 토큰은 서비스 계정의 비공개 키를 사용하여 서명된 JWT입니다. 앱은 연합 ID 제공자에서 반환된 토큰을 사용하는 것처럼 이러한 토큰을 사용합니다.

확인된 이메일 주소

Firebase는 이메일이 두 가지 조건을 충족하는 경우 확인된 이메일로 간주합니다. 1. 사용자가 Firebase 확인 절차를 완료합니다. 2. 신뢰할 수 있는 ID 제공업체(줄여서 IdP)가 이메일을 확인합니다.

이메일을 한 번 확인했지만 사용자가 다시 확인하지 않고도 이메일 주소를 변경할 수 있도록 하는 IdP는 신뢰할 수 없습니다. 도메인을 소유하거나 항상 확인이 필요한 IdP는 신뢰할 수 있는 것으로 간주됩니다.

신뢰할 수 있는 제공업체:

  • Google(@gmail.com 주소용)
  • 야후(@yahoo.com 주소용)
  • Microsoft(@outlook.com 및 @hotmail.com 주소용)
  • Apple(계정이 항상 확인되고 다단계 인증되기 때문에 항상 확인됨)

신뢰할 수 없는 공급자:

  • 페이스북
  • 트위터
  • 깃허브
  • 해당 ID 제공업체에서 발급하지 않은 도메인의 경우 Google, Yahoo 및 Microsoft
  • 이메일/비밀번호 확인 없이

경우에 따라 Firebase는 사용자가 동일한 이메일 주소를 사용하여 다른 제공업체에 로그인할 때 계정을 자동으로 연결합니다. 그러나 이것은 특정 기준이 충족되는 경우에만 발생할 수 있습니다. 그 이유를 이해하려면 사용자가 @gmail.com 계정으로 Google을 사용하여 로그인하고 악의적인 행위자가 동일한 @gmail.com 주소를 사용하여 계정을 생성하지만 Facebook을 통해 로그인하는 상황을 고려하십시오. 이 두 계정이 자동으로 연결되면 악의적인 행위자가 사용자 계정에 액세스할 수 있습니다.

다음 사례는 계정을 자동으로 연결하는 경우와 사용자 또는 개발자의 조치가 필요한 오류가 발생하는 경우를 설명합니다.

  • 사용자가 신뢰할 수 없는 제공업체에 로그인한 다음 동일한 이메일로 다른 신뢰할 수 없는 제공업체에 로그인합니다(예: Facebook 다음에 GitHub). 계정 연결이 필요한 오류가 발생합니다.
  • 사용자는 신뢰할 수 있는 제공업체에 로그인한 다음 동일한 이메일로 신뢰할 수 없는 제공업체에 로그인합니다(예: Google 다음에 Facebook). 계정 연결이 필요한 오류가 발생합니다.
  • 사용자가 신뢰할 수 없는 제공업체에 로그인한 다음 동일한 이메일로 신뢰할 수 있는 제공업체에 로그인합니다(예: Facebook 다음에 Google). 신뢰할 수 있는 공급자가 신뢰할 수 없는 공급자를 덮어씁니다. 사용자가 Facebook으로 다시 로그인을 시도하면 계정 연결이 필요한 오류가 발생합니다.
  • 사용자는 신뢰할 수 있는 제공업체에 로그인한 다음 동일한 이메일로 다른 신뢰할 수 있는 제공업체에 로그인합니다(예: Apple 다음에 Google). 두 공급자 모두 오류 없이 연결됩니다.

Admin SDK를 사용하여 이메일을 확인된 것으로 수동으로 설정할 수 있지만 사용자가 이메일을 실제로 소유하고 있다는 것을 알고 있는 경우에만 이 작업을 수행하는 것이 좋습니다.