Biztonságos ASP.NET Core Blazor WebAssembly

Blazor WebAssembly alkalmazásokat ugyanúgy védik, mint az egyoldalas alkalmazásokat (SLA-k). A felhasználók hitelesítésére számos módszer létezik, de a leggyakoribb és legátfogóbb módszer az OAuth 2.0 protokoll alapuló implementáció használata, például OpenID Connect (OIDC).

A Blazor WebAssembly biztonsági dokumentáció elsősorban a felhasználói hitelesítési és engedélyezési feladatok elvégzésére összpontosít. Az OAuth 2.0/OIDC általános koncepcióinak ismertetéséhez lásd a fő áttekintési cikk További erőforrások szakaszát.

Bizalmas adatok és hitelesítő adatok ügyféloldali/SPA-biztonsága

Egy Blazor WebAssembly alkalmazás .NET/C#-kódbázisa az ügyfelek számára van kiszolgálva, és az alkalmazás kódja nem védhető meg a felhasználók általi ellenőrzés és illetéktelen módosítás ellen. Soha ne helyezzen bizalmas adatokat Blazor WebAssembly alkalmazásokba, például alkalmazás titkos kulcsaiba, kapcsolati sztringjeibe, jelszavaiba, biztonsági kulcsaiba és privát .NET/C# kódjába.

A következő technológiák hasznosak a bizalmas adatok tárolásához, amelyek együtt használhatók ugyanabban az alkalmazásban az adatok fejlesztési és előkészítési/éles környezetek közötti tárolási feladatainak felosztására:

• Secret Manager eszköz: Csak a helyi fejlesztési rendszeren használható.
• Azure Key Vault: Használható a fejlesztési környezetben, helyben futó alkalmazásokhoz, valamint az előkészítési/éles környezetekben való telepítésekhez.

Az előző megközelítések példáiért lásd a fiók megerősítése és jelszó-helyreállítás ASP.NET Core-ban, az ASP.NET Core Blazor WebAssembly, Identity,részekkel.

Webes API-kérések

A .NET/C# kód és adatok védelméhez használja a ASP.NET Core Data Protection funkcióit egy kiszolgálóoldali ASP.NET Core háttérrendszer webes API-val. Az ügyféloldali Blazor WebAssembly alkalmazás meghívja a kiszolgálóoldali webes API-t az alkalmazások biztonságos funkcióinak és adatfeldolgozásának érdekében. További információ: Webes API meghívása egy ASP.NET Core Blazor-alkalmazásból, valamint a dokumentációs csomópontban található cikkek és példák.

Blazor WebAssembly alkalmazások gyakran nem kezdeményezhetnek közvetlen hívásokat a különböző eredetek között a webes API-khoz, a CORS biztonságimiatt. Egy tipikus kivétel a következőhöz hasonló:

Hozzáférés a(z) "{URL}" címen való lekéréshez a forrásból "https://localhost:{PORT}' a CORS-szabályzat letiltotta: Nincs "Access-Control-Allow-Origin" fejléc a kért erőforráson. Ha egy átlátszatlan válasz megfelel az igényeinek, állítsa a kérés módját "no-cors" értékre, hogy lekérje az erőforrást, ha a CORS le van tiltva.

Még akkor is, ha a SetBrowserRequestMode függvényt BrowserRequestMode mezővel, NoCors (1) értékkel hívja meg a korábbi kivétel megkerülésére, a kérés általában meghiúsul a webes API eredetére vonatkozó CORS-korlátozások miatt, például olyan korlátozások miatt, amelyek csak meghatározott forrásokból származó hívásokat engedélyeznek, valamint olyan korlátozások miatt, amelyek megakadályozzák a böngészőből érkező JavaScript fetch kéréseket. Az ilyen hívások sikerének egyetlen módja az, ha a webes API-t meghívja, hogy a forrás a megfelelő CORS-konfigurációval hívja meg a forrását. A legtöbb külső webes API nem teszi lehetővé a CORS-szabályzatok konfigurálását. A korlátozás kezeléséhez fogadja el az alábbi stratégiák egyikét:

• Saját kiszolgálóoldali ASP.NET Core háttérbeli webes API-t tart fenn. Az ügyféloldali Blazor WebAssembly alkalmazás meghívja a kiszolgálóoldali webes API-t, a webes API pedig a kiszolgálóalapú C#-kódból (nem böngészőből) a külső webes API-ba küldi a kérést a megfelelő CORS-fejlécekkel, és visszaadja az eredményt az ügyféloldali Blazor WebAssembly alkalmazásnak.

