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

Firebase 프로젝트의 사용자

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

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

사용자 인스턴스는 Firebase 인증 인스턴스와 독립적이므로 동일한 컨텍스트 내에서 서로 다른 사용자에 대한 여러 참조를 보유하고 여전히 해당 메서드를 호출할 수 있습니다.

사용자 속성

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

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

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

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

로그인 공급자

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

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

현재 사용자

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

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

사용자 라이프사이클

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

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

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

사용자 셀프 서비스

기본적으로 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. 이메일은 신뢰할 수 있는 자격 증명 공급자 또는 간단히 IdP에 의해 확인됩니다.

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

신뢰할 수 있는 공급자:

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

신뢰할 수 없는 공급자:

  • 페이스북
  • 트위터
  • GitHub
  • 해당 ID 공급자가 발급하지 않은 도메인의 경우 Google, Yahoo 및 Microsoft
  • 이메일 확인 없는 이메일/비밀번호

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

다음 사례는 계정을 자동으로 연결하는 경우와 사용자 또는 개발자 작업이 필요한 오류를 발생시키는 경우를 설명합니다.

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

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