Che cos'è l'autenticazione API?

L'autenticazione aiuta a garantire che gli utenti autorizzati possano accedere alle risorse di cui hanno bisogno, proteggendo i dati sensibili e mantenendo la sicurezza delle API.

Le application programming interface (API) sono pilastri chiave degli ecosistema IT moderni, permettendo ad applicazione, database, dispositivi e altri componente IT di scambiare dati tra architetture, ambienti e protocolli. Le API sono ora il modo principale in cui le organizzazioni integrano i servizi e automatizzano i workflow, con l'82% delle organizzazioni che adotta almeno in qualche misura una Strategia API-first, secondo Postman. Ma le organizzazioni spesso faticano a mantenere sicurezza e visibilità su queste connessioni complesse.

Se da un lato gli ecosistemi IT basati su API aiutano le aziende a migliorare l'agilità, la scalabilità e l'efficienza, dall'altro possono esporre le organizzazioni a attacchi informatici, violazioni dei dati e altre vulnerabilità di sicurezza. Una solida autenticazione API, insieme ad altre tecniche di gestione delle identità e degli accessi (IAM), può aiutare le organizzazioni a trarre beneficio dall'Integrazione proteggendo al contempo dalle minacce alla sicurezza.

L'autenticazione API è particolarmente importante per le aziende più grandi, le cui piattaforme di integrazione delle applicazioni aziendali (EAI), che abilitano la gestione delle relazioni con i clienti (CRM), la pianificazione delle risorse aziendali (ERP) e altri sistemi aziendali critici di comunicare nonostante differenze architettoniche e di dati, possono includere centinaia o migliaia di componenti e servizi di integrazione. Secondo uno studio di Zylo del 2025, le aziende con almeno 10.000 dipendenti utilizzano in media 660 applicazioni SaaS. 

Con servizi sparsi in ambienti on-premise, ibridi e multi-cloud, molte aziende si stanno rivolgendo a metodi di autenticazione avanzati, come token, passkey, autenticazione adattiva a più fattori (MFA) e altre tecniche basate sulla crittografia. Questi approcci possono offrire molteplici livelli di protezione e un livello di controllo più profondo rispetto alle tecniche tradizionali.

L'autenticazione può essere utilizzata per aiutare a proteggere molti tipi di interazioni basate su API, incluse comunicazioni tra microservizi, scambi di dati tramite un API Gateway e single sign-on (SSO) e MFA per applicazioni.

Circa il 99% delle organizzazioni riferisce di incontrare problemi di sicurezza delle API, con problemi di autenticazione che rappresentano il 29% degli incidenti, secondo il report State of API Security 2025 di Salt Lab. Le sfide di sicurezza possono sorgere a causa di pratiche di minimo privilegio, storage segreta non sicura e gestione disomogenea delle sessioni (quando le revoche, le scadenze e gli aggiornamenti delle sessioni sono distribuite in modo incoerente all'interno di un'organizzazione), tra gli altri problemi.

Le organizzazioni possono rafforzare i propri sistemi di autenticazione API implementando la gestione dei token e degli accessi privilegiati, mantenendo una supervisione centralizzata e utilizzando solo librerie software affidabili e ben mantenute, insieme ad altre best practice.

Sia l'autenticazione che l'autorizzazione sono parti fondamentali della strategia IAM di un'organizzazione, ma svolgono ruoli distinti. L'autenticazione API verifica l'identità di un utente tramite credenziali utente, token di accesso e altre tecniche crittografiche.

L'autorizzazione API, invece, determina se un utente o un servizio ha il permesso di effettuare una particolare richiesta API. Ad esempio, un team leader interno potrebbe avere accesso a una gamma più ampia di servizi rispetto a un contractor terzo o a un agente basato sull'AI assegnato a un compito specifico.

Un modo per pensare alla differenza tra autenticazione e autorizzazione: quando un utente inserisce una password in una pagina di login, questo processo è una semplice forma di autenticazione. L'autorizzazione è ciò che determina a quali servizi l'utente può accedere dopo aver effettuato il login. In molte configurazioni, l'autenticazione avviene per prima, con i server di autorizzazione che restituiscono un token di accesso solo dopo aver verificato l'identità del client o dell'utente.