• Használjon proxyszolgáltatást az ügyféloldali Blazor WebAssembly alkalmazás kérésének továbbítására a külső webes API felé. A proxyszolgáltatás egy kiszolgálóoldali alkalmazással küldi el a kérést az ügyfél nevében, és a hívás sikerességét követően visszaadja az eredményt. Az alábbi példában CloudFlare CORS PROXYalapján a {REQUEST URI} helyőrző a kérelem URI-ja:

  @using System.Net
  @inject IHttpClientFactory ClientFactory
  
  ...
  
  @code {
      public async Task CallApi()
      {
          var client = ClientFactory.CreateClient();
  
          var urlEncodedRequestUri = WebUtility.UrlEncode("{REQUEST URI}");
  
          using var request = new HttpRequestMessage(HttpMethod.Get, 
              $"https://corsproxy.io/?{urlEncodedRequestUri}");
  
          using var response = await client.SendAsync(request);
  
          ...
      }
  }
  

Hitelesítési kódtár

Blazor WebAssembly támogatja az alkalmazások hitelesítését és engedélyezését az OIDC a Microsoft.AspNetCore.Components.WebAssembly.Authentication könyvtáron keresztül, a Microsoft identitásplatformhasználatával. A kódtár primitívek készletét biztosítja a ASP.NET Core háttérrendszerekkel való zökkenőmentes hitelesítéshez. A kódtár bármely külső Identity-szolgáltatóval (IP-címmel) hitelesíthető, amely támogatja az OIDC-t, amelyet OpenID-szolgáltatóknak (OP) neveznek.

A Blazor WebAssembly kódtár (Authentication.js) hitelesítési támogatása a Microsoft Authentication Library (MSAL, msal.js)alapul, amely a mögöttes hitelesítési protokoll részleteinek kezelésére szolgál. A Blazor WebAssembly kódtár csak a Proof Key for Code Exchange (PKCE) engedélyezési kódfolyamatot támogatja. Az implicit támogatás nem támogatott.

Az SLA-k hitelesítésére más lehetőségek is léteznek, például a SameSite cookie-k használatára. A Blazor WebAssembly mérnöki tervezése azonban az OAuthot és az OIDC-t használja a legjobb megoldásként a hitelesítéshez Blazor WebAssembly alkalmazásokban. JSON-alapúJSON-alapú hitelesítésicookie-alapú hitelesítési választottak funkcionális és biztonsági okokból:

• A jogkivonatalapú protokoll kevesebb biztonsági rést kínál, mivel a jogkivonatok nem minden kérésben lesznek elküldve.
• A jogkivonatokat kifejezetten elküldik a szervernek, így a szerver végpontok nem igényelnek védelmet helyek közötti kérelemhamisítás (CSRF)ellen. Ez lehetővé teszi Blazor WebAssembly alkalmazások üzemeltetését az MVC- vagy Razor oldal-alkalmazások mellett.
• A tokenek kevesebb engedéllyel rendelkeznek, mint a cookie-k. A jogkivonatok például nem használhatók a felhasználói fiók kezelésére vagy a felhasználó jelszavának módosítására, kivéve, ha az ilyen funkció kifejezetten implementálva van.
• A tokenek élettartama rövid, egy óra, ami korlátozza a támadási lehetőséget. A tokenek bármikor visszavonhatók.
• A saját JWT-k garanciát nyújtanak az ügyfélnek és a kiszolgálónak a hitelesítési folyamatról. Az ügyfél például képes észlelni és ellenőrizni, hogy a kapott jogkivonatok jogszerűek-e, és egy adott hitelesítési folyamat részeként lettek-e kibocsátva. Ha egy harmadik fél a hitelesítési folyamat közepén próbál jogkivonatot váltani, az ügyfél észlelheti a kapcsolt jogkivonatot, és elkerülheti annak használatát.
• Az OAuth- és OIDC-jogkivonatok nem támaszkodnak arra, hogy a felhasználói ügynök megfelelően viselkedjen az alkalmazás biztonságossá tételéhez.
• A jogkivonatalapú protokollok, például az OAuth és az OIDC lehetővé teszik a felhasználók hitelesítését és engedélyezését különálló Blazor webassembly-alkalmazásokban, azonos biztonsági jellemzőkkel.

Fontos

