Kontrola dostępu za pomocą żądań niestandardowych i reguł zabezpieczeń

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

Role użytkowników można definiować w tych typowych przypadkach:

  • Przyznanie użytkownikowi uprawnień administratora dostępu do danych i zasobów.
  • definiowanie różnych grup, do których należy użytkownik;
  • Zapewnianie wielopoziomowego dostępu:
    • odróżnianie płatnych i bezpłatnych subskrybentów,
    • odróżnianie moderatorów od zwykłych użytkowników,
    • aplikacja dla nauczycieli/uczniów itp.
  • Dodaj dodatkowy identyfikator użytkownika. Na przykład użytkownik Firebase może być mapowany na inny identyfikator 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ć, wyszukując w bazie danych listę administratorów. Możesz jednak osiągnąć ten sam cel w bardziej efektywny sposób, używając niestandardowej deklaracji użytkownika o nazwie admin z tą regułą Realtime Database:

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

Niestandardowe oświadczenia użytkownika są dostępne za pomocą tokenów uwierzytelniania użytkownika. W powyższym przykładzie tylko użytkownicy z wartością admin ustawioną na „true” w deklaracji tokena będą mieli uprawnienia do zapisu i odczytu węzła adminContent. Token identyfikacji zawiera już te asercje, więc nie jest potrzebne żadne dodatkowe przetwarzanie ani wyszukiwanie, aby sprawdzić uprawnienia administratora. Dodatkowo token identyfikacji jest zaufanym mechanizmem dostarczania tych niestandardowych deklaracji. Wszystkie uwierzytelnione próby dostępu muszą zweryfikować token identyfikacji przed przetworzeniem powiązanego żądania.

Przykłady kodu i rozwiązania opisane na tej stronie korzystają zarówno z interfejsów Firebase Auth API po stronie klienta, jak i interfejsów Auth API po stronie serwera, które są udostępniane przez pakiet Admin SDK.

Ustawianie i weryfikowanie niestandardowych deklaracji użytkowników za pomocą pakietu Admin SDK

Oświadczenia niestandardowe mogą zawierać dane wrażliwe, dlatego powinny być ustawiane tylko z uprzywilejowanego środowiska serwera przez pakiet Firebase Admin SDK.

Node.js

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

getAuth()
  .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.
  });

Java

// 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.

Python

# 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.

Go

// 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.

C#

// 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 zarezerwowanych dla OIDC ani nazw zarezerwowanych dla Firebase. Ładunek nie może przekraczać 1000 bajtów. Oświadczenia niestandardowe muszą być możliwe do serializacji w formacie JSON. Obsługiwane typy to ciągi znaków, liczby, wartości logiczne, tablice, obiekty i wartości null. Nieobsługiwane typy, takie jak Date, undefined, funkcje lub inne wartości inne niż JSON, spowodują błędy.

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

Node.js

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

Java

// 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.
}

Python

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

Go

// 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.
	}
}

C#

// 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 też sprawdzić istniejące niestandardowe oświadczenia użytkownika, które są dostępne jako właściwość obiektu użytkownika:

Node.js

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

Java

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

Python

# 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'))

Go

// 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)
	}
}

C#

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

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

Przekazywanie niestandardowych deklaracji do klienta

Po zmodyfikowaniu nowych oświadczeń użytkownika za pomocą pakietu Admin SDK są one propagowane do uwierzytelnionego użytkownika po stronie klienta za pomocą tokena identyfikacji na te sposoby:

  • użytkownik zaloguje się lub ponownie uwierzytelni po zmodyfikowaniu oświadczeń niestandardowych; Wystawiony w wyniku token identyfikacji będzie zawierać najnowsze oświadczenia.
  • Token identyfikacji istniejącej sesji użytkownika jest odświeżany po wygaśnięciu starszego tokena.
  • Token identyfikacji jest odświeżany wymuszenie przez wywołanie currentUser.getIdToken(true).

Uzyskiwanie dostępu do niestandardowych deklaracji w kliencie

Oświadczenia niestandardowe można pobrać tylko za pomocą tokena identyfikacji użytkownika. Dostęp do tych deklaracji może być konieczny do modyfikowania interfejsu klienta na podstawie roli lub poziomu dostępu użytkownika. Jednak dostęp do backendu powinien być zawsze wymuszany za pomocą tokena identyfikacji po jego zweryfikowaniu i przeanalizowaniu jego oświadczeń. Niestandardowe oświadczenia nie powinny być wysyłane bezpośrednio do backendu, ponieważ nie można im ufać poza tokenem.

Gdy najnowsze deklaracje zostaną rozpowszechnione w tokenie identyfikacji użytkownika, możesz je uzyskać, pobierając token identyfikacji:

JavaScript

import { getAuth } from "firebase/auth";
getAuth().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();
    }
  }
});

Swift

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()
  }
})

Objective-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];
    }
  }
}];

Sprawdzone metody dotyczące niestandardowych deklaracji

Oświadczenia niestandardowe służą tylko do kontroli dostępu. Nie są przeznaczone do przechowywania dodatkowych danych (takich jak dane profilu i inne dane niestandardowe). Może się wydawać, że to wygodny sposób, ale zdecydowanie odradzamy takie rozwiązanie, ponieważ te oświadczenia są przechowywane w tokenie identyfikacji i mogą powodować problemy z wydajnością, ponieważ wszystkie uwierzytelnione żądania zawsze zawierają token identyfikacji Firebase odpowiadający zalogowanemu użytkownikowi.

  • Używaj oświadczeń niestandardowych do przechowywania danych wyłącznie na potrzeby kontrolowania dostępu użytkowników. Wszystkie inne dane powinny być przechowywane oddzielnie w bazie danych czasu rzeczywistego lub w innym miejscu po stronie serwera.
  • Rozmiar niestandardowych oświadczeń jest ograniczony. Przekazanie ładunku niestandardowych oświadczeń o rozmiarze większym niż 1000 bajtów spowoduje błąd.

