Google is committed to advancing racial equity for Black communities. See how.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Kontroluj dostęp za pomocą niestandardowych roszczeń i reguł bezpieczeństwa

Pakiet Firebase Admin SDK obsługuje definiowanie atrybutów niestandardowych na kontach użytkowników. Zapewnia to możliwość wdrażania różnych strategii kontroli dostępu, w tym kontroli dostępu opartej na rolach, w aplikacjach Firebase. Te atrybuty niestandardowe mogą zapewniać użytkownikom różne poziomy dostępu (role), które są wymuszane w regułach zabezpieczeń aplikacji.

Role użytkownika można zdefiniować dla następujących typowych przypadków:

  • Nadanie użytkownikowi uprawnień administracyjnych w zakresie dostępu do danych i zasobów.
  • Definiowanie różnych grup, do których należy użytkownik.
  • Zapewnienie wielopoziomowego dostępu:
    • Rozróżnienie płatnych / niezapłaconych subskrybentów.
    • Odróżnianie moderatorów od zwykłych użytkowników.
    • Podanie nauczyciela / ucznia itp.
  • Dodaj dodatkowy identyfikator użytkownika. Na przykład użytkownik Firebase może mapować do innego UID w innym systemie.

Rozważmy przypadek, w którym chcesz ograniczyć dostęp do węzła bazy danych „adminContent”. Możesz to zrobić, przeszukując bazę danych na liście administratorów. Możesz jednak osiągnąć ten sam cel wydajniej, używając niestandardowego oświadczenia użytkownika o nazwie admin z następującą regułą bazy danych czasu rzeczywistego:

{
  "rules": {
    "adminContent": {
      ".read": "auth.token.admin === true",
      ".write": "auth.token.admin === true",
    }
  }
}

Niestandardowe oświadczenia użytkownika są dostępne za pośrednictwem tokenów uwierzytelniania użytkownika. W powyższym przykładzie tylko użytkownicy z ustawieniem admin wartość true w ich żądaniu tokena mieliby dostęp do odczytu / zapisu do węzła adminContent . Ponieważ token ID zawiera już te potwierdzenia, nie jest potrzebne żadne dodatkowe przetwarzanie ani wyszukiwanie w celu sprawdzenia uprawnień administratora. Ponadto token identyfikatora jest zaufanym mechanizmem dostarczania tych oświadczeń niestandardowych. Każdy uwierzytelniony dostęp musi zweryfikować token ID przed przetworzeniem powiązanego żądania.

Przykłady kodu i rozwiązania opisane na tej stronie pochodzą zarówno z interfejsów API Firebase Auth po stronie klienta, jak i z interfejsów API uwierzytelniania po stronie serwera, które są dostępne w zestawie Admin SDK .

Ustawiaj i weryfikuj niestandardowe oświadczenia użytkowników za pomocą pakietu Admin SDK

Oświadczenia niestandardowe mogą zawierać poufne dane, dlatego należy je ustawiać tylko z uprzywilejowanego środowiska serwera za pomocą pakietu Firebase Admin SDK.

Node.js

// Set admin privilege on the user corresponding to uid.

admin
  .auth()
  .setCustomUserClaims(uid, { admin: true })
  .then(() => {
    // The new custom claims will propagate to the user's ID token the
    // next time a new one is issued.
  });

Jawa

// Set admin privilege on the user corresponding to uid.
Map<String, Object> claims = new HashMap<>();
claims.put("admin", true);
FirebaseAuth.getInstance().setCustomUserClaims(uid, claims);
// The new custom claims will propagate to the user's ID token the
// next time a new one is issued.

Pyton

# Set admin privilege on the user corresponding to uid.
auth.set_custom_user_claims(uid, {'admin': True})
# The new custom claims will propagate to the user's ID token the
# next time a new one is issued.

Iść

// Get an auth client from the firebase.App
client, err := app.Auth(ctx)
if err != nil {
	log.Fatalf("error getting Auth client: %v\n", err)
}

// Set admin privilege on the user corresponding to uid.
claims := map[string]interface{}{"admin": true}
err = client.SetCustomUserClaims(ctx, uid, claims)
if err != nil {
	log.Fatalf("error setting custom claims %v\n", err)
}
// The new custom claims will propagate to the user's ID token the
// next time a new one is issued.

DO#

// Set admin privileges on the user corresponding to uid.
var claims = new Dictionary<string, object>()
{
    { "admin", true },
};
await FirebaseAuth.DefaultInstance.SetCustomUserClaimsAsync(uid, claims);
// The new custom claims will propagate to the user's ID token the
// next time a new one is issued.