L'autenticazione API funziona in modo diverso a seconda del framework utilizzato da un'organizzazione. Alcuni approcci sono ideali per gestire l'accesso interno alle API, ad esempio nelle configurazioni service mesh, mentre altri sono più adatti per sistemi API rivolti all'esterno.

Le organizzazioni possono considerare la loro infrastruttura attuale, i requisiti di conformità e le esigenze degli sviluppatori, oltre ad altri fattori come le configurazioni future, nel determinare quale framework di autenticazione adottare. Molte imprese utilizzano una combinazione di tecniche di autenticazione per adattarsi a diversi casi d'uso. I meccanismi di autenticazione comuni includono:

Introdotta e formalizzata negli anni '90, l'autenticazione di base è un approccio di autenticazione relativamente semplice che verifica l'identità dell'utente utilizzando HTTP come meccanismo di trasporto.

Funziona così: innanzitutto, il client fornisce un nome utente e una password nell'intestazione di autorizzazione di una richiesta HTTP. Queste credenziali sono codificate con lo schema Base64 in modo che possano essere trasportate correttamente (gli strumenti a riga di comando, come cURL, HTTPie o Aria2, vengono spesso utilizzati per automatizzare questo processo).

Successivamente, il server API decodifica l'intestazione HTTP e la confronta con un elenco di credenziali approvate, che di solito vengono memorizzate come valori hash. Se c'è una corrispondenza, il server concede l'accesso all'endpoint protetto o soddisfa la richiesta API. 

Poiché Base64 non offre sicurezza, l'autenticazione di base si basa sulla sicurezza del livello di trasporto (TLS), in particolare sul protocollo HTTPS, per criptare le chiamate API. Una variante più avanzata chiamata Mutual TLS (MTLS) richiede che sia il client che il server si scambino le credenziali. 

Tuttavia, nell'autenticazione di base, la sicurezza delle API è limitata perché le password non scadono o si aggiornano automaticamente e le credenziali devono essere inviate nuovamente per ogni richiesta API, aumentando i rischi di esposizione. Se una password viene compromessa, gli sviluppatori devono revocarla manualmente. Infine, le caratteristiche di autenticazione di base limitano il monitoraggio e i controlli di accesso integrati.

Nonostante i suoi limiti, l'autenticazione di base è spesso utilizzata in ambienti di test e sviluppo e può essere sufficiente per implementazioni interne a bassa sensibilità quando utilizzata tramite HTTPS. L'autenticazione di base è ampiamente supportata, semplice da configurare e completamente stateless, il che significa che i team IT non devono gestire lo storage dei token o le sessioni lato server.

I framework delle chiavi API utilizzano le chiavi API, stringhe di caratteri generati casualmente assegnate dal fornitore di API, invece di fare affidamento su nomi utente e password gestiti dall'utente. Questi identificatori univoci in genere corrispondono a una particolare applicazione o progetto, offrendo alle organizzazioni un controllo degli accessi dettagliato sui singoli servizi. Ad esempio, un team può applicare limiti di velocità ad una particolare applicazione del cliente o limitare l'accesso del cliente a determinati endpoint o ambienti di produzione.

Come l'autenticazione di base, le chiavi API sono spesso incluse nell'intestazione della richiesta di una chiamata API, sebbene possano anche essere incorporate nelle stringhe di query o nei cookie. Anche l'autenticazione con chiave API è stateless: una chiave API deve essere aggiunta ad ogni richiesta API, perché il server non memorizza lo stato della sessione per ogni richiesta.

Nei sistemi più grandi, la gestione delle chiavi API può diventare difficile, con i team IT che faticano a tenere il passo con le assegnazioni chiave. Ad esempio, se una chiave viene compromessa, il fornitore di API può identificare solo la chiave problematica (che potrebbe essere condivisa tra diversi utenti), rendendo difficile isolare la fonte della violazione. La risoluzione dei problemi può rivelarsi complessa anche per i progetti condivisi, poiché la revoca di una chiave API ha effetto su tutti coloro che la utilizzano.

Poiché il provider API gestisce ogni chiave API, può facilmente tracciare l'utilizzo e scartare le chiavi per revocare l'accesso se rileva una minaccia di cybersecurity o una violazione delle linee guida API. Il provider può anche applicare autorizzazioni a grana fine per controllare con precisione l'ambito di ciascuna chiave. Nei framework di autenticazione di base, invece, gli utenti creano le proprie password e i provider di API hanno una capacità limitata di monitorarle e gestirle. Infine, le organizzazioni possono applicare dei limiti tariffari a determinati progetti, migliorando le prestazioni in tutti i servizi.

