[Provider] SSO and force auth

[peppelinux]

Handle the SSO and the force authn if "prompt": "consent login", or ACR > L2

[peppelinux]

• scope = offline_access, prompt != consent allora si deve bloccare tutto e dare un messaggio di invalid_request
• scope != offline_access, prompt != login, L1 in acr_values, user.is_autenticate -> redirect a consent page
• scope = offline_access, prompt = consent, L1 in acr_vaues, user.is_autenticate -> redirect a consent page e viene rilasciato il refresh token
• scope = offline_access, prompt = consent, L1 in acr_vaues, !user.is_autenticate -> viene richiesta l'autenticazione e viene rilasciato il refresh token
• scope = offline_access, prompt = consent, L1 NON in acr_values -> indipendentemente dal fatto che l'utente sia autenticato o meno viene chiesto sempre di autenticarsi nuovamente e NON viene rilasciato il refresh token

l'unico dubbio che ho è che un refresh token, una volta utilizzato, non possa essere più utilizzato (CU1 dovrebbe comunque invalidare il refresh token, non lo considererei). Perlomeno nella implementazione ci muoveremmo così.

Poi, per completezza, aggiungo di seguito le note di @damikael

La differenza tra iat è exp può essere di massimo 30 giorni. La validità del refresh token deve essere calcolata a partire dall'autenticazione originaria, salve eccezioni stabilite da AGID in casi specifici. I casi d'uso previsti sono:
CU 1 (senza rotazione)

• t1 : RP effettua autenticazione con offline_access, quindi ottiene refresh_token RT1 (30gg)
• t2 = t1 + 4gg : dopo 4gg da t1 RP fa richiesta a /token presentando RT1. OP rilascia nuovo access_token e lo stesso RT1 con validità 30gg da t1 (26gg)
  CU 2 (con rotazione)
• t1 : RP effettua autenticazione con offline_access, quindi ottiene refresh_token RT1 (30gg)
• t2 = t1 + 4gg : dopo 4gg da t1 RP fa richiesta a /token presentando RT1. OP rilascia nuovo access_token e nuovo refresh_token RT2 con validità 30gg da t1 (26gg)
• t3 = t1 + 27gg : dopo 27gg da t1 RP fa richiesta a /token presentando RT2. OP rilascia nuovo access_token e nuovo refresh_token RT3 con validità 30gg da t1 (3gg)
  CU 3 (con rotazione ed eccezione per RP X)
• t1 : RP X effettua autenticazione con offline_access, quindi ottiene refresh_token RT1 (30gg)
• t2 = t1 + 4gg : dopo 4gg da t1 RP X fa richiesta a /token presentando RT1. OP riconosce che la richiesta proviene da X e rilascia nuovo access_token e nuovo refresh_token RT2 con validità 30gg da t2 (30gg)
• t3 = t1 + 27gg : dopo 27gg da t1 RP fa richiesta a /token presentando RT2. OP riconosce che la richiesta proviene da X e rilascia nuovo access_token e nuovo refresh_token RT3 con validità 30gg da t3 (30gg)
  Al momento, viene richiesta solo la CU2, ma gli IdP devono garantire anche CU1 e CU3 in base a specifiche richieste di AGID.

[peppelinux]

the example project must be deployed in https otherwise browser applies the samesite-cookies restrictions on cross domains in absence of HTTPS

@francescatronconi ^

[peppelinux]

consider als oto merge/change/merge this PR for v0.7.0 and SSO
#224