Obiekt oświadczeń niestandardowych nie powinien zawierać żadnych nazw kluczy zastrzeżonych OIDC ani nazw zastrzeżonych Firebase . Ładunek oświadczeń niestandardowych nie może przekraczać 1000 bajtów.

Token identyfikatora wysłany do serwera zaplecza może potwierdzić tożsamość użytkownika i poziom dostępu za pomocą pakietu Admin SDK w następujący sposób:

Node.js

// Verify the ID token first.
admin
  .auth()
  .verifyIdToken(idToken)
  .then((claims) => {
    if (claims.admin === true) {
      // Allow access to requested admin resource.
    }
  });

Jawa

// Verify the ID token first.
FirebaseToken decoded = FirebaseAuth.getInstance().verifyIdToken(idToken);
if (Boolean.TRUE.equals(decoded.getClaims().get("admin"))) {
  // Allow access to requested admin resource.
}

Pyton

# Verify the ID token first.
claims = auth.verify_id_token(id_token)
if claims['admin'] is True:
    # Allow access to requested admin resource.
    pass

Iść

// Verify the ID token first.
token, err := client.VerifyIDToken(ctx, idToken)
if err != nil {
	log.Fatal(err)
}

claims := token.Claims
if admin, ok := claims["admin"]; ok {
	if admin.(bool) {
		//Allow access to requested admin resource.
	}
}

DO#

// Verify the ID token first.
FirebaseToken decoded = await FirebaseAuth.DefaultInstance.VerifyIdTokenAsync(idToken);
object isAdmin;
if (decoded.Claims.TryGetValue("admin", out isAdmin))
{
    if ((bool)isAdmin)
    {
        // Allow access to requested admin resource.
    }
}

Możesz również sprawdzić istniejące oświadczenia niestandardowe użytkownika, które są dostępne jako właściwość obiektu użytkownika:

Node.js

// Lookup the user associated with the specified uid.
admin
  .auth()
  .getUser(uid)
  .then((userRecord) => {
    // The claims can be accessed on the user record.
    console.log(userRecord.customClaims['admin']);
  });

Jawa

// Lookup the user associated with the specified uid.
UserRecord user = FirebaseAuth.getInstance().getUser(uid);
System.out.println(user.getCustomClaims().get("admin"));

Pyton

# Lookup the user associated with the specified uid.
user = auth.get_user(uid)
# The claims can be accessed on the user record.
print(user.custom_claims.get('admin'))

Iść

// Lookup the user associated with the specified uid.
user, err := client.GetUser(ctx, uid)
if err != nil {
	log.Fatal(err)
}
// The claims can be accessed on the user record.
if admin, ok := user.CustomClaims["admin"]; ok {
	if admin.(bool) {
		log.Println(admin)
	}
}

DO#

// Lookup the user associated with the specified uid.
UserRecord user = await FirebaseAuth.DefaultInstance.GetUserAsync(uid);
Console.WriteLine(user.CustomClaims["admin"]);

Możesz usunąć oświadczenia niestandardowe użytkownika, przekazując wartość null dla customClaims .

Propaguj niestandardowe roszczenia do klienta

Po zmodyfikowaniu nowych oświadczeń użytkownika za pośrednictwem pakietu Admin SDK są one propagowane do uwierzytelnionego użytkownika po stronie klienta za pośrednictwem tokenu identyfikatora w następujący sposób:

  • Użytkownik loguje się lub ponownie uwierzytelnia po zmodyfikowaniu oświadczeń niestandardowych. W rezultacie wystawiony token ID będzie zawierał najnowsze oświadczenia.
  • Istniejąca sesja użytkownika otrzymuje odświeżany identyfikator po wygaśnięciu starszego tokenu.
  • Token identyfikatora jest wymuszany i odświeżany przez wywołanie currentUser.getIdToken(true) .

Uzyskaj dostęp do oświadczeń niestandardowych na kliencie

Oświadczenia niestandardowe można pobrać tylko za pośrednictwem tokenu identyfikatora użytkownika. Dostęp do tych oświadczeń może być niezbędny do zmodyfikowania interfejsu użytkownika klienta na podstawie roli lub poziomu dostępu użytkownika. Jednak dostęp do zaplecza powinien być zawsze wymuszany za pośrednictwem tokenu identyfikatora po jego zweryfikowaniu i przeanalizowaniu jego oświadczeń. Oświadczenia niestandardowe nie powinny być wysyłane bezpośrednio do zaplecza, ponieważ nie można im ufać poza tokenem.