A Duende Identity Servert Blazor projektsablonokban alkalmazó ASP.NET Core-verziók esetében előfordulhat, hogy Duende Software licencdíjat kell fizetnie a Duende Identity Server éles használatáért. További információ: Migrálás ASP.NET Core-ból .NET 5-ről .NET 6-ra.

Hitelesítési folyamat az OIDC használatával

A Microsoft.AspNetCore.Components.WebAssembly.Authentication-kódtár számos primitív eszközt kínál a hitelesítés és az engedélyezés OIDC használatával történő implementálásához. A hitelesítés általánosan a következőképpen működik:

• Amikor egy névtelen felhasználó kiválasztja a bejelentkezési gombot, vagy Razor összetevőt vagy lapot kér az alkalmazott [Authorize] attribútummal, a rendszer átirányítja a felhasználót az alkalmazás bejelentkezési oldalára (/authentication/login).
• A bejelentkezési oldalon a hitelesítési kódtár előkészíti az engedélyezési végpontra való átirányítást. Az engedélyezési végpont kívül esik a Blazor WebAssembly alkalmazáson, és külön forrásból üzemeltethető. A végpont feladata annak meghatározása, hogy a felhasználó hitelesítve van-e, és válaszként egy vagy több tokeneket ad ki. A hitelesítési kódtár bejelentkezési visszahívást biztosít a hitelesítési válasz fogadásához.
  • Ha a felhasználó nincs hitelesítve, a rendszer átirányítja a felhasználót a mögöttes hitelesítési rendszerbe, amely általában a Core IdentityASP.NET.
  • Ha a felhasználó már hitelesített, az engedélyezési végpont létrehozza a megfelelő jogkivonatokat, és visszairányítja a böngészőt a bejelentkezési visszahívási végpontra (/authentication/login-callback).
• Amikor a Blazor WebAssembly alkalmazás betölti a bejelentkezési visszahívási végpontot (/authentication/login-callback), a rendszer feldolgozja a hitelesítési választ.
  • Ha a hitelesítési folyamat sikeresen befejeződött, a rendszer hitelesíti a felhasználót, és opcionálisan visszaküldi a felhasználó által kért eredeti védett URL-címre.
  • Ha a hitelesítési folyamat bármilyen okból meghiúsul, a rendszer elküldi a felhasználót a sikertelen bejelentkezési lapra (/authentication/login-failed), ahol hiba jelenik meg.

Authentication összetevő

A Authentication összetevő (Authentication.razor) kezeli a távoli hitelesítési műveleteket, és lehetővé teszi az alkalmazás számára a következő műveleteket:

• Alkalmazásútvonalak konfigurálása hitelesítési állapotokhoz.
• Felhasználói felület tartalmának beállítása hitelesítési állapotokhoz.
• Hitelesítési állapot kezelése.

A hitelesítési műveletek, például a regisztráció vagy a bejelentkezés a Blazor keretrendszer RemoteAuthenticatorViewCore<TAuthenticationState> összetevőjére kerülnek, amely megőrzi és szabályozza az állapotot a hitelesítési műveletek között.

További információkért és példákért lásd ASP.NET Core Blazor WebAssembly további biztonsági forgatókönyveket.

Felhatalmazás

Az Blazor WebAssembly-alkalmazásokban az engedélyezési ellenőrzések megkerülhetők, mert az ügyféloldali kódokat a felhasználók módosíthatják. Ugyanez érvényes minden ügyféloldali alkalmazástechnológiára, beleértve a JavaScript SPA-keretrendszereket vagy bármely operációs rendszer natív alkalmazásait is.

Mindig végezzen engedélyezési ellenőrzéseket a kiszolgálón az ügyféloldali alkalmazás által elért API-végpontokon belül.

Hitelesítés testreszabása

Blazor WebAssembly metódusokat biztosít a mögöttes hitelesítési kódtár további paramétereinek hozzáadására és lekérésére a külső identitásszolgáltatókkal végzett távoli hitelesítési műveletek végrehajtásához.

További paraméterek átadásához NavigationManager támogatja az előzménybejegyzési állapot átadását és beolvasását külső helymódosítások végrehajtásakor. További információ:

• Blazor Alapjai>Útválasztás és navigáció cikk
  • Navigációs előzmények állapota
  • navigációs lehetőségek
• MDN-dokumentáció: History API

Az Előzmények API által tárolt állapot a következő előnyöket nyújtja a távoli hitelesítéshez:

