Come vengono archiviate le credenziali del proprietario delle risorse in OAuth2

1

Ho svolto ricerche su oauth2 recentemente e ho cercato di redigere un piano di implementazione. Tuttavia mi sembra che manchi qualcosa, o qualcosa non è ancora abbastanza cliccato.

Ho intenzione di creare un'API e di proteggere determinati endpoint, richiedendo l'autorizzazione. Questa API sarà accessibile tramite la mia prima applicazione Web di partito che utilizza javascript / vuejs.

Per riuscirci, il "Flusso della password del proprietario della risorsa" sembra essere la scelta migliore per consentire ai proprietari di risorse di autenticarsi per ottenere l'accesso a parti dell'API. L'implementazione specifica che ho scelto di utilizzare per oauth2 è "Passport" di laravel. Di seguito è riportato un codice di esempio per il flusso della password e il layout della tabella utilizzato da questa implementazione:

$response = $http->post('http://your-app.com/oauth/token', [
    'form_params' => [
        'grant_type' => 'password',
        'client_id' => 'client-id',
        'client_secret' => 'client-secret',
        'username' => '[email protected]',
        'password' => 'my-password',
        'scope' => '',
    ],
]);


+-------------------------+
|oauth_clients            |
+-------------------------+
|id                       |
|user_id                  |
|name                     |
|secret                   |
|redirect                 |
|personal_access_client   |
|revoked                  |
|updated_at               |
|created_at               |
+-------------------------+

+-------------------------+
|oauth_auth_codes         |
+-------------------------+
|id                       |
|user_id                  |
|client_id                |
|scopes                   |
|revoked                  |
|expires_at               |
+-------------------------+

+-------------------------+
|oauth_access_tokens      |
+-------------------------+
|id                       |
|user_id                  |
|client_id                |
|name                     |
|scopes                   |
|revoked                  |
|created_at               |
|updated_at               |
|expires_at               |
+-------------------------+

+-------------------------+
|oauth_refresh_tokens     |
+-------------------------+
|id                       |
|access_token_id          |
|revoked                  |
|expires_at               |
+-------------------------+

+------------------------------+
|oauth_personal_access_clients |
+------------------------------+
|id                            |
|client_id                     |
|updated_at                    |
|created_at                    |
+------------------------------+

Nella richiesta di esempio sopra, sono richiesti client_id e client_secret insieme a username e password . Non riesco a vedere come chiamare http://your-app.com/oauth/token con i parametri forniti consentirebbe a un proprietario di risorse di autenticarsi, poiché non esiste alcuna tabella che memorizzi username e password del proprietario di una risorsa.

Qualcuno potrebbe spiegarmi cosa sta succedendo qui o quali pezzi del puzzle mi mancano? Il server di autorizzazione OAuth2 deve essere collegato alla mia API (server delle risorse) in qualche modo che consente al server di autorizzazione di autenticare gli utenti in base al loro nome utente e password? ...

    
posta nullReference 15.09.2017 - 20:28
fonte

2 risposte

2

Should the OAuth2 authorization server be tied to my api (resource server) in some way that allows the authorization server to authenticate user's based on their username and password?...

Dipende dai bisogni, ma sì, è un'implementazione abbastanza comune. Tuttavia, ha portato molte persone a credere che OAuth2 sia anche un protocollo di autenticazione; quando non lo è.

As an additional confounder to our topic, an OAuth process does usually include several kinds of authentication in its process: the resource owner authenticates to the authorization server in the authorization step, the client authenticates to the authorization server in the token endpoint, and there may be others. The existence of these authentication events within the OAuth protocol does not translate to the OAuth protocol itself being able to reliably convey authentication.

-oauth.net-

L'obiettivo di OAuth2 è consentire alle applicazioni di interagire senza dover condividere credenziali. Senza doversi preoccupare degli utenti. A OAuth2 non importa come vengono identificati gli utenti. Prevede solo token e emittenti dei token per ulteriori convalide.