L'autenticazione con chiave API è spesso la soluzione migliore per gli ambienti API pubblici perché consente ai fornitori di servizi di monitorare gli sviluppatori che utilizzano le loro API. Ad esempio, affinché un ristorante aggiunga un'integrazione con Google Maps al suo sito web, ha bisogno di una chiave API.

Questa configurazione consente a Google di monitorare l'utilizzo del ristorante e di addebitarlo per l'accesso ai servizi premium. Google Maps non è particolarmente preoccupato di nascondere i propri dati proprietari (i dati sono già disponibili pubblicamente) vuole solo un modo per tracciare chi li utilizza in modo da poterli misurare correttamente, un compito che l'autenticazione tramite chiave API può contribuire a svolgere.

Emerso nei primi anni 2000, il security assertion markup language (SAML) è un framework di autenticazione aperto basato su XML che consente il single sign-on (SSO), ovvero la possibilità di utilizzare un unico insieme di credenziali di accesso tra più applicazioni. Un'organizzazione potrebbe implementare l'SSO in modo che i dipendenti possano accedere alle risorse umane, alle buste paga e alle e-mail con un unico login.

Nell'autenticazione di base e nell'autenticazione con chiave API, il cliente invia le credenziali direttamente all'API. Il SAML introduce un passaggio aggiuntivo; utilizza un intermediario di terze parti chiamato identity provider (IdP) per autenticare gli utenti. 

Nei framework SAML, un utente che desidera accedere a un determinato servizio viene indirizzato a un IdP affidabile, come Google, Auth0 o OneLogin, che gestisce le autenticazioni per conto del fornitore del servizio (il proprietario del servizio a cui un cliente vuole accedere). Sia il fornitore di servizi che l'IdP possono scambiarsi un documento di metadati contenente gli ID delle entità (URI univoci) per distinguersi dagli altri server della rete e stabilire la fiducia. 

Il cliente invia le credenziali, che l'IdP utilizza per verificare l'identità dell'utente finale. Successivamente, l'IdP emette un token di sicurezza chiamato asserzione SAML, cioè un documento XML firmato che può includere tempo di accesso, titolo, ID dipendente e altri dati utente rilevanti, per dimostrare che l'utente è stato autenticato e per fornire contesto riguardo alla richiesta dell'utente. Il fornitore di servizi riceve l'asserzione, poi la utilizza per determinare quale livello di accesso concedere all'utente. 

Il processo può essere ripetuto su più servizi: se l'IdP mantiene la sessione con l'utente, può rispondere a un secondo o terzo servizio con la stessa asserzione SAML, garantendo che l'utente è già stato autenticato. Questo passaggio consente all'utente di accedere ai servizi connessi senza dover effettuare nuovamente il login.

I flussi di reindirizzamento basati su browser di SAML funzionano bene per le applicazioni web ma spesso portano a una scarsa esperienza utente nelle applicazioni mobili (OAuth 2.0 con OIDC è spesso preferito per le app mobili). Il linguaggio di markup XML è anche più prolizzo rispetto a JSON e altri equivalenti. Tuttavia, l'impatto sulle prestazioni è generalmente trascurabile negli scenari di autenticazione. Infine, gli attributi utente incorporati nelle asserzioni SAML non sono standardizzati e richiedono mappature personalizzate tra i sistemi.

Tuttavia, il SAML offre benefici di sicurezza, come registrazione e audit coerenti, tramite una gestione centralizzata dell'autenticazione (tramite l'IdP). Riduce inoltre il carico sui server API, poiché non è più necessario supportare la gestione dell'autenticazione. Infine, SAML è ampiamente supportato, altamente affidabile e adatto ai casi d'uso B2B.

OpenID Connect (OIDC) è un protocollo di autenticazione moderno che, come SAML, realizza l'autenticazione federata attraverso SSO. Tuttavia, OIDC è ottimizzato per applicazioni mobile, API-driven e applicazione cloud-native e si differenzia da SAML per diversi aspetti.

