OAuth2

Art. no. 216100577

No alt text available

Prenly supporta OAuth2 con o senza estensione OpenID Connect (OIDC), purché il server di autorizzazione segua le specifiche OAuth2 RFC 6749. È probabile che sia necessario un server di autorizzazione che supporti OIDC.

Prenly supporta solo la concessione dell'autorizzazione Authorization Code.

Il client che Prenly utilizzerà nel flusso OAuth2 è l'autorità dell'applicazione dell'e-paper (un'implementazione tecnica che decide come l'autenticazione e l'autorizzazione vengono gestite dall'applicazione dell'e-paper nel backend di Prenly).

Prenly dovrà conoscere alcune cose per poter agire come client per il flusso di autorizzazione:

- Opzionale*. L'emittente scelto.
Questo è obbligatorio solo se si vuole utilizzare l'estensione OpenID Connect per la richiesta di token ID.

- Obbligatorio. L'ID del cliente che si vuole far usare all'autorità Prenly.

- Obbligatorio. Il segreto del client che si desidera che l'autorità Prenly utilizzi quando scambia la concessione di autorizzazione fornita per un token di accesso durante l'autenticazione dell'autorità Prenly (il client).

- Facoltativo. Ambito di applicazione. Si può scegliere di far utilizzare a Prenly un elenco di ambiti separati da spazi che definiscono l'autorizzazione del token emesso. Gli ambiti saranno utilizzati con l'endpoint di autorizzazione.

- Opzionale. Stato. Prenly supporta la generazione dello stato nella richiesta di autorizzazione. Si può scegliere se lasciare che Prenly generi uno stato o se far sì che l'autorità lo ignori.

- Obbligatorio. Endpoint dell'autorizzazione. L'autorità Prenly indirizzerà l'agente utente verso questo endpoint per avviare il flusso di autorizzazione con il server di autorizzazione, effettuando il login dell'utente e ottenendo la concessione del codice di autorizzazione.

- Obbligatorio. Endpoint del token. L'autorità Prenly cercherà di scambiare il codice di autorizzazione dell'utente con un token di accesso o, se il server di autorizzazione lo supporta (cosa fortemente consigliata), di scambiare il token di aggiornamento dell'utente con un nuovo token di accesso.

Metodo di autenticazione. Per impostazione predefinita, Prenly utilizza il metodo di autenticazione client client_secret_basic dell'OIDC quando si autentica con il token endpoint del server di autorizzazione. Prenly supporta anche il metodo di autenticazione client_secret_post. Si prega di informare Prenly se si richiede quest'ultimo, altrimenti verrà utilizzato il metodo di autenticazione predefinito.

- Consigliato. Un URL esterno per disconnettere l'utente. L'autorità Prenly utilizzerà l'agente utente selezionato dell'utente corrente per disconnettere l'utente in remoto presso il server di autorizzazione.
Prenly è in grado di utilizzare dei segnaposto nell'URL durante la creazione della richiesta di autorizzazione per disconnettere l'utente, fornendo quanto segue:

◦ L'ID del cliente;
L'URI di ritorno del logout;
◦ l'URI di errore di logout;

Si noti che lo stato non può essere utilizzato.
Un esempio di parametro di query dell'URI di ritorno è "post_logout_redirect_uri".

Attualmente, per l'URL di logout è supportato solo il metodo HTTP GET.

ID utente

L'autorità Prenly dovrà sapere come estrarre l'ID utente univoco dopo che l'utente è stato autorizzato con successo dal server di autorizzazione.

Questo ID utente univoco, se si utilizza l'API dell'autorità remota Prenly, è il parametro di richiesta `uid` quando si richiedono le informazioni di riepilogo dell'utente.

Si può scegliere uno dei seguenti metodi:

- Da una proprietà nella risposta del token endpoint JSON. Se si sceglie questo metodo, è necessario comunicare il nome della proprietà scelta contenente l'ID utente.

- Dalla rivendicazione "sub" di OpenID Connect nel token ID firmato (come restituito dalla proprietà di risposta del token "id_token").
Per poter estrarre l'ID utente è necessario fornire anche:

◦ Richiesto. L'URL esterno alle chiavi pubbliche per convalidare i token ID. Questo URL deve contenere un set di chiavi web JSON secondo gli standard JWT, che può essere indicato come JKU o JWKS.
Opzionale. Il nome della proprietà nella risposta dei dati utente che contiene un numero di cliente.

- Dalla risposta della proprietà "sub" di un endpoint UserInfo.
Per utilizzare questo metodo è necessario fornire anche:

◦ Richiesto. L'URL dell'endpoint UserInfo. L'endpoint viene utilizzato per recuperare le informazioni di base sull'utente, utilizzando il token di accesso dell'utente per autorizzare la richiesta.
Facoltativo. Il nome della proprietà nella risposta dei dati utente che contiene un numero di cliente.

Server delle risorse

Potete scegliere un server di risorse supportato da Prenly oppure potete contattarci all'indirizzo hello@prenly.com per richiedere a Prenly di supportare il vostro specifico server di risorse come attività di integrazione, che Prenly potrebbe supportare sulla base di un'attività di sviluppo a pagamento.

Prenly supporta l'API Prenly Remote authority dalla versione 1.4 o superiore come server di risorse. Per informazioni sul concetto di API, consultare le nostre informazioni generali su Prenly Remote authority API. Per implementare Prenly Remote authority API come server di risorse, consultare le specifiche API per l'endpoint /oauth2/getUser.

La "risorsa" che Prenly richiede al server di risorse è un elenco di prodotti in abbonamento associati all'utente. I prodotti, sotto forma di codice prodotto, indicano lo stato di abbonamento dell'utente e ogni codice è configurato per garantire l'accesso in lettura alle pubblicazioni all'interno dell'applicazione e-paper.

Per concedere il corretto accesso in lettura a seconda del prodotto di abbonamento, è necessario comunicare a Prenly le pubblicazioni a cui il codice prodotto autorizza l'accesso in lettura. Qualsiasi prodotto sconosciuto verrà ignorato.

Potrebbe non essere necessario un server di risorse dedicato...

Prenly può evitare un server di risorse tradizionale se l'endpoint UserInfo è in grado di rivelare lo stato di sottoscrizione del proprietario della risorsa - l'utente.

Se l'endpoint UserInfo è in grado di farlo, tutto ciò che si dovrà fornire è il claim (nome della proprietà) nei dati JSON di risposta dell'endpoint UserInfo.

Il valore della richiesta deve essere un elenco JSON (array) di stringhe. Ogni elemento dell'elenco rappresenta un codice prodotto dell'abbonamento.

Fornire informazioni

Una volta ottenute tutte le informazioni richieste, contattare il servizio clienti di Prenly all'indirizzo hello@prenly.com. Il team imposterà l'autorità Prenly dell'applicazione e-paper scelta per utilizzare OAuth2.

Prenly - Prenota una demo
Volete vedere come la vostra rivista o pubblicazione potrebbe apparire su Prenly? Prenota una demo

© Textalk

We use DeepL and ChatGPT for translations. Occasional imprecisions may occur.