I fail to see how calling http://your-app.com/oauth/token with the provided parameters would allow a resource owner to authenticate, since there is no table that stores a resource owner's username and password.

Questo perché la convalida delle credenziali (autenticazione) dovrebbe essere delegata a qualcun altro.

Questo altro utente può essere la tua applicazione (ad esempio un endpoint di accesso) o esterna. Ad esempio Facebook, Google, Github, ecc.

Diciamo che abbiamo un'applicazione web chiamata MyApp.com . Vorremmo consentire ai nuovi utenti di registrarsi e autenticarsi rapidamente ottenendo i dati da altre applicazioni di cui ci fidiamo. Ad esempio, dagli account Facebook.

Ovviamente, non possiamo chiedere agli utenti le loro credenziali di Facebook. Invece, deleghiamo il duro lavoro a Facebook. Il nostro processo di autenticazione reindirizzerà a OAuth di Facebook.

Gli utenti accederanno a Facebook e ci concederanno l'accesso ai loro dati del profilo.

Facebook genererà un token come prova di a) identità utente eb) i privilegi sull'account utente. Questo token è ciò che conosciamo come token ID .

I token ID vengono rispediti a Facebook ogni volta che Myapp.com deve interagire con Facebook.

Dopo aver ottenuto il token ID, la prima cosa che facciamo è richiedere il profilo utente di Facebook. Inviamo il token ID nella richiesta. Se Facebook accetta il token, completiamo la registrazione / login e permettiamo agli utenti di passare.

D'altra parte, MyApp.com ha anche il suo registro e il suo log-in. Se gli utenti inviano credenziali MyApp.com , chi intendi sarà il provider di identità ? Indovini giusto. MyApp.com stesso. Come possiamo vedere, l'autenticazione e l'autorizzazione sono cose diverse.

How are resource owner credentials stored in OAuth2?

Secondo le opzioni di cui sopra, le credenziali possono essere memorizzate nella tua applicazione, in un Provider di identità centralizzato e condiviso (noto anche come provider di identità federata) o potrebbero essere archiviate in nessun posto all'interno del tuo dominio (Facebook, Google, ecc.)

Considerazioni

Se la tua applicazione è l'unico consumatore di autorizzazione, considera di cambiare il modello di autenticazione per qualcosa di più semplice (ad es. JWT) e considera anche di avere il servizio integrato all'interno dell'applicazione. In definitiva, è solo il servizio di autenticazione dell'applicazione .

    
risposta data 16.09.2017 - 12:25
fonte
0

OAuth2 descrive un meccanismo di scambio di token per concedere accesso limitato a una risorsa di terze parti per conto di un utente / servizio . Al suo centro, c'è il concetto di token Bearer . Questo token bearer è progettato per essere convalidato senza un altro round trip su un server. Un'implementazione comune e utile del token al portatore è Token Web JSON (JWT) .

Anche se non è obbligatorio utilizzare JWT per OAuth, risolve molti problemi:

  • JWT può essere convalidato utilizzando una sezione della firma
  • Contiene metadati sufficienti sull'utente che fa il lavoro
  • Può contenere dati specifici dell'applicazione come una raccolta di ruoli utente
  • Può anche essere scaduto e rinegoziato automaticamente

Includendo l'insieme di concessioni (ovvero i ruoli utente) nel token, il tuo servizio web non deve chiamare un altro servizio web per verificare se il token del portatore è autorizzato a svolgere lavoro.

Probabilmente hai notato che non ho parlato di Autenticazione ovunque qui. Questo perché l'autenticazione non è il ruolo di OAuth. È il ruolo del servizio token. Ad esempio, se si tenta di utilizzare un'applicazione con un token non aggiornato e tale applicazione utilizza Facebook per l'autenticazione, all'utente viene presentata una pagina di accesso di Facebook . Una volta che il servizio di autenticazione convalida che l'utente è chi rivendica , può emettere il token. Tutte le interazioni di servizio dopo che utilizzano solo il token al portatore .

    
risposta data 17.10.2017 - 14:57
fonte

Leggi altre domande sui tag