Le fasi iniziali sono simili: un utente cerca di accedere a un servizio, viene reindirizzato dall'applicazione a un fornitore di identità (IdP) per autenticarsi e poi torna all'applicazione con un token che prova la sua identità. 

Tuttavia, invece di asserzioni basate su XML, OIDC utilizza JSON Web Token (JWT) per i token ID, formattati come "header.payload.signature", per rappresentare le informazioni di autenticazione. Come le asserzioni, questi messaggi confermano a un fornitore di servizi che il client è stato autenticato. Poiché i JWT utilizzano JSON e sono più compatti rispetto alle asserzioni basate su XML, generalmente si adattano meglio alle moderne app mobili, alle API RESTful e alle applicazioni web cloud-native.

Quindi SAML e OIDC usano identificatori e concetti differenti per ottenere lo stesso risultato: mentre SAML utilizza ID di entità e asserzioni basate su XML, OIDC utilizza URL di emettere, stringhe di ID client e JWT basati su JSON/HTTP, rendendo OIDC più adatto a API RESTful e architetture di microservizio.

OIDC è uno strato identità che si sovrasta a un framework di autorizzazione chiamato OAuth 2.0 (talvolta chiamato OAuth2). OAuth 2.0 consente a un'applicazione client di ottenere token di accesso a ambito limitato e limitato nel tempo da chiamare su API protette e risorse ad accesso limitato per conto di un utente (umano o agente). OIDC aggiunge la verifica dell'identità alle funzioni di autorizzazione di OAuth definendo un ID token e endpoint correlati che verificano chi sta tentando di accedere alle risorse.

Ad esempio, un team di sviluppo potrebbe utilizzare una piattaforma di integrazione continua e distribuzione continua (CI/CD) per automatizzare le proprie implementazioni su GitHub. Con OAuth 2.0, il team di sviluppo può concedere al servizio CI/CD il permesso di accedere ai progetti GitHub pertinenti per suo conto. Il team può anche specificare quali repository GitHub desidera condividere e quali desidera mantenere privati.

Esistono scenari in cui un cliente potrebbe richiedere l'autorizzazione senza prima effettuare l'autenticazione utente, come in molti scambi di dati macchina a macchina. Ad esempio, un agente che invia log giornalieri a una piattaforma di monitoraggio centralizzata può svolgere in sicurezza questo compito senza sapere quale utente abbia avviato questa automazione.

Ma nei casi in cui il client deve non solo accedere a un server di terze parti ma anche verificare l'identità dell'utente, ad esempio, se il client deve presentare informazioni sicure all'utente, OAuth 2.0 da solo è insufficiente. OAuth 2.0 definisce solo standard e ruoli di autorizzazione e non può fornire autenticazione. Per colmare questa lacuna, OIDC agisce come un'estensione opzionale di OAuth 2.0, definendo ID token e endpoint standardizzati per le informazioni utente, così che i client possano verificare in modo sicuro l'identità dell'utente durante operazioni sensibili ai dati.

Insieme, OAuth 2.0 e OIDC possono migliorare l'esperienza dell'utente e aiutare a mantenere sicuri i sistemi API. Quando un dipendente accede a una piattaforma HR, ad esempio, potrebbe essere reindirizzato a un portale di accesso centralizzato abilitato OIDC, che funge da livello di autenticazione, per verificare sulla piattaforma HR che il dipendente sia chi dichiara di essere.

Dopo l'accesso, OAuth 2.0 consente alla piattaforma HR di ricevere token di accesso che le autorizzano a chiamare API sicure per conto dell'utente. Queste API possono quindi raccogliere i dati rilevanti dei dipendenti (come ID, titolo e data di inizio del dipendente) in modo che il dipendente non debba inserire manualmente questi dati ripetutamente.

L'OIDC potrebbe essere eccessivamente complesso per le implementazioni interne, richiedendo competenze di sviluppo e una lunga manutenzione, soprattutto nei settori altamente regolamentati, dove i complessi standard di conformità e governance complicano le implementazioni.

Tuttavia, per molte organizzazioni, OAuth 2.0 e OIDC offrono un equilibrio desiderabile tra sicurezza robusta e esperienza utente semplificata. I token di accesso sono tipicamente validi solo per pochi minuti, riducendo i rischi di sicurezza. Allo stesso tempo, i token di aggiornamento memorizzati in modo sicuro consentono agli utenti di rimanere connessi per settimane o mesi senza interruzioni.