Gdy najnowsze oświadczenia zostaną rozpropagowane do tokenu identyfikatora użytkownika, możesz je uzyskać, pobierając token identyfikatora:

JavaScript

firebase.auth().currentUser.getIdTokenResult()
  .then((idTokenResult) => {
     // Confirm the user is an Admin.
     if (!!idTokenResult.claims.admin) {
       // Show admin UI.
       showAdminUI();
     } else {
       // Show regular user UI.
       showRegularUI();
     }
  })
  .catch((error) => {
    console.log(error);
  });

Android

user.getIdToken(false).addOnSuccessListener(new OnSuccessListener<GetTokenResult>() {
  @Override
  public void onSuccess(GetTokenResult result) {
    boolean isAdmin = result.getClaims().get("admin");
    if (isAdmin) {
      // Show admin UI.
      showAdminUI();
    } else {
      // Show regular user UI.
      showRegularUI();
    }
  }
});

Szybki

user.getIDTokenResult(completion: { (result, error) in
  guard let admin = result?.claims?["admin"] as? NSNumber else {
    // Show regular user UI.
    showRegularUI()
    return
  }
  if admin.boolValue {
    // Show admin UI.
    showAdminUI()
  } else {
    // Show regular user UI.
    showRegularUI()
  }
})

Cel C

user.getIDTokenResultWithCompletion:^(FIRAuthTokenResult *result,
                                      NSError *error) {
  if (error != nil) {
    BOOL *admin = [result.claims[@"admin"] boolValue];
    if (admin) {
      // Show admin UI.
      [self showAdminUI];
    } else {
      // Show regular user UI.
      [self showRegularUI];
    }
  }
}];

Najlepsze praktyki dotyczące oświadczeń niestandardowych

Oświadczenia niestandardowe służą wyłącznie do zapewnienia kontroli dostępu. Nie są przeznaczone do przechowywania dodatkowych danych (takich jak profil i inne dane niestandardowe). Chociaż może się to wydawać wygodnym mechanizmem, odradza się go, ponieważ te oświadczenia są przechowywane w tokenie identyfikatora i mogą powodować problemy z wydajnością, ponieważ wszystkie uwierzytelnione żądania zawsze zawierają token identyfikatora Firebase odpowiadający zalogowanemu użytkownikowi.

  • Użyj oświadczeń niestandardowych, aby przechowywać dane tylko do kontrolowania dostępu użytkowników. Wszystkie inne dane powinny być przechowywane oddzielnie za pośrednictwem bazy danych czasu rzeczywistego lub innej pamięci po stronie serwera.
  • Reklamacje niestandardowe mają ograniczony rozmiar. Przekazanie ładunku oświadczenia niestandardowego większego niż 1000 bajtów spowoduje zgłoszenie błędu.

Przykłady i przypadki użycia

Poniższe przykłady ilustrują roszczenia niestandardowe w kontekście konkretnych przypadków użycia Firebase.

Definiowanie ról za pomocą funkcji Firebase podczas tworzenia użytkowników

W tym przykładzie oświadczenia niestandardowe są ustawiane dla użytkownika podczas tworzenia za pomocą Cloud Functions.

Oświadczenia niestandardowe można dodawać za pomocą funkcji Cloud Functions i natychmiast rozpowszechniać za pomocą bazy danych czasu rzeczywistego. Funkcja jest wywoływana tylko podczas rejestracji przy użyciu wyzwalacza onCreate . Po skonfigurowaniu oświadczeń niestandardowych są one propagowane do wszystkich istniejących i przyszłych sesji. Następnym razem, gdy użytkownik zaloguje się przy użyciu poświadczeń użytkownika, token zawiera oświadczenia niestandardowe.

Implementacja po stronie klienta (JavaScript)

const provider = new firebase.auth.GoogleAuthProvider();
firebase.auth().signInWithPopup(provider)
.catch(error => {
  console.log(error);
});

let callback = null;
let metadataRef = null;
firebase.auth().onAuthStateChanged(user => {
  // Remove previous listener.
  if (callback) {
    metadataRef.off('value', callback);
  }
  // On user login add new listener.
  if (user) {
    // Check if refresh is required.
    metadataRef = firebase.database().ref('metadata/' + user.uid + '/refreshTime');
    callback = (snapshot) => {
      // Force refresh to pick up the latest custom claims changes.
      // Note this is always triggered on first call. Further optimization could be
      // added to avoid the initial trigger when the token is issued and already contains
      // the latest claims.
      user.getIdToken(true);
    };
    // Subscribe new listener to changes on that node.
    metadataRef.on('value', callback);
  }
});

