{"id":71307,"date":"2020-02-24T22:18:55","date_gmt":"2020-02-24T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt"},"modified":"2020-03-03T16:14:27","modified_gmt":"2020-03-03T13:14:27","slug":"identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","title":{"rendered":"IdentityServer4. Concetti di base. OpenID Connect, OAuth 2.0 e JWT","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Con questo post voglio aprire una serie di articoli dedicati a IdentityServer4. Iniziamo con i concetti di base.<\/p>\n

<\/p>\n

Attualmente, il protocollo di autenticazione pi\u00f9 promettente \u00e8 OpenID Connect<\/a><\/noindex>, mentre il protocollo di autorizzazione (per concessione di accesso) \u00e8 OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> implementa questi due protocolli. \u00c8 ottimizzato per risolvere problemi tipici<\/strong> di sicurezza.<\/p>\n

<\/a><\/noindex><\/p>\n

OpenID Connect<\/a><\/noindex> \u2014 \u00e8 un protocollo e uno standard di autenticazione, non fornisce accesso alle risorse (Web API), ma poich\u00e9 \u00e8 stato sviluppato sopra il protocollo di autorizzazione OAuth 2.0<\/a><\/noindex>, consente di ottenere i parametri del profilo utente come se si fosse ottenuto accesso alla risorsa UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) \u00e8 uno standard web che definisce il modo di trasmettere i dati dell'utente in formato JSON in modo crittografato.<\/p>\n

OAuth 2.0 (RFC 6749)<\/a><\/noindex> \u2014 \u00e8 un protocollo e uno standard di autorizzazione. Permette alle applicazioni di accedere a risorse protette, come le Web API.<\/p><\/blockquote>\n

Esaminiamo il diagramma di accesso a una risorsa protetta e compiamo i principali passaggi e la terminologia accettata:<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    Il client richiede all'utente il permesso di eseguire l'autenticazione per suo conto. Cliente<\/strong> \u2014 \u00e8 un'applicazione client che accede alle risorse protette a nome del proprietario delle risorse. La risorsa<\/strong> \u2014 sono tutti i nostri servizi protetti Web API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    L'utente consente all'applicazione client di eseguire l'autenticazione per suo conto, ad esempio inserendo nome utente e password. Il nome utente e la password fungeranno da concessione di autorizzazione per l'applicazione client. Utente (proprietario della risorsa)<\/strong> \u2014 \u00e8 il programma o l'individuo che pu\u00f2 concedere accesso a risorse protette, ad esempio, tramite l'inserimento del nome utente (username) e della password (password);<\/p>\n

    \n<\/li>\n

  3. \n

    L'applicazione client richiede un token di accesso a IdentityServer4<\/code> fornendo informazioni su se stessa (client_id<\/code>, client_secret<\/code>), concedendo l'autorizzazione per l'autenticazione da parte dell'utente (username<\/code>, password<\/code>) e fornendo grant_type<\/code> e scope<\/code>. Poi il server di autorizzazione verifica l'autenticit\u00e0 del client e le credenziali del proprietario della risorsa (nome utente e password). <\/p>\n

    <\/p>\n

    Il protocollo OAuth 2.0 esegue l'autenticazione non solo dell'utente, ma anche dell'applicazione client che accede alle risorse. A tal fine, il protocollo prevede parametri come client_id<\/strong> e client_secret<\/strong>.
    \nclient_id<\/strong> \u2014 \u00e8 l'identificativo dell'applicazione client, utilizzato IdentityServer4<\/code> per cercare informazioni sul client.
    \nclient_secret<\/strong> \u00e8 l'equivalente della password per l'applicazione client e viene utilizzato per l'autenticazione dell'applicazione client su IdentityServer4<\/code>. Il segreto del cliente deve essere conosciuto solo dall'applicazione e dall'API<\/strong>. Da quanto detto in precedenza, possiamo concludere che IdentityServer4 deve sapere dei suoi clienti<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    Se l'autenticit\u00e0 dell'applicazione \u00e8 confermata e il permesso per l'autorizzazione \u00e8 valido, IdentiryServer4<\/code> crea access-token<\/code> (token di accesso) per l'applicazione e un optional refresh token (refresh-token<\/code>). Il processo di autorizzazione \u00e8 completato. Se la richiesta \u00e8 invalida o non autorizzata, il server di autorizzazione restituisce un codice con il relativo messaggio di errore.<\/p>\n

    \n<\/li>\n

  5. \n

    L'applicazione client richiede dati da un API Web protetta, fornendo nel contempo il token di accesso per l'autorizzazione. Se il codice di risposta del server delle risorse 401<\/a><\/noindex>, 403<\/a><\/noindex> o 498<\/a><\/noindex>, allora il token di accesso utilizzato per l'autenticazione \u00e8 non valido o scaduto.<\/p>\n

    \n<\/li>\n

  6. \n

    Se il token \u00e8 valido, Web API<\/code> fornisce i dati all'applicazione.<\/p>\n

    \n<\/li>\n<\/ol>\n

    <\/p>\n

    Tipi di token<\/em><\/h4>\n

    <\/p>\n

    I clienti registrati in IdentityServer4<\/code> possono richiedere IdentityServer4<\/code> identity<\/code>-token, access<\/code>-token e aggiorna<\/code>-token.<\/p>\n

    <\/p>\n