Inoltre, i token OIDC sono autonomi e leggeri, rendendoli particolarmente adatti all'autenticazione delle interazioni macchina a macchina, così come a implementazioni cloud e mobile. 

Abbiamo già parlato di JWT nel contesto di OIDC, ma lo standard aperto ha anche un utilizzo più ampio al di fuori delle implementazioni SSO. Pur non essendo un framework di autenticazione autonomo, JWT può essere applicato ad approcci di autenticazione personalizzati, come l'autenticazione a microservizi, Internet of Things (IoT) e autenticazione API Gateway. 

Le trasmissioni JWT tipicamente contengono tre elementi:

• L'header descrive il tipo di token (in questo caso, JWT) e il suo algoritmo di firma.
  
  
• Il payload fornisce rivendicazioni, o dettagli sulla richiesta, compreso chi l'ha fatta e l'ambito dei suoi permessi.
  
  
• La firma utilizza una chiave crittografica per dimostrare che l'intestazione e il carico utile non hanno subito interferenze.

Sebbene il processo di scambio dei token funzioni in modo simile in tutti i casi d'uso, la parte emittente può cambiare a seconda dell'architettura API dell'organizzazione. Le organizzazioni possono utilizzare un IdP, un server di autorizzazione, servizi cloud o servizi backend personalizzati per l'autenticazione.

Ad esempio, nell'autorizzazione API gateway, un server di autorizzazione potrebbe verificare l'identità di un client a monte e poi consegnare un JWT firmato al client. Quando il client invia una richiesta API all'API gateway, il client raggruppa il token firmato insieme alla richiesta.

Poiché l'API gateway si fida dell'autorità emittente (in questo caso, il server di autorizzazione), può leggere il token e inoltrare la richiesta ai servizi backend rilevanti. Il token contiene la prova che un particolare client è stato autenticato, in modo che possa essere conservato lato client e riutilizzato su diversi microservizi, applicazioni e livelli architettonici entro una durata predefinita. 

I JWT sono altamente compatti, autonomi e interoperabili, rendendoli una naturale soluzione ai moderni sistemi distribuiti. Tuttavia, l'uso dei JWT può comportare alcuni svantaggi evidenti. Innanzitutto, revocare i token prima della scadenza è difficile senza sacrificarne la natura stateless, il che richiede sessioni di durata relativamente breve per limitare le vulnerabilità di sicurezza. Inoltre, i team potrebbero sovraccaricare i payload con troppe informazioni, rallentando i processi di autenticazione. Infine, i processi di autenticazione JWT personalizzati non beneficiano della standardizzazione e dell'interoperabilità insite all'OIDC e ad altre alternative.

Indipendentemente dagli approcci specifici che un'organizzazione utilizza, esistono alcune best practice condivise che possono aiutare a mitigare le sfide comuni di autenticazione. Le strategie più comuni includono:

Concedere un accesso eccessivo a troppi utenti può esporre le organizzazioni a rischi inutili. Senza una distribuzione rigorosa delle responsabilità e una corretta supervisione, un utente potrebbe introdurre involontariamente disallineamenti nella pipeline di autenticazione. 

Il principio del privilegio minimo può aiutare a risolvere questo problema. Il concetto afferma che gli utenti dovrebbero essere autorizzati a utilizzare solo i servizi necessari per il loro lavoro, in base al loro ruolo, posizione, orario di accesso e altri fattori. 

I sistemi di autenticazione possono implementare il provisioning just-in-time in modo che l'accesso a un servizio venga revocato immediatamente dopo che un utente ha completato il proprio compito. I team possono anche configurare account amministratore separati e utilizzarli esclusivamente per apportare modifiche di alto livello alle politiche e all'infrastruttura di autenticazione. Audit e monitoraggi frequenti possono anche aiutare a limitare le vulnerabilità di sicurezza. 

Senza crittografia, è più facile per gli attaccanti rubare credenziali o token utente per accedere a materiali sensibili. Le organizzazioni possono utilizzare protocolli crittografici come TLS (il più delle volte tramite HTTPS) per proteggere le transazioni che richiedono autenticazione. TLS può essere integrato con altre misure di crittografia, come mTLS, che richiede che sia il client che il server siano autenticati (chiamata anche autenticazione bidirezionale).