Logika Cloud Functions

Dodawany jest nowy węzeł bazy danych (metadata / ($ uid)} z możliwością odczytu / zapisu ograniczonego do uwierzytelnionego użytkownika.

const functions = require('firebase-functions');

const admin = require('firebase-admin');
admin.initializeApp();

// On sign up.
exports.processSignUp = functions.auth.user().onCreate((user) => {
  // Check if user meets role criteria.
  if (user.email &&
      user.email.endsWith('@admin.example.com') &&
      user.emailVerified) {
    const customClaims = {
      admin: true,
      accessLevel: 9
    };
    // Set custom user claims on this newly created user.
    return admin.auth().setCustomUserClaims(user.uid, customClaims)
      .then(() => {
        // Update real-time database to notify client to force refresh.
        const metadataRef = admin.database().ref("metadata/" + user.uid);
        // Set the refresh time to the current UTC timestamp.
        // This will be captured on the client to force a token refresh.
        return metadataRef.set({refreshTime: new Date().getTime()});
      })
      .catch(error => {
        console.log(error);
      });
  }
});

Reguły baz danych

{
  "rules": {
    "metadata": {
      "$user_id": {
        // Read access only granted to the authenticated user.
        ".read": "$user_id === auth.uid",
        // Write access only via Admin SDK.
        ".write": false
      }
    }
  }
}

Definiowanie ról poprzez żądanie HTTP

Poniższy przykład ustawia niestandardowe oświadczenia użytkownika dla nowo zalogowanego użytkownika za pośrednictwem żądania HTTP.

Implementacja po stronie klienta (JavaScript)

const provider = new firebase.auth.GoogleAuthProvider();
firebase.auth().signInWithPopup(provider)
.then((result) => {
  // User is signed in. Get the ID token.
  return result.user.getIdToken();
})
.then((idToken) => {
  // Pass the ID token to the server.
  $.post(
    '/setCustomClaims',
    {
      idToken: idToken
    },
    (data, status) => {
      // This is not required. You could just wait until the token is expired
      // and it proactively refreshes.
      if (status == 'success' && data) {
        const json = JSON.parse(data);
        if (json && json.status == 'success') {
          // Force token refresh. The token claims will contain the additional claims.
          firebase.auth().currentUser.getIdToken(true);
        }
      }
    });
}).catch((error) => {
  console.log(error);
});

Implementacja zaplecza (Admin SDK)