Przykłady i przypadki użycia

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

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

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

Niestandardowe oświadczenia można dodawać za pomocą Cloud Functions i natychmiast rozpowszechniać za pomocą Realtime Database. Funkcja jest wywoływana tylko podczas rejestracji za pomocą aktywatora onCreate. Po ustawieniu niestandardowych oświadczeń są one propagowane do wszystkich istniejących i przyszłych sesji. Gdy użytkownik zaloguje się następnym razem przy użyciu danych logowania, token będzie zawierać niestandardowe oświadczenia.

Implementacja po stronie klienta (JavaScript)

import { GoogleAuthProvider, signInWithPopup, getAuth, onAuthStateChanged } from "firebase/auth";
import { getDatabase, onValue, ref } from "firebase/database";

const auth = getAuth();
const database = getDatabase();

const provider = new GoogleAuthProvider();

signInWithPopup(auth, provider).catch(error => {
  console.log(error);
});

let unsubscribeFn = null;
let metadataRef = null;
onAuthStateChanged(auth, user => {
  // Remove previous listener.
  if (unsubscribeFn) {
    unsubscribeFn();
  }
  // On user login add new listener.
  if (user) {
    // Check if refresh is required.
    metadataRef = ref(database, 'metadata/' + user.uid + '/refreshTime');
    // Subscribe new listener to changes on that node.
    unsubscribeFn = onValue(metadataRef, async (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);
    });
  }
});

Logika Cloud Functions

Dodawany jest nowy węzeł bazy danych (metadata/($uid)} z uprawnieniami do odczytu i zapisu ograniczonymi do uwierzytelnionego użytkownika.

const functions = require('firebase-functions');
const { initializeApp } = require('firebase-admin/app');
const { getAuth } = require('firebase-admin/auth');
const { getDatabase } = require('firebase-admin/database');

initializeApp();

// On sign up.
exports.processSignUp = functions.auth.user().onCreate(async (user) => {
  // Check if user meets role criteria.
  if (
    user.email &&
    user.email.endsWith('@admin.example.com') &&
    user.emailVerified
  ) {
    const customClaims = {
      admin: true,
      accessLevel: 9
    };

    try {
      // Set custom user claims on this newly created user.
      await getAuth().setCustomUserClaims(user.uid, customClaims);

      // Update real-time database to notify client to force refresh.
      const metadataRef = getDatabase().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.
      await  metadataRef.set({refreshTime: new Date().getTime()});
    } catch (error) {
      console.log(error);
    }
  }
});

Reguły bazy 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 za pomocą żądania HTTP

W tym przykładzie niestandardowe oświadczenia użytkownika są ustawiane dla nowo zalogowanego użytkownika za pomocą żądania HTTP.

Implementacja po stronie klienta (JavaScript)

import { GoogleAuthProvider, signInWithPopup, getAuth, onAuthStateChanged } from "firebase/auth";
import { getDatabase, onValue, ref } from "firebase/database";

const auth = getAuth();
const database = getDatabase();

const provider = new GoogleAuthProvider();

signInWithPopup(auth, 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.
          auth.currentUser.getIdToken(true);
        }
      }
    });
}).catch((error) => {
  console.log(error);
});

Implementacja backendu (Admin SDK)

app.post('/setCustomClaims', async (req, res) => {
  // Get the ID token passed.
  const idToken = req.body.idToken;

  // Verify the ID token and decode its payload.
  const claims = await getAuth().verifyIdToken(idToken);

  // 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.
    await getAuth().setCustomUserClaims(claims.sub, {
      admin: true
    });

    // Tell client to refresh token on user.
    res.end(JSON.stringify({
      status: 'success'
    }));
  } else {
    // Return nothing.
    res.end(JSON.stringify({ status: 'ineligible' }));
  }
});

Tego samego procesu można użyć podczas podnoszenia poziomu dostępu dotychczasowego użytkownika. Weźmy na przykład użytkownika, który przechodzi z bezpłatnej na płatną subskrypcję. Token identyfikacji użytkownika jest wysyłany wraz z informacjami o płatności do serwera backendu za pomocą żądania HTTP. Po przetworzeniu płatności użytkownik jest ustawiany jako użytkownik płatnej subskrypcji za pomocą pakietu Admin SDK. Do klienta jest zwracana odpowiedź HTTP o powodzeniu, aby wymusić odświeżenie tokena.

Definiowanie ról za pomocą skryptu backendu

Można ustawić cykliczny skrypt (nieinicjowany przez klienta), który będzie aktualizować niestandardowe oświadczenia użytkownika:

Node.js

getAuth()
  .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 getAuth().setCustomUserClaims(user.uid, {
        admin: true,
      });
    }
  })
  .catch((error) => {
    console.log(error);
  });

Java

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);
}

Python

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
    })

Go

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)
	}

}

C#

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 też modyfikować przyrostowo za pomocą pakietu Admin SDK:

Node.js

getAuth()
  .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 getAuth().setCustomUserClaims(user.uid, currentCustomClaims);
    }
  })
  .catch((error) => {
    console.log(error);
  });

Java

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);
}

Python

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)

Go

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)
	}

}

C#

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 = user.CustomClaims.ToDictionary(kvp => kvp.Key, kvp => kvp.Value);
    // Add level.
    var level = 10;
    claims["level"] = level;
    // Add custom claims for additional privileges.
    await FirebaseAuth.DefaultInstance.SetCustomUserClaimsAsync(user.Uid, claims);
}