Nei framework OIDC, la crittografia web JSON (JWE) può fornire un ulteriore livello di sicurezza durante le transazioni dei token di accesso. Infine, gli algoritmi di hashing (una pratica fondamentale della sicurezza) possono nascondere le credenziali per mantenere uno storage sicuro.

I token di breve durata, che vengono ruotati poco dopo l'emissione (tipicamente in pochi minuti o ore), possono limitare la capacità degli attaccanti di intercettarli. Questo processo è spesso automatizzato in modo che i team IT non debbano tracciare manualmente e revocare i token. 

Un approccio simile può essere applicato alle credenziali tradizionalmente durature, come password e chiavi API. Ad esempio, le organizzazioni potrebbero implementare una password monouso e unica per integrare il login dei dipendenti. Con questa strategia, agli aggressori viene impedito di accedere a materiali sensibili, anche se ottengono il nome utente e la password a lungo termine di un dipendente. Nel frattempo, le organizzazioni possono assegnare chiavi API a specifici indirizzi IP o reti (come una VPN gestita dall'azienda), limitando ulteriormente l'accesso ai client affidabili.

Sebbene i workflow di autenticazione possano essere distribuiti all'interno dell'organizzazione, i team di sicurezza IT possono standardizzare e mantenere lo storage di chiavi API e token e la governance e la supervisione tramite una piattaforma centralizzata di gestione dei segreti. Un control plane centralizzato aiuta a garantire l'implementazione coerente dei protocolli di autenticazione tra i vari team, reparti e cicli di vita delle credenziali.

Molti metodi di autenticazione, tra cui JWT, chiavi API e autenticazione di base, sono nativamente stateless (il client invia token di autorizzazione o credenziali con ogni richiesta API), consentendo alle API di soddisfare le richieste senza dover fare riferimento a una sessione esterna.

Poiché la chiamata API è autonoma, è possibile aggiungere nuovi servizi senza interrompere i workflow di autenticazione, migliorando la scalabilità. Nel frattempo, l'autenticazione può essere effettuata una sola volta, con le credenziali o i token applicati a più chiamate API, a beneficio dell'efficienza e delle prestazioni del sistema. 

Tradizionalmente, le API facilitavano le interazioni avviate dall'uomo con servizi e applicazioni. Ma man mano che l'automazione e le funzionalità agentiche diventano una parte sempre più critica dei workflow moderni, le organizzazioni stanno ripensando i loro meccanismi di autenticazione per accogliere meglio gli utenti non umani. 

Le identità non umane (NHI) possono includere container, dispositivi IoT, server, applicazioni e agenti AI. Le piattaforme di autenticazione moderne spesso assegnano certificati digitali unici a ogni NHI affinché possano essere monitorati e protetti. Questa misura di sicurezza è importante, considerando che in media ci sono 92 NHI per ogni persona nell'azienda moderna, secondo uno studio Entro Labs del 2025.

L'autenticazione NHI presenta sfide diverse, soprattutto perché i bot non possono eseguire MFA o inserire password. Nei framework OAuth 2.0, gli NHI ricevono invece token di accesso, che possono poi utilizzare per chiamare autonomamente le API rilevanti. 

Le piattaforme cloud, invece, spesso fanno riferimento ai propri servizi di identità integrati per autenticare dinamicamente i workload NHI, invece di riferirsi a un IdP di terze parti. Gli agenti AI complicano ulteriormente l'autenticazione perché possono svolgere compiti complessi e a più passaggi attraverso gli ambienti. Poiché questi agenti possono operare senza intervento umano, l'autenticazione aiuta a prevenire che trapelino involontariamente informazioni sensibili o creino disallineamenti. 

I diversi metodi di autenticazione funzionano meglio con diversi tipi di sistemi agentici. Ad esempio, i server Model Context Protocol (MCP), che aiutano gli LLM a comunicare con servizi esterni, possono utilizzare vari metodi di autenticazione, inclusi OAuth 2.0 e chiavi API, a seconda di quanto richiesto dal servizio esterno. MTLS, invece, potrebbe essere più adatto a contesti zero trust. Ad esempio, i team possono utilizzare l'autenticazione basata su mTLS per limitare un agente dalle implementazioni live, dandogli al contempo accesso a ambienti di test sicuri.