🛠️
Opencity Italia
Sviluppatori e partner tecnologici
Sviluppatori e partner tecnologici
  • Introduzione
  • Architettura
    • Pattern: microservizi
    • Pattern: event sourcing
    • Vista generale
  • Standard e convenzioni
    • Standard della piattaforma
    • Microservizi
  • Roadmap
  • Integrazioni
    • Integrazione Widget servizio (FormIO)
    • Integrazioni con il flusso delle pratiche
      • API ReST
      • Webhooks
    • Modello di integrazione con l'area personale
    • Integrazione con Intermediari di pagamento PagoPA
      • Requisiti per l'integrazione
      • Il Pagamento
        • Versione 1.0
        • Versione 2.0
      • Schema di Funzionamento
      • Configurazione dei pagamenti
        • API v1
        • API v2
      • Un pagamento in dettaglio
      • Gli stati di un pagamento
      • Processo di sviluppo
      • Implementazione di un proxy
    • Integrazione con Protocollo Informatico
      • Requisiti per l'integrazione
      • Documento digitale
        • Esempio documento con allegati non protocollato
        • Esempio documento con allegati protocollato
        • Esempio documento con campo retry_meta prodotto dal protocol proxy
        • Esempio documento con campo retry_meta modificato dal sistema di retry
        • Usecase: Il Documento originato dalle pratiche dai servizi digitali
        • Stati del documento
      • Architettura del sistema di protocollazione
      • WorkFlow sistema di protocollazione
        • Configurazione tenant e servizi
      • Protocol Proxy: Specifiche Implementative
      • Processo di sviluppo
    • Integrazioni con il Sito Istituzionale
    • Single Sign-On
      • SSO mediante oAuth2
      • SSO mediante JWT
    • Processi asincroni (job)
      • Importazione dovuti
    • Integrazione di un servizio di terze parti protetto da autenticazione
      • Esempio con GovWay
  • 👩‍💻Sviluppo
    • Multilingua
    • Temi grafici
Powered by GitBook
LogoLogo

Opencity Labs

  • Sito web
  • Product page

Developers Italia

  • Sito web
  • Area personale e Servizi Digitali

Documentazione Opencity Italia

On this page
  • Il Cookie di Sessione
  • Il token JWT
  • Anatomia di un Token

Was this helpful?

Export as PDF
  1. Integrazioni
  2. Single Sign-On

SSO mediante JWT

La piattaforma Opencity Italia supporta questa possibilità mediante una tecnica che permette di convertire una sessione basata su cookie in un token JWT.

PreviousSSO mediante oAuth2NextProcessi asincroni (job)

Last updated 7 months ago

Was this helpful?

Questo consente di usare l'autenticazione senza necessariamente usare lo stesso cookie:

  1. integrarsi con altri applicativi di terze parti che possono usare un client JWT;

  2. fare chiamate cross-origin (CORS) autenticate dove non è semplice o possibile sfruttare lo stesso cookie di autenticazione;

Attenzione: il requisito perché questa tecnica funzioni è che i servizi si trovino tutti sotto lo stesso dominio di secondo livello. Ad esempio: - servizi.comune.bugliano.pi.it - www.comune.bugliano.pi.it - altro.bugliano.pi.it

Il Cookie di Sessione

Come molti applicativi web anche Opencity Italia usa i cookie per implementare la sessione utente, il cookie si ottiene semplicemente l'indirizzo di accesso degli utenti: ad esempio per il nostro Ente di demo è

A questo punto nel proprio brower è possibile rintracciare facilmente il cookie della piattaforma.

Il token JWT

Il cookie di sessione viene inviato in modo trasparente all'utente dal browser al sito che lo ha generato, e questo garantisce che l'utente abbia sempre una sessione valida quando naviga nella sua area personale.

Per fare chiamate alle API però è necessario convertire il Cookie in Token JWT, per farlo esiste una apposita API, nel nostro esempio:

Per simulare la chiamata con Postman ad esempio:

Il token JWT può essere usato adesso per fare chiamate alle API che richiedono una autenticazione, ad esempio posso usare l'interfaccia Swagger delle API come segue.

Faccio click in alto a destra sul comando Authorize

A questo punto posso chiamare le API che richiedono autenticazione come la /applications

Anatomia di un Token

All'interno del token sono presenti le seguenti informazioni:

Header

{
  "typ": "JWT",
  "alg": "RS256"
}

Payload

{
  "iat": 1711639327,
  "exp": 1712503327,
  "roles": [
    "ROLE_CPS_USER",
    "ROLE_USER"
  ],
  "username": "AAAAAANNANNAMNNNA",
  "id": "ba23337b-7b9e-4e5a-9566-e3f0583822f7",
  "tenant_id": "5962qqfb-15b7-4407-b203-47ee3456f6c3"
}

In base alla , si viene rediretti su un provider di autenticazione (tipicamente un sistema che permette il login con Spid/CIE), si eseguono tutti gli step necessari e infine si torna sull'area personale con una sessione valida.

https://servizi.comune.bugliano.pi.it/lang/it/userservizi.comune.bugliano.pi.it
Il path per fare accesso è sempre /$lingua/user
https://servizi.comune.bugliano.pi.it/lang/api/session-authservizi.comune.bugliano.pi.it
l'API per ottenere il token JWT è /api/session-auth
Esempio di cookie di sessione
esemio di chiamata per recupeare il token JWT usando il cookie e l'API /session-auth
Inserisco il valore del token ottenuto con la chiamata /session-auth
https://servizi.comune.bugliano.pi.it/lang/api/doc
configurazione del tipo di accesso