In tal caso -
- Le credenziali del client dovrebbero essere inviate con ogni richiesta a ogni app / sistema lato server che può presentare risorse.
- Non ci sarebbe nessuna scadenza e nessuna limitazione dell'ambito su una sessione specifica.
- Sarebbe come un'autenticazione di base legacy, con tutti i suoi inconvenienti e vantaggi (semplicità)
Nel flusso delle credenziali del client OAuth, "client" si riferisce a un'applicazione client e non necessariamente al proprietario della risorsa (utente finale). In alcuni casi, come le app per dispositivi mobili, entrambi sono quasi gli stessi, in quanto di solito c'è un singolo utente del client. Pertanto, per una semplice applicazione, la sostituzione di un token di accesso inviando ripetutamente le credenziali del cliente può essere un sostituto adatto. Tuttavia, per qualsiasi applicazione distribuita in cui le API e le risorse sono distribuite su domini / server / applicazioni diversi, avere un endpoint del token centrale è più scalabile e più sicuro solo in virtù del fatto che si tratti di un singolo punto.
Mentre Facebook ha OAuth a due vie per gli utenti finali (proprietari di risorse) che utilizzano le app di Facebook (client), Facebook fornisce token di accesso alle app di Facebook tramite il flusso di lavoro delle credenziali client OAuth.