• A biztonságos alkalmazásvégpontnak átadott állapot a felhasználó hitelesítéséhez a authentication/login végponton végzett navigációhoz van kötve.
• Az adatok további kódolása és dekódolása elkerülhető.
• A biztonsági rések csökkennek. A navigációs állapot tárolásához használt lekérdezési sztringtől eltérően a felső szintű navigáció vagy más forrásból származó befolyás nem tudja beállítani az Előzmények API által tárolt állapotot.
• A rendszer a sikeres hitelesítés után lecseréli az előzménybejegyzést, így a rendszer eltávolítja az előzménybejegyzéshez csatolt állapotot, és nem igényel törlést.

InteractiveRequestOptions az identitásszolgáltató felé irányuló kérés, amely a bejelentkezés vagy hozzáférési token megszerzésére vonatkozik.

NavigationManagerExtensions biztosítja a bejelentkezési művelet NavigateToLogin metódusát, a kijelentkezési művelethez pedig NavigateToLogout. A metódusok meghívják a NavigationManager.NavigateTo-t, beállítva az előzmény bejegyzés állapotát egy átadott InteractiveRequestOptions-gyel vagy egy új InteractiveRequestOptions-példánnyal, amelyet a metódus hoz létre a következőhöz:

• Egy felhasználó bejelentkezik (InteractionType.SignIn) a visszatérési URL-cím aktuális URI-jával.
• Egy felhasználó kijelentkezik (InteractionType.SignOut) a visszatérési URL-cím megadásával.

A következő hitelesítési forgatókönyveket a ASP.NET Core Blazor WebAssembly további biztonsági forgatókönyvek cikkben találja:

• A bejelentkezési folyamat testreszabása
• Kijelentkezés egyéni visszatérési URL-címmel
• Az opciók testreszabása, mielőtt a tokent interaktívan megszerezné
• Beállítások testreszabása IAccessTokenProvider használatakor
• A bejelentkezési útvonal lekérése a hitelesítési beállításokból

Engedélyezés megkövetelése a teljes alkalmazáshoz

Alkalmazza a [Authorize] attribútumot (API-dokumentáció) az alkalmazás minden Razor összetevőjére az alábbi módszerek egy használatával:

• Az alkalmazás importálási fájljában adjon hozzá egy @using direktívát a Microsoft.AspNetCore.Authorization névtérhez az @attribute vonatkozó irányelvvel[Authorize].

  _Imports.razor:

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

  Engedélyezze a névtelen hozzáférést a Authentication összetevőhöz az identitásszolgáltatóhoz való átirányítás engedélyezéséhez. Adja hozzá a következő Razor kódot a Authentication összetevőhöz a @page irányelv értelmében.

  Authentication.razor:

  @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
  @attribute [AllowAnonymous]
  

• Adja hozzá az attribútumot minden Razor összetevőhöz a @page irányelvben:

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

Jegyzet

Az AuthorizationOptions.FallbackPolicy hozzáadása a RequireAuthenticatedUser házirendhez nem támogatott.

Alkalmazásonként egy identitásszolgáltatói alkalmazásregisztráció használata

A jelen áttekintési néhány cikke két vagy több alkalmazást tartalmazó Blazor üzemeltetési forgatókönyvekre vonatkozik. Az önálló Blazor WebAssembly-alkalmazások webes API-t használnak hitelesített felhasználókkal a kiszolgálóalkalmazás által biztosított kiszolgálói erőforrások és adatok eléréséhez.

Ha ezt a forgatókönyvet dokumentációs példákban implementálják, két identitásszolgáltatói regisztrációt használ, egyet az ügyfélalkalmazáshoz, egyet pedig a kiszolgálóalkalmazáshoz. Nem feltétlenül szükséges külön regisztrációkat használni, például a Microsoft Entra ID-ban. Két regisztráció használata azonban ajánlott biztonsági eljárás, mivel alkalmazásonként elkülöníti a regisztrációkat. A különálló regisztrációk használata lehetővé teszi az ügyfél- és kiszolgálóregisztrációk független konfigurálását is.

Jogkivonatok frissítése

Bár a frissítési jogkivonatok nem védhetők Blazor WebAssembly alkalmazásokban, akkor használhatók, ha megfelelő biztonsági stratégiákkal valósítja meg őket.

A .NET 6-os vagy újabb verziójában a ASP.NET Core-ban elérhető különálló Blazor WebAssembly-alkalmazásokhoz a következőket javasoljuk:

• Az OAuth 2.0 engedélyezési kód (Code) a Code Exchange (PKCE) ellenőrző kulcsával.
• Rövid lejáratú frissítési jogkivonat.
• Egy elforgatott frissítési jogkivonat.
• Egy frissítési jogkivonat, amely lejár, és amely után új interaktív engedélyezési folyamatra van szükség a felhasználó hitelesítő adatainak frissítéséhez.

További információ:

• Microsoft identity platform frissítő tokenek: Frissítő token élettartama
• OAuth 2.0 for Browser-Based Apps (IETF-specifikáció)

Jogcímek létrehozása felhasználók számára

Az alkalmazások gyakran igényelnek jogcímeket a felhasználók számára egy kiszolgálóra irányuló webes API-hívás alapján. A jogcímeket például gyakran használják az alkalmazások engedélyezési létrehozására. Ezekben az esetekben az alkalmazás hozzáférési jogkivonatot kér a szolgáltatás eléréséhez, és a jogkivonat használatával kéri le a felhasználói adatokat a jogcímek létrehozásához.

Példákért tekintse meg a következő erőforrásokat:

• További forgatókönyvek: A felhasználó testreszabása
• ASP.NET Core Blazor WebAssembly Microsoft Entra ID csoportokkal és szerepkörökkel

Előrenderelés támogatása

Az előzetes renderelés nem támogatott a hitelesítési végpontok (/authentication/ elérési utak szegmense) esetében.

További információ: ASP.NET Core Blazor WebAssembly további biztonsági forgatókönyvek.

Az Azure App Service a Linux-on a Identity szerverrel

Explicit módon adja meg a kiállítót, amikor az App Service-t linuxos Azure-on helyezi üzembe Identity Serverrel.

További információ: Az Identity használata webes API-háttérrendszer biztonságossá tételéhez az SLA-khoz.

Windows-hitelesítés

Nem javasoljuk a Windows-hitelesítés használatát Blazor Webassembly vagy bármely más SPA-keretrendszer használatával. Javasoljuk, hogy a Windows-hitelesítés helyett tokenalapú protokollokat használjon, például az Active Directory összevonási szolgáltatásokkal (ADFS) rendelkező OIDC-t.

Ha a Windows-hitelesítést Blazor Webassembly vagy bármely más SPA-keretrendszer használatával használják, további intézkedések szükségesek az alkalmazás helyközi hamisítási (CSRF-) jogkivonatokkal szembeni védelméhez. A cookie-kra vonatkozó aggodalmak a Windows-hitelesítésre is vonatkoznak, azzal a kiegészítéssel, hogy a Windows-hitelesítés nem nyújt olyan mechanizmust, amely megakadályozza a hitelesítési környezet forrásközi megosztását. A Windows-hitelesítést a CSRF-sel szembeni további védelem nélkül használó alkalmazásokat legalább a szervezet intranetére kell korlátozni, és nem szabad nyílt interneten használni.

További információkért lásd: Helyek közötti kérelemhamisítás (XSRF/CSRF) támadások megakadályozása az ASP.NET Core-ban.

SignalR hub rögzítése

Egy SignalR hub a kiszolgáló API-projektben való védelméhez alkalmazza a [Authorize] attribútumot a központi osztályra vagy a központi osztály módszereire.

Az előrerendereléssel rendelkező ügyfélprojektekben, például az üzemeltetett Blazor WebAssembly (ASP.NET Core a .NET 7-ben vagy korábbi verziókban) vagy egy Blazor Web App (ASP.NET Core a .NET 8-as vagy újabb verziójában), lásd az útmutatót a ASP.NET Core BlazorSignalRrészben.

Olyan ügyfélprojekt-komponensekben, amelyek előzetes renderelés nélküliek, mint például az önálló Blazor WebAssemblyvagy nem böngésző alkalmazások, adjon meg egy hozzáférési tokent a hub kapcsolathoz, ahogyan azt az alábbi példa is mutatja. További információ: Hitelesítés és engedélyezés ASP.NET Core SignalR.

@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject IAccessTokenProvider TokenProvider
@inject NavigationManager Navigation

...

var tokenResult = await TokenProvider.RequestAccessToken();

if (tokenResult.TryGetToken(out var token))
{
    hubConnection = new HubConnectionBuilder()
        .WithUrl(Navigation.ToAbsoluteUri("/chathub"), 
            options => { options.AccessTokenProvider = () => Task.FromResult(token?.Value); })
        .Build();

  ...
}

Fakitermelés