app.post('/setCustomClaims', (req, res) => {
  // Get the ID token passed.
  const idToken = req.body.idToken;
  // Verify the ID token and decode its payload.
  admin.auth().verifyIdToken(idToken).then((claims) => {
    // Verify user is eligible for additional privileges.
    if (typeof claims.email !== 'undefined' &&
        typeof claims.email_verified !== 'undefined' &&
        claims.email_verified &&
        claims.email.endsWith('@admin.example.com')) {
      // Add custom claims for additional privileges.
      admin.auth().setCustomUserClaims(claims.sub, {
        admin: true
      }).then(function() {
        // Tell client to refresh token on user.
        res.end(JSON.stringify({
          status: 'success'
        });
      });
    } else {
      // Return nothing.
      res.end(JSON.stringify({status: 'ineligible'});
    }
  });
});

Tego samego przepływu można użyć podczas uaktualniania poziomu dostępu istniejącego użytkownika. Weźmy na przykład bezpłatną aktualizację użytkownika do płatnej subskrypcji. Token identyfikatora użytkownika jest wysyłany z informacjami o płatności do serwera zaplecza za pośrednictwem żądania HTTP. Po pomyślnym przetworzeniu płatności użytkownik zostaje ustawiony jako płatny subskrybent za pośrednictwem pakietu Admin SDK. Pomyślna odpowiedź HTTP jest zwracana do klienta w celu wymuszenia odświeżenia tokenu.

Definiowanie ról za pomocą skryptu zaplecza

Można ustawić cykliczny skrypt (nie zainicjowany przez klienta) w celu zaktualizowania oświadczeń niestandardowych użytkownika:

Node.js

admin
  .auth()
  .getUserByEmail('user@admin.example.com')
  .then((user) => {
    // Confirm user is verified.
    if (user.emailVerified) {
      // Add custom claims for additional privileges.
      // This will be picked up by the user on token refresh or next sign in on new device.
      return admin.auth().setCustomUserClaims(user.uid, {
        admin: true,
      });
    }
  })
  .catch((error) => {
    console.log(error);
  });

Jawa

UserRecord user = FirebaseAuth.getInstance()
    .getUserByEmail("user@admin.example.com");
// Confirm user is verified.
if (user.isEmailVerified()) {
  Map<String, Object> claims = new HashMap<>();
  claims.put("admin", true);
  FirebaseAuth.getInstance().setCustomUserClaims(user.getUid(), claims);
}

Pyton

user = auth.get_user_by_email('user@admin.example.com')
# Confirm user is verified
if user.email_verified:
    # Add custom claims for additional privileges.
    # This will be picked up by the user on token refresh or next sign in on new device.
    auth.set_custom_user_claims(user.uid, {
        'admin': True
    })

Iść

user, err := client.GetUserByEmail(ctx, "user@admin.example.com")
if err != nil {
	log.Fatal(err)
}
// Confirm user is verified
if user.EmailVerified {
	// Add custom claims for additional privileges.
	// This will be picked up by the user on token refresh or next sign in on new device.
	err := client.SetCustomUserClaims(ctx, user.UID, map[string]interface{}{"admin": true})
	if err != nil {
		log.Fatalf("error setting custom claims %v\n", err)
	}

}

DO#

UserRecord user = await FirebaseAuth.DefaultInstance
    .GetUserByEmailAsync("user@admin.example.com");
// Confirm user is verified.
if (user.EmailVerified)
{
    var claims = new Dictionary<string, object>()
    {
        { "admin", true },
    };
    await FirebaseAuth.DefaultInstance.SetCustomUserClaimsAsync(user.Uid, claims);
}

Oświadczenia niestandardowe można również modyfikować przyrostowo za pomocą pakietu Admin SDK:

Node.js

admin
  .auth()
  .getUserByEmail('user@admin.example.com')
  .then((user) => {
    // Add incremental custom claim without overwriting existing claims.
    const currentCustomClaims = user.customClaims;
    if (currentCustomClaims['admin']) {
      // Add level.
      currentCustomClaims['accessLevel'] = 10;
      // Add custom claims for additional privileges.
      return admin.auth().setCustomUserClaims(user.uid, currentCustomClaims);
    }
  })
  .catch((error) => {
    console.log(error);
  });

Jawa

UserRecord user = FirebaseAuth.getInstance()
    .getUserByEmail("user@admin.example.com");
// Add incremental custom claim without overwriting the existing claims.
Map<String, Object> currentClaims = user.getCustomClaims();
if (Boolean.TRUE.equals(currentClaims.get("admin"))) {
  // Add level.
  currentClaims.put("level", 10);
  // Add custom claims for additional privileges.
  FirebaseAuth.getInstance().setCustomUserClaims(user.getUid(), currentClaims);
}

Pyton

user = auth.get_user_by_email('user@admin.example.com')
# Add incremental custom claim without overwriting existing claims.
current_custom_claims = user.custom_claims
if current_custom_claims.get('admin'):
    # Add level.
    current_custom_claims['accessLevel'] = 10
    # Add custom claims for additional privileges.
    auth.set_custom_user_claims(user.uid, current_custom_claims)

Iść

user, err := client.GetUserByEmail(ctx, "user@admin.example.com")
if err != nil {
	log.Fatal(err)
}
// Add incremental custom claim without overwriting existing claims.
currentCustomClaims := user.CustomClaims
if currentCustomClaims == nil {
	currentCustomClaims = map[string]interface{}{}
}

if _, found := currentCustomClaims["admin"]; found {
	// Add level.
	currentCustomClaims["accessLevel"] = 10
	// Add custom claims for additional privileges.
	err := client.SetCustomUserClaims(ctx, user.UID, currentCustomClaims)
	if err != nil {
		log.Fatalf("error setting custom claims %v\n", err)
	}

}

DO#

UserRecord user = await FirebaseAuth.DefaultInstance
    .GetUserByEmailAsync("user@admin.example.com");
// Add incremental custom claims without overwriting the existing claims.
object isAdmin;
if (user.CustomClaims.TryGetValue("admin", out isAdmin) && (bool)isAdmin)
{
    var claims = new Dictionary<string, object>(user.CustomClaims);
    // Add level.
    claims["level"] = 10;
    // Add custom claims for additional privileges.
    await FirebaseAuth.DefaultInstance.SetCustomUserClaimsAsync(user.Uid, claims);
}