È sicuro utilizzare un URL per autenticarsi automaticamente su un'API protetta da OAuth?

No, questo schema che proponi non è sicuro, perché stai potenzialmente esponendo il tuo token di autorizzazione tra domini nei log del server e le stringhe referer su qualsiasi server web di terze parti con cui stai collegando il contenuto (o possibilmente iniettato) da XSS per controllare i valori della richiesta), se lo si passa come parametro URI.

Per quanto riguarda i cookie, dipende se utilizzerai questo token di autorizzazione su più domini o un singolo dominio:

• Più domini : dal momento che avrai bisogno che i tuoi cookie vengano letti su più domini (non limitato a un certo path ), significa che potrebbero essere letti da qualsiasi dei tuoi fornitori di contenuti di terze parti ( qualsiasi contenuto collegato, incluso ma non limitato a codice JavaScript esterno, CSS, immagine, video, ... file). Un modo migliore per farlo sarebbe con l'uso del metodo POST HTTP, quindi almeno non esponete inutilmente questo token a nessuno dei vostri fornitori di contenuti di terze parti (i dati del modulo su POST fanno parte del richiesta corpo e non intestazione, il che significa che i suoi valori non sono semplicemente ispezionabili attraverso i server web).
• Dominio singolo : puoi utilizzare i cookie per questo, ma assicurati che siano bloccati su un singolo dominio nel loro valore path e, se possibile, usa anche httponly cookie (se il framework non funziona) Supponiamo di lavorare direttamente con questo valore, è sufficiente allegare ;httponly alla fine del valore del cookie di autorizzazione). L'utilizzo di httponly assicurerà che questi cookie non possano essere letti da JavaScript su tutti i browser di supporto (la maggior parte lo supportano), eliminando così la minaccia di iniezioni XSS per rubare i token di autorizzazione e dirottare le sessioni utente.

Queste sono le considerazioni di cui dovrai occuparti, indipendentemente dal fatto che tu abbia inteso nella tua domanda l'autorizzazione per più domini o uno con dominio singolo:

• I token non dovrebbero essere solo casuali, ma anche unici . Casuale qui significa che non possono essere previsti conoscendo nessuno dei token precedenti, e univoci significa che non solo devi espirarli il più velocemente possibile, ma rimuoverli completamente dal tuo token e controllare la creazione di token che non sei ripetendo e con esso invalidando tutti i token generati in precedenza che sono ancora validi. Anche se l'imprevedibilità dovrebbe teoricamente occuparsi degli ultimi requisiti di unicità, è sempre meglio accertarsi e confrontarsi con il proprio pool prima di scrivere un nuovo token nel proprio database.
• Probabilmente vorrai bloccare la validità del tuo token in un client univoco il prima possibile. Mentre quel client unico potrebbe essere un punto piuttosto discutibile e facile da spoofing, fornisce comunque una convalida aggiuntiva quando verrà utilizzato un singolo token per autorizzare un singolo utente su più domini (o su un singolo dominio, quando l'utente invia nuovamente la richiesta di accesso per qualche motivo). Suggerisco di firmare qualsiasi dato cliente su cui poter mettere le mani con un HMAC e quindi memorizzarlo nel tuo database insieme a il token. Su ogni ulteriore richiesta di autenticazione, si verifica anche questa HMAC firma del client per convalidare ulteriormente il token utilizzato.
• Forse la cosa più importante, assicurati che tutto questo scambio di token sia protetto utilizzando il livello di trasporto crittografato , ovvero HTTPS (SSL o TLS) ed elimina MiTM attacca i tipi sulla tua procedura di autorizzazione.