Ez a szakasz a .NET 7-es vagy újabb verziójában ASP.NET Core-ban Blazor WebAssembly alkalmazásokra vonatkozik.

A hibakeresési vagy nyomkövetési naplózás engedélyezéséhez tekintse meg a ASP.NET Core-naplózási Blazor WebAssembly cikk .NET 7-es vagy újabb verziójának Hitelesítési naplózás (Blazor) szakaszát.

A WebAssembly tesztkörnyezet

A WebAssembly tesztkörnyezet korlátozza a WebAssembly-kódot végrehajtó rendszer környezetéhez való hozzáférést, beleértve az I/O-alrendszerekhez, a rendszertárolókhoz és -erőforrásokhoz, valamint az operációs rendszerhez való hozzáférést. A WebAssembly-kód és a kódot végrehajtó rendszer elkülönítése biztonságos kódolási keretrendszerré teszi a WebAssemblyt a rendszerek számára. A WebAssembly azonban hardverszinten sebezhető az oldalcsatornás támadásokkal szemben. A hardverek beszerzésével kapcsolatos szokásos óvintézkedések és kellő gondosság, valamint a hardver elérésére vonatkozó korlátozások érvényesek.

WebAssembly nem a Microsoft tulajdonában vagy karbantartásában van.

További információ: W3C-erőforrások:

• WebAssembly: Biztonság
• WebAssembly specifikációja: Biztonsági megfontolások
• W3C WebAssembly közösségi csoport: Visszajelzés és problémák: A W3C WebAssembly közösségi csoport hivatkozás csak referenciaként érhető el, így egyértelművé válik, hogy a WebAssembly biztonsági réseit és hibáit folyamatosan javítják, gyakran a böngésző jelenti és kezeli. Ne küldjön visszajelzést vagy hibajelentést Blazor a W3C WebAssembly közösségi csoportnak.ABlazor visszajelzést a Microsoft ASP.NET Core termékegységnek kell jelenteni . Ha a Microsoft termékegysége megállapítja, hogy a WebAssemblyvel kapcsolatos alapvető probléma létezik, megteszik a megfelelő lépéseket a probléma W3C WebAssembly közösségi csoportnak való jelentéséhez.

Megvalósítási útmutató

A áttekintési című cikkek tájékoztatnak a felhasználók Blazor WebAssembly alkalmazásokban való hitelesítéséről adott szolgáltatók ellen.

Különálló Blazor WebAssembly alkalmazások:

• Általános útmutatás az OIDC-szolgáltatók és a WebAssembly hitelesítési könyvtár számára
• Microsoft-fiókok
• Microsoft Entra-azonosító (ME-ID)
• Azure Active Directory (AAD) B2C

További konfigurációs útmutató az alábbi cikkekben található:

• ASP.NET Core Blazor WebAssembly további biztonsági forgatókönyvek
• Graph API használata ASP.NET Core Blazor WebAssembly

Az engedélyezési kód folyamatának használata a PKCE-vel

A Microsoft identitásplatform Microsoft Authentication Library for JavaScript (MSAL) 2.0-s vagy újabb verziója támogatja az Engedélyezési kód folyamatot, a Proof Key for Code Exchange (PKCE)-t és a Cross-Origin Resource Sharing (CORS)-t egyoldalas alkalmazásokhoz, beleértve a Blazor.

Microsoft nem javasolja az Implicit grant használatát.

További információ:

• Hitelesítési folyamat támogatása az MSAL-ben: Implicit engedélyezési
• Microsoft-identitásplatform és implicit engedélyezési módszer: A hitelesítési kódfolyamat használatának előnyben részesítése
• Microsoft identity platform és az OAuth 2.0 engedélyezési kódfolyamat

További erőforrások

• A Microsoft identitásplatform dokumentációja
  • Általános dokumentáció
  • Hozzáférési jogkivonatok
• Az ASP.NET Core konfigurálása a proxykiszolgálókkal és terheléselosztókkal való együttműködéshez
  • A Továbbított fejlécek köztes szoftver használata a HTTPS-séma információinak megőrzéséhez proxykiszolgálókon és belső hálózatokon.
  • További forgatókönyvek és használati esetek, beleértve a manuális sémakonfigurációt, a kérelem útvonalának változásait a megfelelő kérés-útválasztáshoz, valamint a kérelemséma továbbítása Linux és nem IIS fordított proxyk esetében.
• Előrenyomtatás hitelesítéssel
• WebAssembly: Biztonság
• WebAssembly specifikációja: Biztonsági megfontolások