Ověřování javascriptových aplikací ve službách Azure pomocí knihovny identit Azure
Pokud aplikace potřebuje přístup k prostředku Azure, jako je Storage, Key Vault nebo Cognitive Services, musí být aplikace ověřena v Azure. To platí pro všechny aplikace, ať už nasazené v Azure, nasazené místně nebo ve vývoji na místní vývojářské pracovní stanici. Tento článek popisuje doporučené přístupy k ověřování aplikace v Azure při použití sady Azure SDK pro JavaScript.
Doporučený přístup k ověřování aplikací
Doporučeným přístupem je, aby vaše aplikace při ověřování prostředků Azure používaly
Konkrétní typ ověřování na základě tokenů, který by aplikace měla použít k ověření prostředků Azure, závisí na tom, kde je aplikace spuštěná, a zobrazuje se v následujícím diagramu.
| Životní prostředí | Autentizace |
|---|---|
| místní | Když vývojář spouští aplikaci během místního vývoje– Aplikace se může ověřit v Azure pomocí instančního objektu aplikace pro místní vývoj nebo pomocí přihlašovacích údajů Azure vývojáře. Každá z těchto možností je podrobněji popsána v části ověřování během místního vývoje. |
| Azurová | Když je aplikace hostovaná v Azure– Aplikace by se měla ověřovat u prostředků Azure pomocí spravované identity. Tato možnost je podrobněji popsána níže v části ověřování v serverových prostředích. |
| Lokální systém | Když je aplikace hostovaná a nasazená v rámci podniku, aplikace by se měla ověřit u prostředků Azure pomocí služebního účtu aplikace. Tato možnost je podrobněji popsána níže v části ověřování v serverových prostředích. |
Výhody ověřování založeného na tokenech
Při vytváření aplikací pro Azure se důrazně doporučuje ověřování na základě tokenů u tajných kódů (připojovací řetězce nebo klíče). Ověřování na základě tokenů je k dispozici s DefaultAzureCredential.
| Ověřování na základě tokenů | Tajné kódy (připojovací řetězce a klíče) |
|---|---|
| princip nejnižších oprávnění, nastavte konkrétní oprávnění potřebná aplikací v prostředku Azure. | Připojovací řetězec nebo klíč uděluje úplná práva k prostředku Azure. |
| K uložení neexistuje žádný tajný kód aplikace. | Tajné kódy je nutné ukládat a otáčet v nastavení aplikace nebo proměnné prostředí. |
| Knihovna Identit Azure spravuje tokeny za vás na pozadí. Díky tomu se ověřování založené na tokenech snadno používá jako připojovací řetězec. | Tajemství nejsou spravována. |
Použití připojovacích řetězců by mělo být omezené na počáteční testování konceptů aplikací nebo prototypů vývoje, které nepřistupují k produkčním nebo citlivým datům. Jinak by se při ověřování prostředků Azure měly vždy upřednostňovat třídy ověřování založené na tokenech, které jsou k dispozici v knihovně identit Azure.
Použijte následující knihovnu:
DefaultAzureCredential
Třída DefaultAzureCredential poskytovaná knihovnou identit Azure umožňuje aplikacím používat různé metody ověřování v závislosti na prostředí, ve kterém se spouští. Toto chování umožňuje zvýšit úroveň aplikací z místního vývoje na testovací prostředí do produkčního prostředí beze změn kódu. Nakonfigurujete odpovídající metodu ověřování pro každé prostředí a DefaultAzureCredential tuto metodu ověřování automaticky rozpozná a použije. Použití DefaultAzureCredential by mělo být upřednostňované před ručním kódováním podmíněné logiky nebo příznaků funkcí pro použití různých metod ověřování v různých prostředích.
Podrobnosti o používání DefaultAzureCredential najdete v tématu Použití DefaultAzureCredential v aplikaci.
Ověřování v serverových prostředích
Při hostování v serverovém prostředí by každá aplikace měla mít přiřazenou jedinečnou identitu aplikace na každé prostředí. V Azure je identita aplikace reprezentována instančním objektem, speciálním typem objektu zabezpečení určeným k identifikaci a ověřování aplikací v Azure. Typ služebního principála, který se má použít pro vaši aplikaci, závisí na tom, kde vaše aplikace běží.
Ověřování během místního vývoje
Když je aplikace spuštěná na pracovní stanici vývojáře během místního vývoje, musí se místní prostředí stále ověřovat ve všech službách Azure, které aplikace používá.
Použití DefaultAzureCredential v aplikaci
DefaultAzureCredential je strukturovaná seřazená posloupnost mechanismů pro ověřování v Microsoft Entra ID. Každý mechanismus ověřování je třída odvozená z třídy TokenCredential a nazývá se pověření. Za běhu se DefaultAzureCredential pokusí ověřit pomocí prvních přihlašovacích údajů. Pokud se tento přihlašovací údaj nepodaří získat přístupový token, pokusí se další přihlašovací údaje v této sekvenci atd., dokud se přístupový token úspěšně nezíská. Aplikace tak může používat různé přihlašovací údaje v různých prostředích bez psaní kódu specifického pro prostředí.
Pokud chcete použít DefaultAzureCredential, přidejte do aplikace balíček @azure/identity.
npm install @azure/identity
Pak následující vzorový kód ukazuje, jak vytvořit instanci objektu DefaultAzureCredential a použít ho s klientskou třídou služby Azure SDK – v tomto případě BlobServiceClient sloužící k přístupu ke službě Azure Blob Storage.
import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config';
const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');
const blobServiceClient = new BlobServiceClient(
`https://${accountName}.blob.core.windows.net`,
new DefaultAzureCredential()
);
DefaultAzureCredential automaticky rozpozná ověřovací mechanismus nakonfigurovaný pro aplikaci a získá potřebné tokeny pro ověření aplikace v Azure. Pokud aplikace používá více než jednoho klienta sady SDK, lze stejný objekt přihlašovacích údajů použít s každým objektem klienta sady SDK.