Integra l'autenticazione immersiva

Documentation

Un'applicazione può utilizzare Schermate di login RestFrontage per autenticare i propri utenti, applicare MFA e recuperare un token utilizzabile con WebAPI e OData. Non deve riprodurre password, codice QR o schermate di inserimento TOTP.

Questa guida offre due progetti completi: un Applicazione WPF per Windows e un Applicazione web basata su JavaScript, ospitato da un piccolo progetto ASP.NET Core. Nessuno dei due fa riferimento a GraphicStream.Immersive.Server.Interop o ad altre DLL Immersive. Il futuro pacchetto di autenticazione indipendente non è obbligatorio per usarli.

Le illustrazioni sono screenshot degli esempi e del login RestFrontage in un ambiente di test isolato. Gli account mostrati sono account demo. Le porte e gli ID delle catture provengono dal banco di test; usa i valori dalla tua configurazione.

In questo articolo

    Mostra altro
    Mostra meno

    1. Comprendere il principio

    1.1 Un'interfaccia di connessione comune

    L'utente clicca Accedi nella tua applicazione. Il browser mostra l'accesso Immersive. Inserisce il suo nome utente e la password, poi il codice MFA quando richiesto dalla policy del server. Se la verifica deve essere configurata, il server gli mostra il codice QR e gli chiede di confermare un primo codice.

    L'applicazione riceve quindi automaticamente un token. Questo token le permette di chiamare le API con i diritti dell'utente effettuato l'accesso. Una connessione di successo non concede loro diritti aggiuntivi.

    MFA segue l'impostazione già impostata in Immersive: disabilitata, richiesta con esenzioni o obbligatoria per tutti gli utenti interessati. L'applicazione client non sceglie di aggirare questa politica.

    Login ospitato su RestFrontage: Il nome dell'applicazione accompagna l'inserimento delle credenziali

    1.2 Due codici che hanno ruoli diversi

    Il Codice TOTP è il codice a sei cifre mostrato dall'app del telefono. Viene usato per confermare l'identità dopo la password. Di solito cambia ogni 30 secondi ed è calcolato senza internet.

    Il Codice di ritorno è un codice tecnico, generato dal server dopo l'accesso. Viene automaticamente trasmesso all'applicazione, che lo scambia con il token. L'utente non deve mai copiarlo, conservarlo o trasmetterlo a un amministratore. Questo codice scade dopo 60 secondi E funziona solo una volta.

    Login del server con il check-in TOTP, prima di tornare all'applicazione

    1.3 Il viaggio completo

    sequenceDiagram
        participant A as Votre application
        participant N as Navigateur
        participant R as RestFrontage
        A->>A: Préparer state et une preuve PKCE
        A->>N: Ouvrir Browser/Authorize
        N->>R: Demander la connexion pour l'application déclarée
        R-->>N: Afficher le login Immersive
        N->>R: Saisir identifiant et mot de passe
        opt MFA requise
            R-->>N: QR code si inscription nécessaire, puis saisie TOTP
            N->>R: Confirmer un code à six chiffres
        end
        R-->>N: Rediriger vers le callback avec un code temporaire
        N-->>A: Transmettre code, state et iss
        A->>A: Vérifier le retour attendu
        A->>R: Browser/Token avec le code et la preuve PKCE
        R-->>A: Token Immersive et durée restante
        A->>R: WebAPI ou OData avec Authorization: Bearer
        R-->>A: Réponse autorisée selon les droits du compte
    

    Protezione PKCE S256 collega lo scambio di codici all'applicazione che ha avviato la connessione. L'applicazione mantiene un valore casuale privato, il code_verifier, e inizialmente trasmetteva solo la sua impronta digitale, il code_challenge. Intercettare il solo codice di ritorno quindi non è sufficiente per ottenere il token. Questo meccanismo è descritto da RFC 7636.

    state Collega il ritorno alla richiesta di connessione corrente. iss Identifica il server che sta rispondendo. I client forniti verificano questi valori e l'indirizzo di ritorno prima dello scambio.

    2. Prepara i due esempi

    2.1 Contenuto del file fornito

    Open Campioni/Immersive.Authentication.Samples.slnx in Visual Studio. La soluzione contiene esattamente due progetti indipendenti.

    Progetto Funzione Annessi
    Immersive.Authentication.Wpf eseguibile per Windows; offre il browser esterno o una finestra integrata in WebView2, e poi chiama un'API. .NET 10 per Windows, WPF e il pacchetto Microsoft.Web.WebView2. Niente DLL immersive.
    Immersive.Authentication.Web applicazione JavaScript; reindirizza la scheda a Immersive e poi riscatta il codice al ritorno. .NET 10/ASP.NET Core per servire file. JavaScript può anche essere ospitato da un altro server web.

    Il dossier Eseguibili/WPF, nell'archivio di consegna, contiene l'eseguibile pubblicato e la sua configurazione. Questa release richiede il Runtime desktop .NET 10 x64 e, per la modalità integrata, la Microsoft Edge WebView runtime2. Tieni insieme tutti i file pubblicati, incluso il caricatore WebView2.

    Per compilare le sorgenti, utilizzare l'SDK .NET 10 e, in Visual Studio, i componenti di sviluppo Desktop .NET e ASP.NET/Web. Entrambi i progetti possono essere staccati dal repository server: puoi copiare la cartella Samples su un altro computer.

    2.2 Dichiara le app su RestFrontage

    Aggiungi questa sezione alla configurazione dell'istanza di RestFrontage, sostituendo gli indirizzi in base al tuo ambiente. Il appsettings.example.json contiene lo stesso esempio. Non sovrascrive la tua configurazione esistente.

    {
      "BrowserAuthentication": {
        "Issuer": "https://localhost:44333",
        "Clients": [
          {
            "ClientId": "immersive-desktop",
            "DisplayName": "Exemple Immersive WPF",
            "RedirectUris": [ "http://127.0.0.1/callback/" ],
            "AllowLoopbackRedirect": true
          },
          {
            "ClientId": "immersive-web",
            "DisplayName": "Exemple Immersive Web",
            "RedirectUris": [ "https://localhost:5173/auth/callback" ]
          }
        ]
      }
    }
    
    

    Emittente è l'origine HTTPS di RestFrontage quando il browser vi accede: schema, host e opzionalmente port, senza path o barra finale. Questo percorso attende un server montato alla radice di questa origine. Se viene utilizzato un reverse proxy, il server deve ricevere lo schema esterno corretto e l'host tramite la sua configurazione affidabile.

    ClientId identifica la domanda e non è un segreto. DisplayName è il suo nome visualizzato nell'accesso. Dichiara solo le applicazioni autorizzate a utilizzare i diritti dei loro utenti. Per questi esempi nessun segreto condiviso dovrebbe essere incorporato in un binario o in JavaScript.

    RedirectUris Elenca gli indirizzi di ritorno esatti. Non vengono accettati wildcard, parametri di richiesta o frammenti. Ogni indirizzo web utilizza HTTPS. AllowLoopbackRedirect Permette solo al client nativo di scegliere una porta libera sull'indirizzo locale del loop dichiarato. L'host letterale e il percorso rimangono controllati. Con l'esempio WPF, il ritorno diventa ad esempio http://127.0.0.1:54321/callback/.

    Per mettere in pausa un'app, aggiungi "Enabled": false alla sua dichiarazione. Un ingresso assente o disabile non può utilizzare questo percorso.

    2.3 Controlla HTTPS e l'accesso alla rete

    RestFrontage deve essere raggiungibile per estensione e possedere un certificato riconosciuto. Il progetto web utilizza anche HTTPS. Per i test locali ASP.NET Core, se necessario, installa il certificato di sviluppo affidabile con:

    dotnet dev-certs https --trust
    
    

    Le applicazioni fornite non disabilitano la validazione dei certificati. Per una rete interna, si utilizza un certificato riconosciuto dai dispositivi rilevanti.

    Per il progetto web, RestFrontage deve permettere, ad esempio, chiamate dall'origine dell'applicazione https://localhost:5173, nella sua politica CORS. In particolare, la richiesta WebAPI deve essere in grado di inviare il Authorization. L'autorizzazione CORS non sovrascrive la dichiarazione di callback. Le chiamate WPF non dipendono dal CORS.

    La connessione funziona senza Internet se l'estensione raggiunge RestFrontage e qualsiasi applicazione Web sulla rete interna. Le risorse negli esempi sono locali. Il telefono calcola il suo codice TOTP offline; le impostazioni di data e ora devono rimanere corrette.

    3. Usa il campione WPF

    3.1 Lancio e collegamento

    Nel progetto Immersive.Authentication.Wpf, il appsettings.json Imposta i valori iniziali:

    {
      "Server": "https://localhost:44333",
      "ClientId": "immersive-desktop",
      "BrowserMode": "External",
      "ApiPath": "/api/Security/Mfa/Context"
    }
    
    

    Dalla cartella Esempi, esegui:

    dotnet run --project Immersive.Authentication.Wpf
    
    

    Puoi anche correre Immersive.Authentication.Wpf.exe dalla cartella pubblicata, oppure impostare questo progetto come progetto di avvio in Visual Studio.

    Applicazione WPF: Configurazione del server, login nel browser e chiamata WebAPI
    1. Controlla l'indirizzo RestFrontage e l'ID della domanda.
    2. Scegli Browser esterno oppure Browser integrato (WebView2), poi clicca Accedi.
    3. Inserire la password completa e, se richiesto, verificare la MFA.
    4. In modalità esterna, torna al WPF. In modalità integrata, la finestra di accesso si chiude automaticamente.
    5. Click Chiama GET. La rotta proposta restituisce il nome dell'account collegato.

    Dopo una connessione riuscita, il WPF mostra la data di scadenza del token. La chiamata proposta ritorna HTTP 200 e il nome dell'account collegato.

    Applicazione WPF dopo login integrato: token ricevuto e chiamata WebAPI riuscita

    In esterno, il ritorno utilizza un ascolto temporaneo di rete, limitato a 127.0.0.1, su una porta scelta automaticamente. Questo ascolto inizia prima che il browser venga aperto e si interrompe alla fine del viaggio. Il tempo massimo di connessione è di dieci minuti. Il Cancella Pausa l'attesa nell'app. Non chiude la scheda del browser.

    3.2 Scegli il browser

    Entrambe le scelte usano lo stesso server, lo stesso ClientId, e gli stessi controlli di ritorno e PKCE. La MFA è ancora applicata da Immersive. Non è necessario dichiarare un'applicazione aggiuntiva per passare tra di essi.

    Moda Cosa vede l'utente Elaborazione dei resi
    Browser esterno Il browser di sistema apre l'accesso. L'utente poi torna al WPF. Questa è la scelta predefinita. Ascolto temporaneo su 127.0.0.1, con un porting gratuito.
    Browser integrato (WebView2) Una finestra appartenente al WPF mostra l'accesso. Si chiude automaticamente dopo l'accesso. Il WPF intercetta la navigazione verso http://127.0.0.1/callback/ prima che venga caricata e poi scambia il codice. Non vengono aperti ascoltatori di rete locali.

    Adattamento BrowserMode in appsettings.json sceglie il valore iniziale: Esterno oppure Embedded. La lista ti permette di cambiare modalità per la connessione successiva; non riscrive il file di configurazione.

    Login immersivo visualizzato nella finestra di WebView2 dell'applicazione WPF

    La finestra integrata mostra l'origine del server sopra il login. Mantiene i passaggi usuali, incluso l'inserimento del codice a sei cifre e la registrazione con un codice QR quando il server lo richiede. Cancella, il cross di chiusura, o timeout, interrompe la connessione e restituisce il WPF al WPF.

    Verifica MFA nella finestra integrata prima di recuperare il token

    Il profilo WebView2 è privato e separato dal consueto profilo browser. Il salvataggio della password e il completamento automatico sono disabilitati. La navigazione fuori dal server configurato, nuove finestre, download e accesso agli oggetti nativi sono bloccati. Non vengono iniettati script di lettura delle credenziali dal campione. Gli errori di certificato non vengono ignorati.

    Il browser esterno rimane la scelta predefinita per isolare la pagina di autenticazione dell'applicazione. La variante integrata è adatta a un'applicazione masterizzata: il suo host può tecnicamente accedere ai contenuti web. Il PKCE protegge lo scambio di codice, ma non toglie questa capacità al programma che ospita WebView2. I principi per proteggere il componente sono descritti nel Documentazione Microsoft WebView2.

    3.3 Prepara le stazioni per WebView2

    Il progetto di riferimento WPF Microsoft.Web.WebView2. Questo pacchetto fornisce il controllo e il suo caricatore; il Microsoft Edge WebView runtime2 Deve essere presente sul computer per la modalità integrata. La sua presenza è separata da quella del browser Edge. Se manca l'runtime, il campione mostra un messaggio e permette di scegliere il browser esterno.

    Per una posizione senza Internet, pianifica ilInstallatore Evergreen Standalone l'architettura appropriata nel tuo processo di implementazione. Il piccolo bootstrapper web richiede un download ed è adatto a un'installazione completamente offline. La connessione può comunque funzionare sulla rete interna una volta installata la runtime. Visualizza Distribuire WebView2.

    Il file tecnico del componente viene creato sotto %LOCALAPPDATA%/Immersive.Authentication.Sample/WebView2, in una posizione accessibile dall'utente. Il profilo di accesso si apre in modalità privata. L'app conserva il token Immersive in memoria in entrambe le modalità.

    3.4 Riutilizza il codice nella tua app

    Il BrowserAuthenticationClient.cs contiene il client standalone. Utilizza le librerie standard .NET per preparare la richiesta, aprire il browser, controllare il ritorno e scambiare il codice. Non dipende dall'Immersive SDK.

    using Immersive.Authentication.Wpf;
    
    using var http = new HttpClient(new HttpClientHandler
    {
        AllowAutoRedirect = false,
        UseCookies = false
    });
    
    var authentication = new BrowserAuthenticationClient(
        "https://localhost:44333", http);
    
    var session = await authentication.SignInAsync(
        "immersive-desktop", cancellationToken);
    
    // session.Token : token Immersive à garder en mémoire.
    // session.ExpiresAt : échéance du token.
    
    

    MainWindow.xaml.cs mostra il pulsante connetti, la cancellazione, lo stato della sessione e la chiamata API. Puoi cambiare il namespace del file standalone quando lo integri nel tuo progetto.

    Per la modalità integrata, i file EmbeddedLoginWindow.xaml e EmbeddedLoginWindow.xaml.cs completare il client standalone. La chiamata viene effettuata dal thread UI WPF, con la finestra principale come proprietario:

    var session = await EmbeddedLoginWindow.SignInAsync(
        this, authentication, "immersive-desktop", cancellationToken);
    
    

    Il risultato ha le stesse proprietà Token e ExpiresAt. I controlli di callback e lo scambio HTTP rimangono attivi BrowserAuthenticationClient.cs ; La finestra si occupa solo di mostrare e intercettare la navigazione finale.

    Il metodo del browser esterno può ricevere una funzione openBrowser Se la tua app ha già il browser aperto in astrazione. Metodi CreateBrowserLoginRequest e CompleteBrowserLoginAsync Ti permettono di gestire separatamente l'inizio e il ritorno se hai già un meccanismo di callback compatibile.

    Il browser di sistema mantiene l'inserimento delle credenziali nella pagina server. Questa scelta segue il principio raccomandato per applicazioni native dal RFC 8252. Un iframe non è una modalità di integrazione di questo login.

    4. Usa il Campione Web

    4.1 Lancio del sito

    Il appsettings.json del progetto Immersive.Authentication.Web Contiene:

    {
      "Authentication": {
        "Server": "https://localhost:44333",
        "ClientId": "immersive-web",
        "ApiPath": "/api/Security/Mfa/Context"
      }
    }
    
    

    Dai campioni:

    dotnet run --project Immersive.Authentication.Web
    
    

    Open https://localhost:5173. In Visual Studio, il profilo di avvio apre automaticamente questo indirizzo. La rotta di ritorno è https://localhost:5173/auth/callback ; deve essere dichiarata esattamente come tale in RestFrontage.

    App web autonoma prima del login
    1. Click Accedi : La scheda viene reindirizzata a RestFrontage.
    2. Inserisci le tue credenziali, poi il codice MFA se necessario.
    3. Il server reindirizza la scheda a /auth/callback nella tua app.
    4. JavaScript verifica il ritorno e scambia il codice con il token.
    5. Click Chiama GET per leggere il contesto del racconto.
    Di nuovo nell'applicazione web: Token ricevuto e risposta autenticata dall'API

    Lo stesso esempio web adatta il suo layout a piccoli schermi. Il percorso di accesso e l'uso del token rimangono gli stessi.

    Esempio web per small-screen: login completato e risposta API autenticata

    4.2 Riutilizzare il modulo JavaScript

    I fascicoli wwwroot/ImmersiveAuthentication.js e wwwroot/app.js mostra rispettivamente il client di connessione e la sua integrazione nella pagina. Il piccolo server ASP.NET Core serve queste risorse e la configurazione pubblica. Non riceve il token: il browser chiama direttamente RestFrontage.

    import { ImmersiveAuthentication } from "/ImmersiveAuthentication.js";
    
    const authentication = new ImmersiveAuthentication({
        Server: "https://localhost:44333",
        ClientId: "immersive-web",
        RedirectUri: location.origin + "/auth/callback"
    });
    
    // Dans l'action « Se connecter » :
    await authentication.SignIn();
    
    

    Nella pagina di reso, ricrea il cliente con le stesse opzioni, e poi chiama:

    const session = await authentication.CompleteSignIn();
    // session.Token : token Immersive.
    // session.ExpiresIn : durée restante, en secondes.
    
    

    Il modulo mantiene solo la transazione provvisoria PKCE in sessionStorage durante la modifica della pagina. Cancella questa transazione dopo la validazione e rimuove il codice dall'indirizzo del browser. Il token non è scritto su localStorage, sessionStorage o cookie.

    Il ritorno deve avvenire nella stessa scheda e sulla stessa origine dell'applicazione che ha avviato la richiesta. Il percorso /auth/callback deve essere accessibile direttamente dal tuo hosting, anche prima che JavaScript venga caricato. Nell'esempio, il server restituisce index.html per questa strada.

    Per l'alloggio, mantieni Referrer-Policy: no-referrer Nella pagina di ritorno, evita risorse di terze parti su quella pagina e non registrare i parametri URL del D. Una configurazione proxy o di hosting dovrebbe preservare queste proprietà.

    5. Chiamate WebAPI e OData

    5.1 Lo stesso gettone indipendentemente dal cliente

    Una volta completata la connessione, entrambe le applicazioni utilizzano lo stesso tipo di token Immersive. Aggiungono l'intestazione Autorizzazione: Titolare alle loro richieste. Ecco la stessa operazione in C#, JavaScript e HTTP; server si riferisce all'origine di RestFrontage e token il gettone ottenuto.

    Una risposta di successo contiene AccountName. Per OData, cambia il percorso verso una rotta OData della tua istanza: l'intestazione rimane la stessa. Gli esempi fanno solo richieste GET. Impediscono che il token venga inviato a un altro server tramite il campo path e negano i reindirizzamenti HTTP sulle chiamate autenticate.

    A 401 significa che la richiesta non è autenticata o che il token non viene più accettato; Ripeti la connessione. A 403 Indica un diniego di accesso: Controlla i diritti e le regole dell'API pertinente. Passare MFA non dà accesso a tutte le risorse.

    5.2 Scadenza e fine della sessione

    Il token mantiene il suo solito periodo di validità in Immersive. La risposta dell'exchange indica il suo Tempo rimanente. I campioni smettono di usarlo quando scade; è quindi necessaria una nuova connessione. Questo percorso non fornisce un token di refresh.

    Cancella la mia sessione rimuove il token dalla memoria del campione. Questo pulsante non revoca il token già emesso al server né disconnette tutte le altre applicazioni. Chiudere l'eseguibile WPF o ricaricare la scheda Web cancella anche lo stato della connessione.

    I progetti mostrano volontariamente una sessione in memoria. Un'applicazione che vuole mantenere una sessione più a lungo deve definire esplicitamente la propria politica di archiviazione e logout. Per un sito con backend, è possibile mantenere il token esclusivamente lato server.

    6. Comprendere il contratto HTTP

    6.1 Avvio della connessione

    L'applicazione prepara valori casuali state e code_verifier. I client forniti utilizzano 32 byte casuali codificati in Base64URL, senza alcun riempimento. La sfida è BASE64URL(SHA256(ASCII(code_verifier))).

    Poi apre questo indirizzo nel browser, codificando i valori dei parametri:

    GET {{server}}/api/Security/Browser/Authorize?response_type=code&client_id={{clientId}}&redirect_uri={{redirectUriEncoded}}&state={{state}}&code_challenge={{challenge}}&code_challenge_method=S256
    
    

    Non iniziare l'integrazione aprendo direttamente /Login : l'ingresso Browser/Autorizza Contiene le informazioni della domanda e il ritorno atteso. La richiesta di connessione è valida per dieci minuti.

    Dopo il successo, il server reindirizza al callback dichiarato con Codice, Stato e ISS. Dopo aver cancellato dal login, torna errore=access_denied, Stato e ISS. Una richiesta iniziale non valida rimane su un errore locale: non reindirizza a un indirizzo non autorizzato.

    6.2 Codice di riscatto

    Dopo aver controllato il callback, state e iss, l'applicazione passa un modulo HTTP. I valori sono codificati come un modulo, senza conversione in JSON.

    La risposta contiene:

    {
      "access_token": "JWT Immersive",
      "token_type": "Bearer",
      "expires_in": 3600
    }
    
    

    La durata è illustrativa. Questi tre nomi seguono il contratto OAuth, in minuscole. Il client WPF espone Token e ExpiresAt, e il modulo JavaScript esposto Token e ExpiresIn. Le altre Immersive WebAPI mantengono la loro convenzione PascalCase.

    Strade Browser/VerifyCredentials, Browser/VerifyTotp e Browser/Annulla. fanno parte del funzionamento interno dell'interfaccia ospitata. La tua integrazione utilizza Autorizzare e Gettone ; Non deve controllare i passaggi di accesso.

    7. Altri mezzi di integrazione

    WPF e JavaScript non sono le uniche opzioni. Il contratto è HTTP: entrambi i progetti mostrano due modi di utilizzarlo, non una restrizione tecnologica.

    Integrazione Dove si trova il token? Compatibilità attuale
    WPF, WinForms, strumento desktop o console interattiva Nel processo, nella memoria. Attraversamento esterno del browser con callback a loop locale. WPF fornisce anche una finestra WebView2; adattarla a un altro framework richiede il controllo del browser.
    React, Vue, Angular, JavaScript o altre applicazioni in esecuzione nel browser In memoria nella scheda. Il modulo JavaScript può essere integrato nel framework scelto. Dichiarare una vera route di callback HTTPS e configurare il CORS.
    Sito con backend: ASP.NET, PHP, Java, Node.js... In sessione sul lato backend. Il backend può preparare PKCE, ricevere il callback HTTPS e scambiare il codice. Il browser riceve solo un cookie di sessione site-specific. Questa guida descrive il principio; non fornisce una terza bozza.
    Mobile App Nel processo di stoccaggio protetto della piattaforma secondo il suo progetto. Il principio del browser rimane applicabile. I collegamenti HTTPS associati all'applicazione richiedono integrazione con la piattaforma. Schemi privati come monapp:// non sono accettati dal server attuale. Non sono forniti esempi mobili qui.
    Interfaccia di connessione completamente personalizzata Nell'applicazione che chiama direttamente le API MFA. Le API MFA esistenti consentono questo percorso, ma l'applicazione deve gestire credenziali, iscrizione, codici ed errori. L'interfaccia ospitata evita questa duplicazione.
    Servizio, automazione o attività programmata senza un utente Il segreto dell'applicazione è mantenuto nella sua configurazione protetta. Usa una chiave API. Un login interattivo MFA non è adatto per giocare senza persone.

    7.1 Variante web con backend

    In questa variante, il backend mantiene state e la prova PKCE nella sessione utente prima del redirect. Controlla il callback e poi scambia il codice lato server. Poi conserva il token Immersive e effettua le chiamate API per il browser.

    sequenceDiagram
        participant N as Navigateur
        participant B as Backend de votre site
        participant R as RestFrontage
        N->>B: Se connecter
        B->>B: Stocker state et PKCE dans la session
        B-->>N: Redirection vers le login hébergé
        N->>R: Mot de passe et MFA éventuelle
        R-->>N: Redirection vers le callback du site
        N->>B: Callback avec code et state
        B->>B: Vérifier session, state et iss
        B->>R: Échanger code et PKCE
        R-->>B: Token Immersive
        B-->>N: Session du site, cookie sécurisé HttpOnly
        N->>B: Demander une ressource
        B->>R: Appeler l'API avec le token
        R-->>B: Résultat autorisé
        B-->>N: Résultat pour l'interface
    

    In particolare, il cookie di sessione deve essere sicuro, solo Http e adatto per la navigazione dei feedback. Proteggere le azioni del sito contro richieste cross-site. Il token rimane nel backend; non deve essere inviato al browser tramite una utility route. PKCE e state rimane necessario in questa variante.

    8. Ambito e diagnosi

    8.1 Cosa tratta questo corso

    Le coperture del tour ospitato nome utente/password e TOTP, con le esenzioni, la prima registrazione e la riregistrazione autorizzata previste in Immersive. Non collega ancora i fornitori SSO esistenti a questa voce; la loro operatività rimane distinta.

    Il server utilizza il Codice di autorizzazione con PKCE, ma non è rappresentato come un provider completo OpenID Connect. Questo lotto non fornisce la scoperta OIDC, il token ID, il consenso tramite ambiti, il token di aggiornamento o il Flusso di Autorizzazione del Dispositivi. Un componente che richiede queste funzioni non può essere collegato senza adattamento.

    Per più istanze di RestFrontage, l'operatore deve mantenere un keyring persistente condiviso di Protezione dei Dati, la stessa identità di applicazione Data Protection e lo stesso database di Sicurezza. Le chiavi JWT e le impostazioni MFA devono anch'esse essere coerenti. La perdita delle protezioni temporanee richiede che le connessioni attuali vengano riavviate.

    8.2 Correggere gli errori comuni

    Sintomo Verifica
    Richiesta di connessione invalida all'apertura Controlla l'emittente, il ClientId abilitato, la corrispondenza esatta del callback e S256.
    Il browser rifiuta HTTPS Controlla i certificati di RestFrontage e del sito web, il loro nome e il trust dell'estensione.
    L'accesso ha successo ma il ritorno web fallisce Controlla la via /auth/callback, la stessa scheda, sessionStorage, le origini CORS e il nome pubblico del server.
    Il browser integrato non si avvia Controlla l'runtime di WebView2 e i diritti sulla sua cartella dati. Scegli il browser esterno se necessario.
    Il browser integrato rifiuta il server Controlla il tuo certificato HTTPS e l'origine configurata. La navigazione verso un altro dominio è bloccata.
    La finestra WPF attende dopo l'accesso Controlla il ritorno a 127.0.0.1 e la porta temporanea, le regole locali dell'estensione, e poi ricomincia se l'attesa è stata annullata.
    invalid_grant durante lo scambio Il codice può essere scaduto, già in uso, collegato a un'altra prova o invalidato da un cambiamento di account o politica. Ricomincia da Accedi.
    L'API restituisce 401 o 403 Controlla la validità del token e i diritti dell'account per la transazione in questione.
    La connessione scompare dopo un ricaricamento web Questo è il comportamento di questo esempio: il token rimane solo in memoria.

    Non registrare token, prove PKCE, password, segreti TOTP o impostazioni di callback. Questo vale anche per IIS, reverse proxy, e log delle applicazioni client. Le migliori pratiche generali sono dettagliate nel RFC 9700.

    8.3 Verifica la tua integrazione

    Prova un account soggetto a MFA, un account che deve essere configurato per la prima volta e, se la tua politica lo permette, un account esente. Controlla anche se cancellazioni, errori TOTP e accesso all'API negato per mancanza di diritti.

    Il risultato atteso è sempre lo stesso: La tua applicazione recupera un token solo dopo i passaggi di connessione richiesti dal server. Possono quindi utilizzare le API entro i limiti dei diritti dell'account.