Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

Контроль доступа с помощью настраиваемых утверждений и правил безопасности

SDK Firebase Admin поддерживает определение настраиваемых атрибутов в учетных записях пользователей. Это дает возможность реализовывать различные стратегии контроля доступа, включая контроль доступа на основе ролей, в приложениях Firebase. Эти настраиваемые атрибуты могут предоставлять пользователям разные уровни доступа (роли), которые применяются в правилах безопасности приложения.

Роли пользователей могут быть определены для следующих общих случаев:

  • Предоставление пользователю прав администратора для доступа к данным и ресурсам.
  • Определение различных групп, к которым принадлежит пользователь.
  • Обеспечение многоуровневого доступа:
    • Разграничение платных и бесплатных абонентов.
    • Отличие модераторов от обычных пользователей.
    • Заявление учителя / ученика и т. Д.
  • Добавьте дополнительный идентификатор для пользователя. Например, пользователь Firebase может сопоставить другой UID в другой системе.

Давайте рассмотрим случай, когда вы хотите ограничить доступ к узлу базы данных «adminContent». Вы можете сделать это с помощью поиска в базе данных по списку администраторов. Тем не менее, вы можете достичь того же объективного более эффективного использования претензии на заказ пользователь по имени admin с помощью следующей Realtime правило базы данных:

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

Настраиваемые пользовательские утверждения доступны через токены аутентификации пользователя. В приведенном выше примере, только пользователи с admin значение ИСТИНА в их символической претензии бы доступ на чтение / запись к adminContent узлу. Поскольку токен идентификатора уже содержит эти утверждения, дополнительная обработка или поиск не требуется для проверки разрешений администратора. Кроме того, токен идентификатора является надежным механизмом для доставки этих настраиваемых утверждений. Любой аутентифицированный доступ должен проверять токен идентификатора перед обработкой связанного запроса.

Примеры кода и решения , описанные в этой странице извлечь из обоих на стороне клиента Firebase Auth API , и на стороне сервера Авт API , предоставленной Admin SDK .

Устанавливайте и проверяйте пользовательские утверждения с помощью Admin SDK.

Пользовательские утверждения могут содержать конфиденциальные данные, поэтому они должны устанавливаться только из среды привилегированного сервера с помощью 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.
  });

Джава

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

Идти

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

Объект пользовательских требований не должен содержать какой - либо РСИН защищены имена ключей или Firebase зарезервированных имена. Полезная нагрузка настраиваемых утверждений не должна превышать 1000 байт.

Идентификационный токен, отправленный на внутренний сервер, может подтвердить личность и уровень доступа пользователя с помощью Admin SDK следующим образом:

Node.js

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

Джава

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

Идти

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

Вы также можете проверить существующие настраиваемые утверждения пользователя, которые доступны как свойство в объекте пользователя:

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

Джава

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

Идти

// 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"]);

Вы можете удалить пользовательские требования пользователя, передавая нуль для customClaims .

Распространение индивидуальных претензий клиенту

После изменения новых утверждений для пользователя с помощью Admin SDK они передаются аутентифицированному пользователю на стороне клиента с помощью токена идентификатора следующими способами:

  • Пользователь входит в систему или повторно аутентифицируется после изменения настраиваемых утверждений. Идентификационный токен, выданный в результате, будет содержать последние утверждения.
  • Идентификационный токен существующего пользовательского сеанса обновляется после истечения срока действия старого токена.
  • ID лексема сила обновляется посредством вызова currentUser.getIdToken(true) .

Доступ к настраиваемым претензиям на клиенте

Пользовательские утверждения можно получить только с помощью токена идентификатора пользователя. Доступ к этим утверждениям может потребоваться для изменения пользовательского интерфейса клиента в зависимости от роли или уровня доступа пользователя. Однако бэкэнд-доступ всегда должен осуществляться через токен идентификатора после его проверки и анализа утверждений. Пользовательские утверждения не следует отправлять непосредственно в серверную часть, поскольку им нельзя доверять вне токена.

Как только последние утверждения распространяются на токен идентификатора пользователя, вы можете получить их, получив токен идентификатора:

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

Быстрый

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

Цель-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];
    }
  }
}];

Лучшие практики для настраиваемых претензий

Пользовательские утверждения используются только для управления доступом. Они не предназначены для хранения дополнительных данных (таких как профиль и другие пользовательские данные). Хотя это может показаться удобным механизмом, он настоятельно не рекомендуется, поскольку эти утверждения хранятся в токене идентификатора и могут вызвать проблемы с производительностью, поскольку все аутентифицированные запросы всегда содержат токен идентификатора Firebase, соответствующий вошедшему в систему пользователю.

  • Используйте настраиваемые утверждения для хранения данных только для управления доступом пользователей. Все остальные данные должны храниться отдельно через базу данных реального времени или другое хранилище на стороне сервера.
  • Индивидуальные претензии ограничены по размеру. Передача полезной нагрузки настраиваемых утверждений более 1000 байт вызовет ошибку.

Примеры и варианты использования

Следующие примеры иллюстрируют настраиваемые утверждения в контексте конкретных вариантов использования Firebase.

Определение ролей с помощью функций Firebase при создании пользователя

В этом примере пользовательские утверждения устанавливаются для пользователя при создании с помощью облачных функций.

Пользовательские утверждения можно добавлять с помощью облачных функций и сразу же распространять с помощью базы данных реального времени. Функция вызывается только на Signup , используя onCreate курок. Как только пользовательские утверждения установлены, они распространяются на все существующие и будущие сеансы. В следующий раз, когда пользователь войдет в систему с учетными данными пользователя, токен будет содержать настраиваемые утверждения.

Реализация на стороне клиента (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);
  }
});

Логика облачных функций

Добавлен новый узел базы данных (метаданные / ($ uid)} с ограничением чтения / записи для аутентифицированного пользователя.

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

Правила базы данных

{
  "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
      }
    }
  }
}

Определение ролей через HTTP-запрос

В следующем примере настраиваемые пользовательские утверждения устанавливаются для вновь вошедшего пользователя с помощью HTTP-запроса.

Реализация на стороне клиента (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);
});

Бэкэнд-реализация (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' }));
  }
});

Тот же поток можно использовать при обновлении уровня доступа существующего пользователя. Возьмем, к примеру, бесплатное обновление пользователя до платной подписки. Идентификационный токен пользователя отправляется с платежной информацией на внутренний сервер через HTTP-запрос. После успешной обработки платежа пользователь становится платным подписчиком через Admin SDK. Успешный HTTP-ответ возвращается клиенту для принудительного обновления токена.

Определение ролей через серверный скрипт

Повторяющийся сценарий (не инициированный клиентом) может быть настроен на запуск для обновления пользовательских утверждений:

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

Джава

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

Идти

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

Пользовательские утверждения также можно постепенно изменять с помощью 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);
  });

Джава

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)

Идти

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 = new Dictionary<string, object>(user.CustomClaims);
    // Add level.
    claims["level"] = 10;
    // Add custom claims for additional privileges.
    await FirebaseAuth.DefaultInstance.SetCustomUserClaimsAsync(user.Uid, claims);
}