{"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 fondamentali. 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 dai concetti fondamentali.<\/p>\n

<\/p>\n

Il protocollo di autenticazione pi\u00f9 promettente al momento \u00e8 OpenID Connect<\/a><\/noindex>, mentre il protocollo di autorizzazione (accesso) \u00e8 OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> implementa questi due protocolli. \u00c8 ottimizzato per risolvere problematiche tipiche<\/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 progettato sopra il protocollo di autorizzazione OAuth 2.0<\/a><\/noindex>, consente di ottenere i parametri del profilo utente come se si fosse avuto accesso alla risorsa UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) \u00e8 uno standard web che definisce il modo di trasmettere dati sull'utente in formato JSON in forma crittografata.<\/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, ad esempio a Web API.<\/p><\/blockquote>\n

Diamo un'occhiata al diagramma di accesso alla risorsa protetta e analizziamo i passaggi principali e la terminologia accettata:<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

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

    \n<\/li>\n

  2. \n

    L'utente permette all'applicazione client di autorizzarsi a suo nome, ad esempio, inserendo il nome utente e la password. Nome utente e password fungeranno da autorizzazione per l'applicazione client. Utente (proprietario della risorsa)<\/strong> \u2014 programma o persona che pu\u00f2 concedere accesso a risorse protette, ad esempio, inserendo nome utente (username) e 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>), fornendo l'autorizzazione per l'autorizzazione da parte dell'utente (username<\/code>, password<\/code>) e fornendo grant_type<\/code> e scope<\/code>. Quindi, 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 autentica non solo l'utente, ma anche l'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'app cliente e viene utilizzato per autenticare l'app cliente su IdentityServer4<\/code>. Il segreto del cliente deve essere noto solo all'applicazione e all'API<\/strong>. Da quanto sopra, concludiamo che IdentityServer4 deve conoscere i 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 un access-token<\/code> (token di accesso) per l'applicazione e un'opzionale chiave di aggiornamento (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 un messaggio di errore appropriato.<\/p>\n

    \n<\/li>\n

  5. \n

    L'app cliente richiede i dati a 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>, il token di accesso utilizzato per l'autenticazione \u00e8 non valido o \u00e8 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

    Ai clienti registrati \u00e8 consentito richiedere IdentityServer4<\/code> -token, IdentityServer4<\/code> identity<\/code>-token, access<\/code>-token e aggiorna<\/code>-token.<\/p>\n

    <\/p>\n