[Musica]
va bene, pranziamo e basta
continua a sentire gli applausi alla fine
parlerò molto di un Freddie
connettersi forse verso la fine non lo sei
così felice più perché in realtà è un
argomento complesso
non è così facile da digerire, ma lo sono
cercherò di renderlo digeribile per te
e il mio obiettivo qui è che te ne vai via
comprensione o comprensione completa
cosa fa perché fa quello che fa e
come lo fa
Lo stesso vale per l’ open ID che sto collegando
parlare di ciò verso la fine è
costruito sopra OAuth per una particolare
scopo e questo è il da asporto
questa sessione quando parliamo di cosa
il modo migliore per introdurre questo è forse
attraverso un’analogia del mondo reale, così è
parcheggiatore qualcosa che siamo in Europa
non troppo familiare con ma negli Stati Uniti
puoi effettivamente consegnare qualcuno alla tua auto
chiave e avranno parcheggiato l’auto per te
molto facile, molto semplice, ovviamente
si sta consegnando un estraneo la chiave per
la tua auto probabilmente di lusso è così
probabilmente forse un po ‘di rischio e allora
hai in queste macchine hai un
Valorizza una chiave speciale che puoi usare
dare verso l’ ophélie e quella chiave
apre solo la porta della macchina e
avvia la macchina ma non la dà
accesso al vano portaoggetti o
il tronco quindi se hai oggetti di valore in
lì condivido documenti importanti o
valigie o qualsiasi altra cosa se li metti dentro
lì quella chiave non li concederà
l’accesso a tale risorsa e ci porta
vicino verso l’ ID di oh perché o esso
riguarda la delega dell’accesso e se a
la chiave è una sorta di delega dell’accesso a
la tua auto a qualcun altro che non lo fai
lo so davvero ma a certe condizioni
e questo è ciò che le parti portano al
tavolo e oh arte abbiamo bisogno di un
server delle autorizzazioni per gestire quella
delegazione in primo luogo un mondo reale
Ohad esempio ritmo parliamo di
qualcosa come Twitter tutti lo sanno
Twitter Ho un feed di Twitter le mie diapositive
sono disponibili attraverso il mio feed Twitter così
puoi prendere una copia da lì se tu
voglio postare le diapositive su Twitter I
utilizzare un’applicazione nota come buffer
buffer ti permette di pianificare il mio
tweets così posso metterli pronti come
Rilascio che alle 12 in punto e sto bene
andare
nel buffer di sfondo ha bisogno di accedere a
il mio profilo Twitter, quindi delegherò
accesso al buffer per accedere al mio Twitter
per
per mio conto e postare il tweet ogni volta
Dico che dovrebbe essere pubblicato se si guarda
il lato Twitter delle cose c’è a
numero di applicazioni che ha accesso
al mio feed Twitter ecco alcuni esempi
vedi i legittimi clienti di Twitter
avendo accesso ma vedi anche questo
applicazione tampone in là e alcuni
altri tipi di applicazioni che è
combattuto sul lavoro è così che cosa in realtà
fa questa cosa e quello che ci prova
raggiungere permettendoti come utente di concedere
un accesso di applicazione per conto dell’utente a
una risorsa di terze parti quindi se si guarda
una visione concettuale da un livello molto alto
faremo tutto questo possibile
attraverso il server di autorizzazione che è
sarà la componente chiave dell’insieme
di OAuth noi come utente vogliamo concedere un
accesso alle applicazioni client così nel mio
esempio da prima del buffer sarebbe il
applicazione client voglio concedere che
accesso dell’applicazione a una risorsa I
controllo per accedere a quella risorsa
il client utilizza un token di accesso che accede
il token è qualcosa che il cliente ha
ricevuta del buffer ricevuta da Twitter e
può usarlo per accedere a un protetto
risorsa nei nostri termini che è ospitata da
il server delle risorse, quindi nell’esempio
che abbiamo quello sarebbe il Twitter
API per pubblicare un tweet che sarebbe un
risorsa protetta su un server di risorse
e un token di accesso sta per concedere
accesso e il server delle risorse sta per
bisogno di un modo per verificare se il
il cliente è effettivamente autorizzato a farlo
questo è molto importante per una risorsa
il server esegue l’autorizzazione appropriata
altrimenti qualsiasi cliente sarebbe in grado di fare
qualsiasi cosa per conto di qualsiasi utente che è
sicuramente non quello che vogliamo oh arte cosa
la specifica fornisce è in realtà circa il
danza tra il cliente e un
server di autorizzazione sulla concessione
accesso e questo è in realtà potrebbe essere il
anche la verifica dell’accesso client fa parte di
cosa ma forse nemmeno il corso
i pacchetti è una specifica separata
e come utilizzare il token di accesso a
accedere al server delle risorse che non è pari
coperto da molto perché molto è puramente
sulla delega ovviamente su tutti gli altri
le cose entrano in gioco quando inizi
usando molto perché ne avrai bisogno se tu
stai costruendo un’API che dovrai controllare
autorizzazione e prendere decisioni e
cose del genere, ma tenere a mente che
è solo basato sui meccanismi
fornito da ODS ma non parte del coart
stessa immagine qui mostra uno molto
cosa strana abbiamo un cliente uno
server delle risorse, quindi perché andare al TRO
di creazione permesso di fare quel lavoro
probabilmente non ne vale la pena
perché è abbastanza complesso da ottenere questo
lavorando e puoi fare degli errori
contro quello, naturalmente, questo paga davvero
fuori in un paesaggio dove tu hai
più clienti hai cose come
tampone che è un sistema di back-end si
avere cose come un front-end mobile
applicazione hai un’applicazione web
tutti questi possono essere clienti della stessa
parte protocollo o Oh nostro framework e di
Ovviamente hai più risorse
tutti i server offrono diversi tipi
di risorse API diverse è diversa
tipi di risorse e tutti hanno bisogno di
prendere decisioni di autorizzazione che è
che architettura OAuth ad alto livello
sembra come prima che ci tuffiamo nel
dettagli su come questa delegazione in realtà
capita una piccola parola su di me, io sono Filippo
mazzo grazie per l’introduzione
nessuno e io sono un allenatore sul web
sicurezza quindi insegno agli sviluppatori come
costruire meglio e più sicuro
applicazioni che faccio tutto il
mondo e sotto la mia compagnia web pragmatico
sicurezza che è il mio veicolo per fare
quello
Sto anche organizzando la Second Life
corso che è un corso in Belgio a
settimana di sicurezza per gli sviluppatori che sono
insegnato da esperti di tutto il mondo
Sono un esperto di sviluppatori Google che
significa che Google mi riconosce per il mio
contributi con sicurezza al
comunità ma non sono impiegato da Google
o non affiliato con Google in alcun modo
proprio come un disclaimer perché le persone tendono
per ottenere confuso circa che altrimenti
parliamo molto di più
complesso ma anche di forse di più
interessante mi avvicinerò molto
da due punti di vista diversi io sono
andando a parlare del cliente
prospettiva prima cosa significa
essere un cliente cosa devi fare
in realtà ottenere questo flusso iniziato e ottenere
questo token di accesso e ora sto andando a
parlare di un server di risorse
prospettiva come puoi autorizzare a
client che sta tentando di accedere a
un’API torna all’esempio di Twitter quindi se
vuoi costruire un client OAuth
costruirlo non è difficile ma se tu
voglio usarlo con una vera autorizzazione
server è necessario registrare il
client e nel caso Twitter questo
significa registrarsi per lo sviluppatore di Twitter
account che è proprio come fare clic su a
tasto e cliccando l’ok in una e-mail
questo è tutto e quindi è necessario
registra il tuo cliente con alcuni dettagli così
è necessario fornire un nome questo è
generalmente noto come identificatore del client
è necessario fornire un URL e in particolare
un URL di richiamata quindi devi dirlo al
server questo è dove devi inviare
qualcosa se qualcosa ritorna da
tutto questo flusso stiamo andando parlare su
quello dopo perché quello realmente conta e
una volta che lo fai, ricevi da Twitter
ottieni i segreti dei tuoi clienti che puoi
tipicamente ottengono un token di accesso e a
twitter segreto utilizza due diversi
segreti ma ciò non importa
qui o è importante che tu abbia dei segreti
quei segreti dovrebbero essere protetti loro
dovrebbe essere usato in determinati scenari
di cui parlerò nelle prossime diapositive
e prima di iniziare a preoccuparmi, revoco
questi dopo aver fatto lo screenshot che è
valido anche se qualcuno trova il
diapositive online e sono come oh mio dio
questo ragazzo ha messo segreti sulle sue diapositive cosa
Al diavolo sta facendo è ok loro
revocato non ti preoccupare
Twitter è un esempio di pubblico
servizio chiunque può costruire un client chiunque
puoi registrarti con Twitter puoi anche
usa la stessa cosa in un’azienda
l’architettura che nessuno ti impedisce
eseguendo il proprio server di autorizzazione
che è usato solo all’interno del tuo
impresa per i vostri clienti e il vostro
server delle risorse in questo caso
probabilmente non ho questo pubblico
interfaccia di registrazione in quel caso tu
probabilmente qualcuno responsabile per
gestione del server di autorizzazione e lui
registra i clienti lui o lei
li registra per gli sviluppatori che chiedono
per farlo, questo è un open
sistema l’altro l’impresa
sistema è più di un sistema chiuso così
ci sono due diverse modalità di implementazione
ma i principi sono gli stessi di cui hai bisogno
per registrare il cliente è necessario dire al
server di autorizzazione di cui ha bisogno la roba
da inviare alla fine del flusso a
l’ URI di reindirizzamento è davvero importante
parliamo delle proprietà parliamo
su diversi clienti ne ho tre
Gli scenari che voglio coprire sono di più
ma ho solo una quantità limitata di tempo
quindi ho dovuto fare una selezione che sto per fare
concentrarsi su tre flussi importanti da fare
capisci come funziona
il primo flusso è pubblicità spudorata
dalla seconda a sinistra, ma non importa
il primo cliente vuole mostrare un numero
di tweet da un feed su un sito web, così noi
voglio essere in grado di selezionare quello che voglio
mangiato è in questa strada e voglio
mostra che sul sito web abbastanza semplice
giusto quello che dobbiamo fare è chiamare il
API di Twitter e
ottenere quel tweet di informazioni che possiamo
fare in modo che le credenziali del cliente lo facciano
ciò che usa una terminologia piuttosto complessa
ma portami con me e noi lo capiremo
fuori così il cliente è di nuovo qui
è un sistema di back-end, è solo un
sistema e il client va al
server di autorizzazione usando il suo client
credenziali
ricorda quel segreto cliente che abbiamo ottenuto
da Twitter questo è il momento in cui
lo usi dal tuo sistema di back-end
da un ambiente sicuro vai al
server di autorizzazione e tu chiedi posso
ottenere un token di accesso qui è la prova che io
sono davvero questo cliente questo è il mio
identificatore e questo è il mio segreto e il
server di autorizzazione quando tutto
controlla assegni i clienti o dà
il client è un client di accesso in
turn usa quel token di accesso per andare al
server delle risorse hey posso ottenere questa lista
di tweet da questo account che è
informazione pubblica e la risorsa
server dice oh sì, certo che qui è il
dati
ovviamente dopo aver effettuato una corretta
decisione di autorizzazione questo è il
il più semplice dei flussi OAuth che potresti
ricorda che ho detto di cosa si tratta
delegazione non c’è niente
delegato qui questo è l’accesso diretto
essenzialmente da un client a un server
c’è comunicazione macchina-macchina
nessun utente coinvolto perché non lo è
necessario in questo tipo di scenario veloce
Panoramica sarò costruire noi up
in tutti i prossimi due scenari così
la concessione di credenziali client è per
accesso diretto dall’applicazione client
ricorda questo è macchina da lavorare
non c’è nessun utente coinvolto che tu possa ottenere un
token di accesso è possibile accedere a una risorsa
è tutto ciò che succede in nome di
il cliente ci porta al secondo
Scenario e se vogliamo pianificare
tweets per conto dell’utente che è a
caso molto legittimo abbiamo visto il buffer
esempio se vuoi costruire qualcosa
così abbiamo davvero bisogno di un modo per chiedere
l’ utente hey possiamo accedere al tuo
Account Twitter in modo che possiamo effettivamente
Pubblica tweet a tuo nome in quel momento
lo fai per esempio con il
il codice di autorizzazione garantisce che sia basato su a
codice lascia che ti spieghi come funziona
quindi puoi vedere che è già un po ‘di più
complicato ci sono diverse parti
coinvolto il cliente in questo caso cliente
in fondo c’è ancora un tag e un web
domanda e questo sarà importante
più avanti in questo flusso perché abbiamo ancora bisogno
di utilizzare un segreto e si può usare solo questo
segreto ed è
memorizzato in un luogo sicuro e a
il back-end è considerato sicuro quindi
il cliente sta per richiedere l’accesso
in genere ciò implica che il browser sia
innescando un reindirizzamento che va
attraverso il browser verso il
autorizzazione del server di autorizzazione
server sta per presentare all’utente
una pagina se è Twitter chiederà
tu chi sei se già ti conosce
quindi se sei già un disco autenticato
che può essere saltato ma in generale a
ti chiedo per favore accedi al tuo Twitter
account su Twitter stesso perché il
server di autorizzazione qui nel nostro esempio
quello è Twitter che accedi e poi il
server di autorizzazione chiedi who’s Mac hey
questo buffer di applicazioni sta provando
per accedere al tuo account Twitter
voglio davvero che tu voglia autorizzare
quello e poi il cliente dice oh sì
certo che è quello che intendevo farti
fare clic su Sì, ora i servizi medici sono
interessante quindi hai autorizzato
autenticato e autorizza i clienti così
Emetterò un codice di autorizzazione
e lo farà con a
reindirizzare attraverso il browser verso
questo URI di reindirizzamento che è stato
registrato prima così il cliente durante
registrazione dice se vuoi mandarmi
qualcosa lo manda qui e questo è quello che
il server di autorizzazione userà qui
per inviare questo codice di autorizzazione a questo
per questioni di sicurezza altrimenti potresti
ingannarlo per inviarlo all’attaccante
che non dovrebbe accadere
questo codice di autorizzazione non concede
qualsiasi accesso non è un token quindi il
il cliente scambia quel codice di autorizzazione
in un token di accesso questo passaggio di scambio
9 e 10 richiedono l’uso del client
credenziali è qui il cliente
in realtà deve autenticare il
server di autorizzazione e ricordati di me
questa cosa buffer e questo è ciò che è mio
segreto che tu mi hai dato io ho questi a
Dimostralo che sono davvero io e posso farlo ora
ottenere un token di accesso in cambio di questo
codice di autorizzazione ancora più che puoi
anche ottenere un token di aggiornamento ma sto andando
per parlarne in un secondo con quello
token di accesso che l’applicazione può ora
accedere a questo server delle risorse in modo che possa
ora vai a questa API di Twitter e dì oh a
postare per conto di Filippo per favore
e vai e questo è il modo
la delega funziona in OAuth, quindi cosa noi
realizziamo davvero tanto è che permettiamo a
utente per autorizzare un cliente ad accedere
le risorse per loro conto è questo
ciò che è tutto in questo flusso è questo
il flusso più sicuro in molto perché esso
implica l’autenticazione del client passaggio 9
e 10 qui richiedono il client da utilizzare
le sue credenziali sono davvero importanti
non esiste in altri flussi che noi
parleremo nel prossimo scenario
importante anche il codice di autorizzazione
qui è valido solo da una volta
per un periodo di tempo molto breve così
di solito è come un minuto quindi hai un
minuto tra ricevendolo qui per fare
quella chiamata che dovrebbe essere abbastanza anche su
sistemi lenti se stai impiegando più tempo
di un minuto lì probabilmente hai bisogno di farlo
aggiustare alcune altre cose prima di usare molto
e questo è ciò che questo flusso ha da offrire
se si vuole guardare quella dalla
prospettiva del browser questo è ciò che il
l’utente vedrebbe effettivamente così vedi
applicazione del buffer in questo caso
chiedendoti puoi collegare il tuo Twitter
profilo alla mia domanda e se tu
fai clic sul pulsante per inviare una chiamata
al backend del buffer come oh yeah I
voglio collegare il mio account Twitter e
inizierà questo flusso con a
reindirizzare in modo da non vedere quello invece
si finisce con una pagina dal
server di autorizzazione quella pagina dal
il server di autorizzazione ti chiederà di farlo
login se necessario che potrebbe essere saltato
tu autentichi e poi il
server di autorizzazione chiede che fate voi
voglio davvero permettere questo sì che faccio
ok ecco il codice veramente reindirizzato
torna al back-end del client
applicazione che ora può scambiarla
e accedere alle risorse protette che
è ciò che l’ utente vede vede così ti connetti
vai su Twitter molto importante
è molto importante per te
in realtà andare alla festa che dovrebbe
assistere il cancello non si fa questo non lo fa
capita sotto il cofano è in realtà molto
fattibile sei reindirizzato su Twitter
e tu fai tutto ciò che devi fare lì
come utente ho menzionato il cliente
ottiene anche un token di aggiornamento che non ho intenzione di
parlare più dettagliatamente di ciò a
il token di aggiornamento consente al client di ottenere un
nuovo token di accesso in seguito, quindi accesso
i token di solito sono di breve durata
se il buffer riceve un token di accesso
Twitter è caduto per dirlo 10
minuti in modo che possa accedere all’API per 10
minuti e poi scade boom non di più
accedi lì onestamente se voglio twittare
qualcos’altro domani ne avrà bisogno
accedi di nuovo ma non sono presente
domani perché probabilmente sono su un albero
su un treno così invece di dover chiedere
me puoi darmi un altro token di accesso
attraverso il buco
elaborare questo flusso con un token di aggiornamento
chiedere al cliente di ottenere un nuovo token di accesso
l’utilizzo di quel token di aggiornamento può andare a
server di autorizzazione e dire come hey
ricorda che mi hai dato questo gettone di aggiornamento
un paio di giorni settimane mesi anni fa
Voglio usarlo per ottenere un nuovo accesso
il server di autorizzazione token può controllare
tutto dà al cliente un nuovo accesso
token e client possono indipendentemente
accedere all’account per conto di
utente di nuovo è ciò che un token di aggiornamento
autobus e naturalmente è possibile accedere al
server di risorsa se si vuole entrare in
i dettagli sporchi di come funziona è
tutto bene basato su HTTP, chiamiamolo
Tutto basato su HTTP dovrebbe essere HTTPS
ma il protocollo è HTTP, quindi si invia
loro una richiesta di questa autorizzazione
server su Twitter e tu lo indichi
vuoi eseguire questo codice di autorizzazione
concedimi per me lo faccio specificando
codice come un tipo di risposta come mi aspetto un
codice come risposta fornite al cliente
ID tu fornisci l’URI di reindirizzamento qui come
bene che dovrebbe corrispondere a quello che tu
registrato prima e un dettaglio finale è
c’è un parametro di stato di nuovo tempo
entrare nei dettagli, ma si dovrebbe sempre
usa il parametro di stato che impedisce
alcuni attacchi mettono un valore casuale
lì e controllarlo ogni volta che
il flusso è completato è sufficiente, ma se tu
voglio saperne di più su quella conversazione per me
più tardi e se tu se il flusso completa
se l’utente ha autorizzato l’autorizzazione
l’applicazione questo è ciò che torna
attraverso il browser verso il
applicazione client in modo da vedere che questo
questo URL qui è usato qui per creare il
chiama la pagina PHP di callback che riceve
questo codice, che ora posso usare per
scambiare quello per un token di accesso sul
server di autorizzazione che scambia funziona
così è una richiesta di back-channel così
non passa attraverso il browser
contro server a server in modo che possa
usa semplicemente un post che usa il
intestazione di autorizzazione è di base a
trasmetti le credenziali del cliente che sono
incorporato in là e fornisce il
codice che ha ottenuto prima che il codice sia qui
la richiesta le idee del cliente di nuovo qui
e il tipo di concessione indica che il
client vuole scambiare questo codice in
un token di accesso e questo è il
flusso di concessione del codice di autorizzazione che è
il più complesso per essere onesti ma anche
il più sicuro
oh si, mi dispiace la risposta contiene il
token di accesso che può essere utilizzato per accedere
risorse protette e anche l’aggiornamento
token come si può vedere qui tutto bene sono
ancora bene ancora e poi possiamo parlare
su alcune altre cose quindi per ricapitolare il
la concessione del codice di autorizzazione è delegata
accesso a un’applicazione di back-end che può
essere utilizzato solo su ponte e applicazioni
perché, perché usi questo cliente
credenziali per scambiare questo codice per a
token se si desidera farlo su un client
su un browser web su un’applicazione mobile
sarebbe necessario codificare il tuo segreto
applicazione internet, così sta andando
prendere qualcun altro come due minuti per
in realtà lo escludono e impersonano
il tuo cliente quindi non dovresti mai
mai farlo così questo codice è solo
sviluppato se il tuo cliente può archiviare
segreti in un modo sicuro che significa se lo è
un’applicazione back-end molto importante in modo
Lee anche la ragione per cui solo questo flusso
ti dà un token di aggiornamento perché è
l’ unico flusso che consente al cliente di
autenticarsi per l’autorizzazione
scenario del server numero tre invece di
costruire questo back-end PHP che nessuno
Piace davvero che vogliamo costruire un moderno
Front-end JavaScript che abbiamo come a
centinaia di quadri tra cui scegliere
ne sceglieremo uno e costruiamo il nostro
front-end utilizzando tale framework e in
il nostro front-end vogliamo migliorare l’interfaccia utente
di Twitter, vogliamo renderlo possibile
per interagire direttamente con alcuni tweet
vogliamo che l’utente risponda ai tweet
cose del genere quindi abbiamo bisogno di accesso
l’api ha di nuovo bisogno di accesso
retweet accesso per inviare nuovi tweet o
risposte o qualsiasi altra cosa diamo un’occhiata
come possiamo fare il flusso che stiamo andando
usare qui è il flusso implicito delle sovvenzioni
Ecco come funziona
nota che un client è un front-end
l’applicazione il tuo cliente è un web
applicazione di una pagina Web nel browser
ora sono i tuoi clienti che non abbiamo un
back-end perché non ne abbiamo bisogno
perché il nostro cliente è un front-end
Applicazione JavaScript che sta per fare
interagire con Twitter direttamente senza necessità
per il nostro back-end non serve il nostro
dati poiché interagiamo solo con Twitter
in modo che il cliente sta andando chiedere l’accesso
in genere accade all’interno del
browser quindi non c’è reindirizzamento qui è
solo una navigazione per l’autorizzazione
server
chiederà all’utente di autenticarsi
proprio come prima chiederà all’utente di farlo
autorizzare l’applicazione proprio come
prima di ogni volta che controlla il
il server di autorizzazione torna a questo
reindirizzare l’URI con un token di accesso
tempo non un codice di autorizzazione ma un
accedi direttamente al token e quell’accesso
sovvenzioni gettone questo accesso client al
server delle risorse e siamo pronti per partire
con questo token di accesso al punto sette noi
puoi leggere i tweet che possiamo permettere al
utente per digitare una risposta e possiamo postare
quella risposta su quel server delle risorse
usando quel token di accesso che è ciò che il
implicito ci ha afferrato dagli utenti
prospettiva l’utente vede una pagina da
il client questo è il nostro JavaScript
l’applicazione front-end fa clic su un pulsante
come oh yeah apri i miei piedi e poi il
il flusso inizia così siamo navigati verso
Pagina server di autorizzazione dove siamo
chiesto di autenticare se necessario noi
viene chiesto di approvare l’ applicazione se
necessario mai inviato a una pagina da
quella applicazione front-end che la pagina può
ora estrai il token di accesso da
URL e accesso a risorse protette
direttamente e questo è ciò che è implicito
concedere il flusso fa se si guarda il
richieste dietro a questo puoi vederlo
sembrano molto simili e noi chiamiamo ancora
lo stesso endpoint ma invece di codice noi
ora dillo che vogliamo e gettiamo dentro
risposta quindi questo dice l’autorizzazione
server stiamo eseguendo questa concessione implicita
flusso non stiamo facendo questa autorizzazione
codice che garantisce ma una concessione implicita a noi
fornito un ID cliente che è l’unico
cosa legare questo al nostro cliente e noi
di nuovo fornito un reindirizzamento si arriva il
la risposta arriverà a quel reindirizzamento
URI fornirà un token di accesso
nella risposta direttamente non aggiorna
segno molto importante dettaglio nota come
questo è un hash e non un punto interrogativo
questo significa che questo è parte del
frammento e il frammento delle URI è
mai inviato al server ogni volta che il
il browser carica l’URL con un frammento
quel frammento rimane nel browser
il browser invia solo ciò che è prima
quello al server e lo carica
risorsa ma un frammento fa parte del
URL ma non viene mai inviato tramite la rete
quindi qui questo ha senso perché il
il token di accesso è destinato a essere utilizzato su
il lato client e questo è quello che siamo
facendo qui non ci sono passaggi aggiuntivi
ovviamente questa cosa diventa un po ‘complicata
se il token di accesso scade perché quello
implicherebbe che tu debba eseguire il
Flusso di nuovo ma ancora una volta è molto
dibattito acceso in questa comunità su come
per gestire questi casi e non lo farò
entra nei dettagli lì quindi se lo guardi
questo dal punto di vista generale
delegato la concessione implicita ti dà
accesso delegato a un front-end
applicazione mai e poi mai usare questo
flusso quando si utilizza anche un back-end
perché le cose andranno male posso
garantire che molte applicazioni
per errore, eseguono l’implicito
concedere per e quindi prendono l’accesso
token e spedirli a loro
back-end e poi fanno qualcosa in
il back – end attraverso quel token di accesso se
lo fai correndo seriamente
problemi quindi per favore non farlo sempre
scegli il flusso appropriato per il tuo scenario
I token di accesso molto importanti sono
ottenuto direttamente tramite il reindirizzamento
attraverso il frammento dell’URI e a
anche l’applicazione front-end non lo è
dovrebbe avere accesso per l’aggiornamento
token perché i front end sono di
definizione insicura So che le persone
pensa come si, ma è a
Framework JavaScript e lo voglio davvero
questo accesso a lungo termine e lo farò
questo comunque modificherò il flusso a
bit per dare un token di aggiornamento che è un male
idea perché il token di aggiornamento è solo
emessi nell’altro flusso perché questo
richiede l’ uso di questo segreto del cliente
che nessuno dovrebbe sapere tranne il tuo
client quindi se inizi a utilizzare l’aggiornamento
token senza segreti del cliente
sbagli e ti stai aprendo
voi stessi per serio
vulnerabilità se qualcuno lo ruba
hanno accesso eterno a questo
sistema di back-end fino a quando non esplicitamente
revocare ciò se è possibile
e questo conclude il cliente
prospettiva so che questo è molto breve
panoramica quindi sarò molto felice di rispondere
tutte le domande dopo il discorso se ne hai
di più specifici parliamo di
prospettiva del servizio di risorse se sei un
server delle risorse si ottiene un token di accesso
e tu dovresti prendere una decisione
con quel token di accesso
nota che il token di accesso è inviato a
tu dal cliente uno dei comuni
idee sbagliate è che i clienti sono
dovrebbe leggere l’accesso e supposto
per capire cosa significano
ma per quanto riguarda il cliente è interessato
il token di accesso può anche essere
dinosauro non importa quello che è
può essere dinosauro un cane da uccello o un po ‘funky
token qualunque cosa non importa cosa
è importante che il server delle risorse possa
fare qualcosa con esso
questi sono due token di accesso perché tu
hanno due tipi diversi comunemente usati
in OAuth un tipo è chiamato riferimento
gettone e l’altro è chiamato a
discorsi autosufficienti di questo tipo
il token di riferimento è prima un riferimento
il token è in realtà solo un identificatore
è un identificatore che punta a a
pezzo della nostra serie di metadati tenuto dal
server di autorizzazione così ogni volta che tu
Dillo a un cliente che non sei
divulgare informazioni sensibili
gli stai solo dando un identificatore e
l’identificatore verrà in seguito utilizzato da
il server delle risorse per recuperare le informazioni
dal server di autorizzazione e con
questa informazione può prendere una decisione
e quel processo è chiamato token
l’introspezione è una delle cose
in OA che è stato specificato un po ‘più tardi
rispetto alla specifica principale ecco come token
l’introspezione funziona così tu hai il tuo
client hai il tuo server delle risorse e
hai il tuo server di autorizzazione loro
hanno diversi endpoint in questo caso
è un endpoint del token che viene utilizzato
così ovunque il cliente acceda a
risorsa protetta con un riferimento
token invia semplicemente questo identificatore
in un modo o nell’altro di solito è il
intestazione di autorizzazione con lì e poi
l’ identificatore lì dentro la risorsa
il server usa quello per scambiarlo
identificatore in un insieme di set di metadati di
rivendicazioni memorizzati su questo utente la
server di autorizzazione fornisce che e
con quelle rivendicazioni il server può fare un
decisione di controllo di accesso che è richiesta
andando a dire come oh sì questo era
rilasciato per quel cliente ed è
associato a questo profilo Twitter e
sì, questo token è ancora valido, ecco un
esempio di come farlo è di nuovo un
richiesta di back-channel
è comunicazione da server a server
fai una richiesta di posta elettronica inviandola al token
hai ricevuto dal cliente che hai detto al
l’autorizzazione serve questo dovrebbe essere un
token di accesso puoi verificarlo per me
per favore ed è quello che ottieni in cambio
i servizi di autorizzazione come oh si
Conosco questi identificatori è ancora
valido è ancora attivo non è stato
ti ha revocato
non ha annullato questo token di accesso è
associato a questo particolare cliente
e associato a questo argomento questo è
un identificatore univoco per questo argomento
può essere un ID questo può essere anche questo può
essere un nome completo o qualunque sia il sistema
vuole usare e questo è ciò che token
l’introspezione è così se andiamo rapidamente
torna a questa immagine il server delle risorse
ha bisogno di fare questo round-trip ogni volta
vuole risolvere tale riferimento
token è un token di riferimento per design
è più sicuro perché il
il server di autorizzazione mantiene il controllo di
questo token ha tutti i metadati qui
quindi ogni volta che dici “oh merda” ho perso
il mio telefono e il mio telefono ha un
l’applicazione e l’applicazione hanno accesso
a Twitter e voglio revocarlo
può andare su Twitter e dire come oh si
riorientare l’accesso prego innesco la latta
dimentica quell’informazione e quello
l’identificatore ora non è più valido
uno dei poteri di usare il riferimento
token così di nuovo li confronterò
a discorsi autosufficienti e quindi a riferimenti
i token sono un identificatore che lo tengono dentro
mente pieno controllo per l’ autorizzazione
server ma richiede questo canale posteriore
richiesta in realtà facendo così
richiesta di back-channel su ogni singolo
la chiamata API in arrivo probabilmente non è la
la migliore idea che metterà un sacco di carico
sul server di autorizzazione per uno e
c’è molta comunicazione tra
servizi per ogni chiamata che devi
fare così realtà ciò che vediamo nei sistemi
implementando questo è cache
questi token di accesso o questi riferimenti
per un breve periodo di tempo in modo che il
il server delle risorse può decidere come va bene io sono
non lo risolverò ogni volta
perché abbiamo molte chiamate API così
Lo prenderò per due o tre
minuti che è accettabile, ma ovviamente
perde un po ‘ di controllo quindi se l’utente
lo revocherò nel frattempo, allora
l’ atto che lo stalker di riferimento farà ancora
essere memorizzato nella cache per due o tre minuti
questo è il rovescio della medaglia e questo è
sicuramente qualcosa che si potrebbe desiderare di
prendi in considerazione parliamo del
altro lato delle cose vi parlerò di
gettoni autosufficienti che il nome dice
contiene un token autonomo
tutto il necessario per rendere il tuo
decisioni di autorizzazione questo è ciò a
il token autonomo potrebbe sembrare così
è un token web JSON un evento di inseguimento e
Sono parlare andando circa i dettagli su
Token web JSON ma la parte importante
di un token Web JSON è il payload e a
il carico utile è un insieme di affermazioni che sono
protetto in un modo o nell’altro così
di solito un gettone web JSON è firmato a
assicurati che nessuno possa modificarli
reclami senza essere scoperti
e queste affermazioni sono generate dal
server di autorizzazione il token assegnato
dal server di autorizzazione e dal tuo
il server delle risorse può usarli per decidere
è consentito o meno ciò di cui ha bisogno
per fare è necessario verificare il
firma di questo token e ogni volta che
firma controlla che può guardare il
dati lì come oh sì, questo era
Philippe ha fatto quella richiesta oh sì no
no ed è davvero per il cliente giusto
così e viene da Twitter quindi sì, lo sono
fidarsi di questi dati che deciderò
sì, a Philippe è permesso fare o il
il cliente è autorizzato a fare questa chiamata
per conto di Philippa per pubblicare questo tweet su
quella timeline di Twitter e questo è il
lavoro del server delle risorse grande vantaggio
autosufficiente significa no roundtrip voi
non devi tornare al
server di autorizzazione più e più volte
per controllare qual è questo identificatore oh sì
grazie no, puoi farlo semplicemente con
il token stesso così vinci molto
quel dipartimento
il rovescio della medaglia è che non hai alcun controllo
questi token di accesso sono
autosufficiente se l’utente va al
il servizio di autorizzazione dice che voglio
revoca questo token che puoi forse revocare
ma come sarà mai il server delle risorse
sappi che è revocato non c’è
comunicazione più così finché questo
il token rimane abbattuto esso può essere usato da
tutti coloro che hanno accesso a quel token così
se posso rubare il tuo token e rimane
valido per cinque mesi, quindi puoi averlo
cinque punti quattro mesi perché io ora
avere cinque mesi di accesso a questo
API back-end nel tuo nome che è molto
problematico quindi questi token dovrebbero essere
di breve durata è una delle primarie
considerazioni di sicurezza nel
le specifiche utilizzano un accesso di breve durata
gettoni e la gente implementare questo in
vita reale nell’idea, indipendentemente dalle due settimane
buono per andare oh sicuro che funzioni, ma lì
sono sicuramente rischi e coinvolti
che se non sbaglio è il recente
I problemi di Facebook erano legati all’accesso
token e penso che fossero validi
60 giorni
quindi sì, ci sono dei rischi coinvolti lì
quindi un token autonomo contiene tutto
i metadati necessari per prendere decisioni
sono memorizzati sul client
quindi sono fuori liberati dal
server di autorizzazione che significa che tu
non può facilmente revocarli, ci sono
meccanismi per farlo, ma lo sono
difficile sono risorse ingannevoli
i server devono verificare l’integrità di a
token autonomo prima di usarli
molto molto importante se lo dimentichi
le cose andranno davvero in giro
rapidamente questo è l’uso dei token di accesso
potresti aver notato nella richiesta
prima c’era questo parametro
chiamato ambito mi sono sfiorato perché io
Sapevo che ne avrei parlato più tardi
quindi non ho menzionato prima che gli ambiti lo siano
in realtà una proprietà piuttosto interessante
perché l’ambito consente di limitare
le autorizzazioni associate a un
accedi al token quindi se richiedi un accesso
token come client è possibile fornire il
portata remota come autorizzazione hey
server Voglio accedere a questo account e
Voglio leggere l’accesso o l’accesso in scrittura
e il server di autorizzazione sta per
chiedi all’utente che questa applicazione sta provando
per accedere al tuo account che vuole
leggi il tuo feed Twitter e scrivi
messaggi al tuo feed Twitter fai tu
voglio quello e tu puoi decidere di sì o no
e se non vuoi che tu scelga no
ovviamente e l’intero flusso fallisce con
un errore e se si fa clic su Sì allora
il server di autorizzazione assocerà il
Questo è l’ambito con il token di accesso
molto utile un esempio molto pratico in
vita reale ho comprato uno scanner che può
scansione su Evernote che pensavo fosse
una caratteristica molto interessante non più manuale
mettere le cose in Evernote e quando io
sistemarlo ha usato molto e ha chiesto
accesso completo al mio account Evernote come
hey possiamo leggere tutti i tuoi appunti e
quaderni e possiamo scrivere note ed è stato
come perchè hai bisogno di leggere tutto questo
informazioni mia moglie intera è lì dentro
Non ho intenzione di darti accesso
soprattutto non perché l’altro
il software fa schifo quindi non sono sicuro che sia tuo
quale implementazione andrà bene
quindi in realtà queste cose funzionano
gli ambiti di pratica non sono definiti in cosa
l’ OAuth ci specifica come si puoi mettere
i tuoi ambiti in questo parametro ma si
Metti messo lì qualunque cosa tu
sei andato a guardare un esempio reale questo
è come gli utenti chiedono le autorizzazioni
per esempio slick questi sono gli ambiti
offerto da selezionabile molto piccolo
parte degli ambiti che hanno scelto
per avere ambiti a grana molto fine basati
sugli oggetti e il livello di accesso
quindi ad esempio hai un problema artistico
che dà il giusto accesso ai canali e
questo è associato a questo metodo
se si desidera utilizzare uno di questi metodi
hai bisogno di accedere alla scrittura l’ambito necessario
concesso dall’utente e loro fanno un
distinzione tra clienti connessi all’utente
e entrambi i client correlati di nuovo così
l’utente ha una buona idea di cosa
esattamente lui sta concedendo a un cliente e
la migliore pratica per un cliente è
Richiedi tutti gli ambiti che puoi ottenere come
piccoli ambiti in cui puoi cavartela
mi dispiace come pochi ambiti che puoi ottenere
via con così se stai solo mostrando
tweets a un utente non ha senso in
chiedendo per l’accesso in lettura e scrittura solo
chiedere un accesso root è molto importante
considerazione in pratica puoi andare
completamente pazzo con scope quindi se il tuo
Google hai un sacco di api che hanno
scelto di utilizzare gli URL come ambiti così di
certo se richiedi come 25.000 di
loro probabilmente sarà molto lungo
richiesta ma non dovresti farlo
che probabilmente non stai costruendo un
cliente che ha bisogno sia dell’accesso a Google
Analitici e fogli di lavoro di Google Documenti
allo stesso tempo, probabilmente mi non lo faccio
sai cosa stai costruendo ma ottieni
l’idea ma puoi vedere interessante
cose come te hanno pieno accesso a
portata dell’analisi come vista e gestione
dati ma hai anche un ambito di sola lettura
e cose come cancellare utenti o
eliminazione di richieste o eliminazione di dati da
l’analisi è un ambito separato che è
nemmeno parte della vista e gestisci
portata dei dati perché è così sensibile
che lo hanno esplicitamente messo separatamente
e ancora se richiedi un accesso a
commettere solo l’ambito di sola lettura e
qualcuno riesce a rubare il peggio
possono fare è leggere i dati almeno loro
non è possibile cancellare o modificare alcun dato
di nuovo è la tua responsabilità come
implementatore del client per scegliere il
Ambiti che si adattano al tuo cliente e da mantenere
loro come minimo come
e quando lo fai questo meccanismo
funziona davvero abbastanza bene, certo che lo è
la responsabilità della risorsa
server per controllare questi ambiti che sono
parte dei metadati associati a a
gettone
così ogni volta che il token entra nel
server delle risorse si controlla quello che sei
cercando di fare
Pubblica il tweet hai accesso in scrittura
si va bene a parte gli altri assegni
che è fatto, naturalmente, è così
gli ambiti effettivamente funzionano molto bene
contenere le autorizzazioni associate a un
accedi al token fino ad ora per immergerti in Ord
parliamo di open early connect a
la dichiarazione in fondo potrebbe non essere
molto accurata Sono pienamente consapevole di ciò
ma aperte ID Connect è di circa
autenticazione perché come si fa
l’autenticazione con tutte le probabilità non è possibile
davvero evolvono le persone pensano di poter fare a
un po ‘in realtà è molto difficile quindi
se si esegue questo foro o deflusso al
terminare la cliente ottiene un token di accesso è
potrebbe recuperare le informazioni dell’utente con quello
token di accesso che è in genere come
l’autenticazione è implementata ma lo è
quell’asiatico davvero autentico come fai tu
sapere se l’ utente è autenticato correttamente
è un po ‘implicito perché presumi
che il server di autorizzazione ne faccia un po ‘
forma di autenticazione ma è fresca
quando l’utente intende kay, forse l’utente
fatto cinque mesi fa e la sua sessione
con il server di autorizzazione è ancora
valido vale come un
autenticazione per il client se il
client usa questa informazione utente a
autenticare l’utente è un compagno
autenticazione non proprio e tutti
il cliente commette un errore, quindi non lo fai
anche sapere se il token di accesso è
è caduto e finalmente dove prendi
quella informazione utente su Twitter è su quello
endpoint e su Facebook è su quello
endpoint e poi hai Google è
su quell’endpoint e ottieni l’ idea
quindi se vuoi implementare questo login
con Facebook Twitter e Google sei
molto probabile che abbia tre diversi
implementazioni che tutti odiano
nessuno lo vuole così persone in realtà
incasinare questo davvero davvero male e
è qui che entra in gioco Connect aperto
operato Connect è costruito su poet it
segue lo stesso principio di delega
ma invece di risultare in un accesso
token risulta
l’emissione di un token di identità così il
il client avvia nuovamente il flusso
richiede informazioni sull’identità all’utente
autentica concede l’accesso e nel
fine il server di autorizzazione dà un
token di identità per il cliente e quello
il token di identità sta per contenere
informazioni su chi è l’utente quando
lui autenticato e un altro
proprietà e con ciò il cliente può
decidere di perché questo tizio si o no
e se è che autorizzo o
autenticare questo utente e se non lo è
Devo rifiutare questo e questo è quello
open ID Connect è in realtà di
Certo che potresti voler ottenere di più
informazioni da parte dell’utente e questo è
per cosa si dispone l’endpoint di informazioni utente
un ID aperto Connect invece di consentire
il server di autorizzazione per scegliere come
sì, lo metteremo ovunque tu
non voglio se stai già implementando
connetti fornisci un endpoint che è
chiamato informazioni utente non domande che è
proprio come funziona e questo è dove il
il cliente può effettivamente ottenere quell’informazione
da e questo è costruito su parte perché
ha usato scorre, ma si fa un sacco di
decisioni per te dove oh è molto
apri come qui puoi usare questo
meccanismo lo implementa come vuoi tu
Connect afferma apertamente che è così che si fa
questo è ciò che ottieni da questo è
dati nel token di identità e cioè
come si implementa questo e questo diventa
influenze Google interoperabili se tu
accedi con Google stai usando OpenID
Connetti ma se ne userai altri
servizi se implementano anche OpenID
Connetti è la stessa implementazione
che è molto bella e molto pulita in
la tua applicazione questo è un esempio di
un token di identità che potresti riconoscere
il formato ora è di nuovo un JSON
web token è firmato da
server di autorizzazione quindi se vuoi
Selezionare Login con Google si otterrà un
token di Google ed è firmato da
Google quindi sei l’applicazione client
puoi verificare che questo è un token per firmare il mio
Google oh sì questo è caduto oh
si ok ora ho qualche informazione
la richiesta SUV è un identificativo univoco
rappresentando l’utente che è nel tuo
caso non molto utile perché è
ID di Google che non conosco ma anche tu
prendi questa e-mail in fondo e quella
per esempio, l’e-mail ti consente di collegarti
l’identità di quell’utente a qualcosa
tu
concetto nella tua applicazione in modo che tu possa
ora cerca nel tuo database come fa
Ho un utente con il flip alle labbra pragmatiche
carino, vieni, sì, ecco il ragazzo, quindi questo
il token è fella, viene da quel ragazzo, quindi sono
collegarlo al suo account e ora
è autenticato come Phillip in questo
applicazione buffer o qualunque cosa stia usando
puoi vedere che ce ne sono altri
affermazioni coinvolte anche qui, forse
una delle cose importanti è che c’è
un tempo di autenticazione qui così tu
sapere esattamente quando l’autorizzazione
il server è stato autenticato dall’utente e tu
può decidere è accettabile sì o no
se è una transazione di alto valore,
lo stai facendo in un’azienda
e non con il login con Google
per favore, ma in un sistema aziendale, allora
potresti voler richiedere un nuovo
autenticazione perché forse non lo è
valido se l’utente ha effettuato l’accesso ieri no
vuoi una nuova autenticazione ACR
indica la forza del
autenticazione utile per indicare
se l’utente ha utilizzato il multi-fattore
autenticazione sì o no perché
a volte potresti aver bisogno di questo e
questo è un protocollo progettato per fornire
che le informazioni ed è quello che
open ID Connect porta al tavolo aperto
la connessione iniziale si basa sull’arte e sulle offerte
tre flussi che sono in realtà molto
simile al flusso OAuth che noi
discusso prima che io vada rapidamente
su di loro e poi vado a concludere così
abbiamo tempo per una o due domande a
Alla fine c’è un flusso di sussidi impliciti
utilizzato solo per applicazioni di front-end
che non cambia mai i mezzi di concessione impliciti
autenticazione client implicita come in no
davvero l’ autenticazione del cliente solo così
front-end funziona come l’altro
fluire in modo che il cliente inizi a
flusso ma invece di dare la risposta
digita token ora dice che voglio anche un
token di identità un token ID che
indica che sto eseguendo la connessione ID aperta
qui ho bisogno di informazioni sull’identità da
l’utente da te sta per fare il
balla con l’autorizzazione dell’utente sì di
Certo e qui andiamo dà un accesso
token e un token di identità l’identità
token consente al front-end di
autenticare l’utente che in a
l’applicazione front-end non significa molto
molto ma tu hai l’idea ora puoi dire
bentornato per questo Thank You
applicazione front-end il token di accesso
a questo proposito può essere utilizzato per effettuare chiamate
a una risorsa protetta
come in quale parte è stata inserita la porta
uno in modo che tu possa effettivamente fare
qualcosa di utile dopo con le API
così non devi usare che questo
è facoltativo l’uso del token di accesso
ma spesso è fatto insieme che è il
concessione implicita anteriore e unica
il codice di autorizzazione è concesso molto rapidamente
lo stesso setup di prima del cliente
inizia l’intera danza con un reindirizzamento
ancora una volta questo non cambia è ancora
codice si va al luppolo di
autenticare la concessione dell’utente
autorizzazione con cui reindirizza
codici di autorizzazione che vanno al
client e questo è dove operandi Connect
entra in gioco il cliente ora scambia
questo codice di autorizzazione usando suppliant
credenziali e ottiene un token di identità
e un token di accesso e quell’identità
token esegue nuovamente l’autenticazione dell’utente
questo caso è un sistema di back-end quindi è così
andando a cercare nel proprio database o
eppure questo è associato a questo utente così
ora so che questo utente è loggato
invece di fare l’autenticazione
direttamente abbiamo ottenuto che le informazioni da
qui e ora sappiamo che quell’utente è
effettivamente registrato nel back-end
così abbiamo impostato la nostra sessione o qualsiasi altra cosa
facciamo e facciamo la nostra interazione di abilitazione
con l’utente e di nuovo possiamo usare il
accedi al token se vogliamo e poi il
nuovo mi dispiace
questo è per le applicazioni di back-end
quello che abbiamo coperto e poi quello nuovo è
il flusso ibrido questo è il suo bene
è nuovo ma non è davvero nuovo se tu
capire questo flusso di lavoro è giusto
ti aiuta a ottenere il token di identità più velocemente
nel client così essenzialmente ciò che fai
stai iniziando lo stesso flusso ma invece
di soli atti che richiedono un codice anche tu
chiedere un token di identità in questo passaggio
quindi faremo tutto il ballo e
otterremo un codice di autorizzazione
e stai parlando direttamente nell’URL
che lo farà finire direttamente in
il cliente che consente al cliente di partecipare
per autenticare l’utente in quel punto
senza dover fare questo spettro o
richiesta di scambio del codice per il
accedi al token ed è aperto per primo
ti fa risparmiare tempo è più veloce è di più
efficiente ed è spesso usato in
pratica a causa di questi motivi e di
Certo, allora puoi ancora ottenere il tuo
token di accesso a
accedi alle tue risorse protette quindi se
mettere questo nuovo insieme il
il token di identità è inteso per il
applicazione back-end molto importante se
stai usando questo flusso ibrido di cui hai bisogno
per garantire che questo token di identità sia
destinato al tuo cliente
ci sono molte implementazioni che
in realtà fanno questo e poi accettano
qualsiasi token di identità che abbia un significato
che se ho un cliente che tu solo
accedi con Google e se hai un
client che ha effettuato l’ accesso a Google se
non stai controllando il pubblico che posso
darti un token di identità token di accesso
rilasciato dal mio cliente e lo farai
accetta quel significato che potrei prendere
qualcosa dal mio cliente e lo uso
accedi come utente della tua applicazione
a causa di una vulnerabilità e questo è
in realtà molto molto comune in già
collegare gli scenari ed è per questo che questo è
così importante ci sono altri controlli che
deve essere fatto ma questo è veramente
davvero cruciale perché non c’è
non utilizzare nessuna credenziale del cliente
segreto nulla che collega a questo codice I
sapere che tutti sono come riempiti fino a
qui con flussi e token e codici a
ricorda che parte è un meccanismo da delegare
accesso per conto dell’utente ci sono
alcuni altri casi d’uso ma il generale
i flussi difficili consentiti permettono a
applicazione per accedere a una risorsa su
per conto del proprietario della risorsa l’utente
che è associato a quella risorsa
e questa è l’unica cosa che dovresti fare
a meno che ovviamente non ne abbiate altri
scelta ad esempio Facebook ha il loro
proprio protocollo di autenticazione sopra
dispari che non è aperto nessun collegamento ma se
hai una scelta in un set aziendale
in alto avrai una scelta se lo schiererai
il tuo server di autorizzazione se tu
bisogno di autenticazione
le radio usano la parte di connessione addy aperta
non si tratta di autenticazione intelligente
delegazione open ID connect ti offre
le informazioni sull’identità sono progettate per
autenticazione in questi modi e
in realtà gestisce un sacco di più angolo
casi rispetto a quelli che sono stato in grado di
discuti qui e questo è ciò che questi
le cose sono veramente e spero che
questa è la cosa che togli e se
c’è un’altra cosa che devi
ricorda di usare sempre il flusso corretto
guarda non è difficile quando lo sai
che devi cercare questo sguardo cosa
è il flusso corretto dall’applicazione e
effettivamente usare quel flusso adeguato e quello
conclude il discorso grazie, grazie
per ascoltare e se ne hai
domande sarei felice di rispondere loro
tu
va bene, pranziamo e basta
continua a sentire gli applausi alla fine
parlerò molto di un Freddie
connettersi forse verso la fine non lo sei
così felice più perché in realtà è un
argomento complesso
non è così facile da digerire, ma lo sono
cercherò di renderlo digeribile per te
e il mio obiettivo qui è che te ne vai via
comprensione o comprensione completa
cosa fa perché fa quello che fa e
come lo fa
Lo stesso vale per l’ open ID che sto collegando
parlare di ciò verso la fine è
costruito sopra OAuth per una particolare
scopo e questo è il da asporto
questa sessione quando parliamo di cosa
il modo migliore per introdurre questo è forse
attraverso un’analogia del mondo reale, così è
parcheggiatore qualcosa che siamo in Europa
non troppo familiare con ma negli Stati Uniti
puoi effettivamente consegnare qualcuno alla tua auto
chiave e avranno parcheggiato l’auto per te
molto facile, molto semplice, ovviamente
si sta consegnando un estraneo la chiave per
la tua auto probabilmente di lusso è così
probabilmente forse un po ‘di rischio e allora
hai in queste macchine hai un
Valorizza una chiave speciale che puoi usare
dare verso l’ ophélie e quella chiave
apre solo la porta della macchina e
avvia la macchina ma non la dà
accesso al vano portaoggetti o
il tronco quindi se hai oggetti di valore in
lì condivido documenti importanti o
valigie o qualsiasi altra cosa se li metti dentro
lì quella chiave non li concederà
l’accesso a tale risorsa e ci porta
vicino verso l’ ID di oh perché o esso
riguarda la delega dell’accesso e se a
la chiave è una sorta di delega dell’accesso a
la tua auto a qualcun altro che non lo fai
lo so davvero ma a certe condizioni
e questo è ciò che le parti portano al
tavolo e oh arte abbiamo bisogno di un
server delle autorizzazioni per gestire quella
delegazione in primo luogo un mondo reale
Ohad esempio ritmo parliamo di
qualcosa come Twitter tutti lo sanno
Twitter Ho un feed di Twitter le mie diapositive
sono disponibili attraverso il mio feed Twitter così
puoi prendere una copia da lì se tu
voglio postare le diapositive su Twitter I
utilizzare un’applicazione nota come buffer
buffer ti permette di pianificare il mio
tweets così posso metterli pronti come
Rilascio che alle 12 in punto e sto bene
andare
nel buffer di sfondo ha bisogno di accedere a
il mio profilo Twitter, quindi delegherò
accesso al buffer per accedere al mio Twitter
per
per mio conto e postare il tweet ogni volta
Dico che dovrebbe essere pubblicato se si guarda
il lato Twitter delle cose c’è a
numero di applicazioni che ha accesso
al mio feed Twitter ecco alcuni esempi
vedi i legittimi clienti di Twitter
avendo accesso ma vedi anche questo
applicazione tampone in là e alcuni
altri tipi di applicazioni che è
combattuto sul lavoro è così che cosa in realtà
fa questa cosa e quello che ci prova
raggiungere permettendoti come utente di concedere
un accesso di applicazione per conto dell’utente a
una risorsa di terze parti quindi se si guarda
una visione concettuale da un livello molto alto
faremo tutto questo possibile
attraverso il server di autorizzazione che è
sarà la componente chiave dell’insieme
di OAuth noi come utente vogliamo concedere un
accesso alle applicazioni client così nel mio
esempio da prima del buffer sarebbe il
applicazione client voglio concedere che
accesso dell’applicazione a una risorsa I
controllo per accedere a quella risorsa
il client utilizza un token di accesso che accede
il token è qualcosa che il cliente ha
ricevuta del buffer ricevuta da Twitter e
può usarlo per accedere a un protetto
risorsa nei nostri termini che è ospitata da
il server delle risorse, quindi nell’esempio
che abbiamo quello sarebbe il Twitter
API per pubblicare un tweet che sarebbe un
risorsa protetta su un server di risorse
e un token di accesso sta per concedere
accesso e il server delle risorse sta per
bisogno di un modo per verificare se il
il cliente è effettivamente autorizzato a farlo
questo è molto importante per una risorsa
il server esegue l’autorizzazione appropriata
altrimenti qualsiasi cliente sarebbe in grado di fare
qualsiasi cosa per conto di qualsiasi utente che è
sicuramente non quello che vogliamo oh arte cosa
la specifica fornisce è in realtà circa il
danza tra il cliente e un
server di autorizzazione sulla concessione
accesso e questo è in realtà potrebbe essere il
anche la verifica dell’accesso client fa parte di
cosa ma forse nemmeno il corso
i pacchetti è una specifica separata
e come utilizzare il token di accesso a
accedere al server delle risorse che non è pari
coperto da molto perché molto è puramente
sulla delega ovviamente su tutti gli altri
le cose entrano in gioco quando inizi
usando molto perché ne avrai bisogno se tu
stai costruendo un’API che dovrai controllare
autorizzazione e prendere decisioni e
cose del genere, ma tenere a mente che
è solo basato sui meccanismi
fornito da ODS ma non parte del coart
stessa immagine qui mostra uno molto
cosa strana abbiamo un cliente uno
server delle risorse, quindi perché andare al TRO
di creazione permesso di fare quel lavoro
probabilmente non ne vale la pena
perché è abbastanza complesso da ottenere questo
lavorando e puoi fare degli errori
contro quello, naturalmente, questo paga davvero
fuori in un paesaggio dove tu hai
più clienti hai cose come
tampone che è un sistema di back-end si
avere cose come un front-end mobile
applicazione hai un’applicazione web
tutti questi possono essere clienti della stessa
parte protocollo o Oh nostro framework e di
Ovviamente hai più risorse
tutti i server offrono diversi tipi
di risorse API diverse è diversa
tipi di risorse e tutti hanno bisogno di
prendere decisioni di autorizzazione che è
che architettura OAuth ad alto livello
sembra come prima che ci tuffiamo nel
dettagli su come questa delegazione in realtà
capita una piccola parola su di me, io sono Filippo
mazzo grazie per l’introduzione
nessuno e io sono un allenatore sul web
sicurezza quindi insegno agli sviluppatori come
costruire meglio e più sicuro
applicazioni che faccio tutto il
mondo e sotto la mia compagnia web pragmatico
sicurezza che è il mio veicolo per fare
quello
Sto anche organizzando la Second Life
corso che è un corso in Belgio a
settimana di sicurezza per gli sviluppatori che sono
insegnato da esperti di tutto il mondo
Sono un esperto di sviluppatori Google che
significa che Google mi riconosce per il mio
contributi con sicurezza al
comunità ma non sono impiegato da Google
o non affiliato con Google in alcun modo
proprio come un disclaimer perché le persone tendono
per ottenere confuso circa che altrimenti
parliamo molto di più
complesso ma anche di forse di più
interessante mi avvicinerò molto
da due punti di vista diversi io sono
andando a parlare del cliente
prospettiva prima cosa significa
essere un cliente cosa devi fare
in realtà ottenere questo flusso iniziato e ottenere
questo token di accesso e ora sto andando a
parlare di un server di risorse
prospettiva come puoi autorizzare a
client che sta tentando di accedere a
un’API torna all’esempio di Twitter quindi se
vuoi costruire un client OAuth
costruirlo non è difficile ma se tu
voglio usarlo con una vera autorizzazione
server è necessario registrare il
client e nel caso Twitter questo
significa registrarsi per lo sviluppatore di Twitter
account che è proprio come fare clic su a
tasto e cliccando l’ok in una e-mail
questo è tutto e quindi è necessario
registra il tuo cliente con alcuni dettagli così
è necessario fornire un nome questo è
generalmente noto come identificatore del client
è necessario fornire un URL e in particolare
un URL di richiamata quindi devi dirlo al
server questo è dove devi inviare
qualcosa se qualcosa ritorna da
tutto questo flusso stiamo andando parlare su
quello dopo perché quello realmente conta e
una volta che lo fai, ricevi da Twitter
ottieni i segreti dei tuoi clienti che puoi
tipicamente ottengono un token di accesso e a
twitter segreto utilizza due diversi
segreti ma ciò non importa
qui o è importante che tu abbia dei segreti
quei segreti dovrebbero essere protetti loro
dovrebbe essere usato in determinati scenari
di cui parlerò nelle prossime diapositive
e prima di iniziare a preoccuparmi, revoco
questi dopo aver fatto lo screenshot che è
valido anche se qualcuno trova il
diapositive online e sono come oh mio dio
questo ragazzo ha messo segreti sulle sue diapositive cosa
Al diavolo sta facendo è ok loro
revocato non ti preoccupare
Twitter è un esempio di pubblico
servizio chiunque può costruire un client chiunque
puoi registrarti con Twitter puoi anche
usa la stessa cosa in un’azienda
l’architettura che nessuno ti impedisce
eseguendo il proprio server di autorizzazione
che è usato solo all’interno del tuo
impresa per i vostri clienti e il vostro
server delle risorse in questo caso
probabilmente non ho questo pubblico
interfaccia di registrazione in quel caso tu
probabilmente qualcuno responsabile per
gestione del server di autorizzazione e lui
registra i clienti lui o lei
li registra per gli sviluppatori che chiedono
per farlo, questo è un open
sistema l’altro l’impresa
sistema è più di un sistema chiuso così
ci sono due diverse modalità di implementazione
ma i principi sono gli stessi di cui hai bisogno
per registrare il cliente è necessario dire al
server di autorizzazione di cui ha bisogno la roba
da inviare alla fine del flusso a
l’ URI di reindirizzamento è davvero importante
parliamo delle proprietà parliamo
su diversi clienti ne ho tre
Gli scenari che voglio coprire sono di più
ma ho solo una quantità limitata di tempo
quindi ho dovuto fare una selezione che sto per fare
concentrarsi su tre flussi importanti da fare
capisci come funziona
il primo flusso è pubblicità spudorata
dalla seconda a sinistra, ma non importa
il primo cliente vuole mostrare un numero
di tweet da un feed su un sito web, così noi
voglio essere in grado di selezionare quello che voglio
mangiato è in questa strada e voglio
mostra che sul sito web abbastanza semplice
giusto quello che dobbiamo fare è chiamare il
API di Twitter e
ottenere quel tweet di informazioni che possiamo
fare in modo che le credenziali del cliente lo facciano
ciò che usa una terminologia piuttosto complessa
ma portami con me e noi lo capiremo
fuori così il cliente è di nuovo qui
è un sistema di back-end, è solo un
sistema e il client va al
server di autorizzazione usando il suo client
credenziali
ricorda quel segreto cliente che abbiamo ottenuto
da Twitter questo è il momento in cui
lo usi dal tuo sistema di back-end
da un ambiente sicuro vai al
server di autorizzazione e tu chiedi posso
ottenere un token di accesso qui è la prova che io
sono davvero questo cliente questo è il mio
identificatore e questo è il mio segreto e il
server di autorizzazione quando tutto
controlla assegni i clienti o dà
il client è un client di accesso in
turn usa quel token di accesso per andare al
server delle risorse hey posso ottenere questa lista
di tweet da questo account che è
informazione pubblica e la risorsa
server dice oh sì, certo che qui è il
dati
ovviamente dopo aver effettuato una corretta
decisione di autorizzazione questo è il
il più semplice dei flussi OAuth che potresti
ricorda che ho detto di cosa si tratta
delegazione non c’è niente
delegato qui questo è l’accesso diretto
essenzialmente da un client a un server
c’è comunicazione macchina-macchina
nessun utente coinvolto perché non lo è
necessario in questo tipo di scenario veloce
Panoramica sarò costruire noi up
in tutti i prossimi due scenari così
la concessione di credenziali client è per
accesso diretto dall’applicazione client
ricorda questo è macchina da lavorare
non c’è nessun utente coinvolto che tu possa ottenere un
token di accesso è possibile accedere a una risorsa
è tutto ciò che succede in nome di
il cliente ci porta al secondo
Scenario e se vogliamo pianificare
tweets per conto dell’utente che è a
caso molto legittimo abbiamo visto il buffer
esempio se vuoi costruire qualcosa
così abbiamo davvero bisogno di un modo per chiedere
l’ utente hey possiamo accedere al tuo
Account Twitter in modo che possiamo effettivamente
Pubblica tweet a tuo nome in quel momento
lo fai per esempio con il
il codice di autorizzazione garantisce che sia basato su a
codice lascia che ti spieghi come funziona
quindi puoi vedere che è già un po ‘di più
complicato ci sono diverse parti
coinvolto il cliente in questo caso cliente
in fondo c’è ancora un tag e un web
domanda e questo sarà importante
più avanti in questo flusso perché abbiamo ancora bisogno
di utilizzare un segreto e si può usare solo questo
segreto ed è
memorizzato in un luogo sicuro e a
il back-end è considerato sicuro quindi
il cliente sta per richiedere l’accesso
in genere ciò implica che il browser sia
innescando un reindirizzamento che va
attraverso il browser verso il
autorizzazione del server di autorizzazione
server sta per presentare all’utente
una pagina se è Twitter chiederà
tu chi sei se già ti conosce
quindi se sei già un disco autenticato
che può essere saltato ma in generale a
ti chiedo per favore accedi al tuo Twitter
account su Twitter stesso perché il
server di autorizzazione qui nel nostro esempio
quello è Twitter che accedi e poi il
server di autorizzazione chiedi who’s Mac hey
questo buffer di applicazioni sta provando
per accedere al tuo account Twitter
voglio davvero che tu voglia autorizzare
quello e poi il cliente dice oh sì
certo che è quello che intendevo farti
fare clic su Sì, ora i servizi medici sono
interessante quindi hai autorizzato
autenticato e autorizza i clienti così
Emetterò un codice di autorizzazione
e lo farà con a
reindirizzare attraverso il browser verso
questo URI di reindirizzamento che è stato
registrato prima così il cliente durante
registrazione dice se vuoi mandarmi
qualcosa lo manda qui e questo è quello che
il server di autorizzazione userà qui
per inviare questo codice di autorizzazione a questo
per questioni di sicurezza altrimenti potresti
ingannarlo per inviarlo all’attaccante
che non dovrebbe accadere
questo codice di autorizzazione non concede
qualsiasi accesso non è un token quindi il
il cliente scambia quel codice di autorizzazione
in un token di accesso questo passaggio di scambio
9 e 10 richiedono l’uso del client
credenziali è qui il cliente
in realtà deve autenticare il
server di autorizzazione e ricordati di me
questa cosa buffer e questo è ciò che è mio
segreto che tu mi hai dato io ho questi a
Dimostralo che sono davvero io e posso farlo ora
ottenere un token di accesso in cambio di questo
codice di autorizzazione ancora più che puoi
anche ottenere un token di aggiornamento ma sto andando
per parlarne in un secondo con quello
token di accesso che l’applicazione può ora
accedere a questo server delle risorse in modo che possa
ora vai a questa API di Twitter e dì oh a
postare per conto di Filippo per favore
e vai e questo è il modo
la delega funziona in OAuth, quindi cosa noi
realizziamo davvero tanto è che permettiamo a
utente per autorizzare un cliente ad accedere
le risorse per loro conto è questo
ciò che è tutto in questo flusso è questo
il flusso più sicuro in molto perché esso
implica l’autenticazione del client passaggio 9
e 10 qui richiedono il client da utilizzare
le sue credenziali sono davvero importanti
non esiste in altri flussi che noi
parleremo nel prossimo scenario
importante anche il codice di autorizzazione
qui è valido solo da una volta
per un periodo di tempo molto breve così
di solito è come un minuto quindi hai un
minuto tra ricevendolo qui per fare
quella chiamata che dovrebbe essere abbastanza anche su
sistemi lenti se stai impiegando più tempo
di un minuto lì probabilmente hai bisogno di farlo
aggiustare alcune altre cose prima di usare molto
e questo è ciò che questo flusso ha da offrire
se si vuole guardare quella dalla
prospettiva del browser questo è ciò che il
l’utente vedrebbe effettivamente così vedi
applicazione del buffer in questo caso
chiedendoti puoi collegare il tuo Twitter
profilo alla mia domanda e se tu
fai clic sul pulsante per inviare una chiamata
al backend del buffer come oh yeah I
voglio collegare il mio account Twitter e
inizierà questo flusso con a
reindirizzare in modo da non vedere quello invece
si finisce con una pagina dal
server di autorizzazione quella pagina dal
il server di autorizzazione ti chiederà di farlo
login se necessario che potrebbe essere saltato
tu autentichi e poi il
server di autorizzazione chiede che fate voi
voglio davvero permettere questo sì che faccio
ok ecco il codice veramente reindirizzato
torna al back-end del client
applicazione che ora può scambiarla
e accedere alle risorse protette che
è ciò che l’ utente vede vede così ti connetti
vai su Twitter molto importante
è molto importante per te
in realtà andare alla festa che dovrebbe
assistere il cancello non si fa questo non lo fa
capita sotto il cofano è in realtà molto
fattibile sei reindirizzato su Twitter
e tu fai tutto ciò che devi fare lì
come utente ho menzionato il cliente
ottiene anche un token di aggiornamento che non ho intenzione di
parlare più dettagliatamente di ciò a
il token di aggiornamento consente al client di ottenere un
nuovo token di accesso in seguito, quindi accesso
i token di solito sono di breve durata
se il buffer riceve un token di accesso
Twitter è caduto per dirlo 10
minuti in modo che possa accedere all’API per 10
minuti e poi scade boom non di più
accedi lì onestamente se voglio twittare
qualcos’altro domani ne avrà bisogno
accedi di nuovo ma non sono presente
domani perché probabilmente sono su un albero
su un treno così invece di dover chiedere
me puoi darmi un altro token di accesso
attraverso il buco
elaborare questo flusso con un token di aggiornamento
chiedere al cliente di ottenere un nuovo token di accesso
l’utilizzo di quel token di aggiornamento può andare a
server di autorizzazione e dire come hey
ricorda che mi hai dato questo gettone di aggiornamento
un paio di giorni settimane mesi anni fa
Voglio usarlo per ottenere un nuovo accesso
il server di autorizzazione token può controllare
tutto dà al cliente un nuovo accesso
token e client possono indipendentemente
accedere all’account per conto di
utente di nuovo è ciò che un token di aggiornamento
autobus e naturalmente è possibile accedere al
server di risorsa se si vuole entrare in
i dettagli sporchi di come funziona è
tutto bene basato su HTTP, chiamiamolo
Tutto basato su HTTP dovrebbe essere HTTPS
ma il protocollo è HTTP, quindi si invia
loro una richiesta di questa autorizzazione
server su Twitter e tu lo indichi
vuoi eseguire questo codice di autorizzazione
concedimi per me lo faccio specificando
codice come un tipo di risposta come mi aspetto un
codice come risposta fornite al cliente
ID tu fornisci l’URI di reindirizzamento qui come
bene che dovrebbe corrispondere a quello che tu
registrato prima e un dettaglio finale è
c’è un parametro di stato di nuovo tempo
entrare nei dettagli, ma si dovrebbe sempre
usa il parametro di stato che impedisce
alcuni attacchi mettono un valore casuale
lì e controllarlo ogni volta che
il flusso è completato è sufficiente, ma se tu
voglio saperne di più su quella conversazione per me
più tardi e se tu se il flusso completa
se l’utente ha autorizzato l’autorizzazione
l’applicazione questo è ciò che torna
attraverso il browser verso il
applicazione client in modo da vedere che questo
questo URL qui è usato qui per creare il
chiama la pagina PHP di callback che riceve
questo codice, che ora posso usare per
scambiare quello per un token di accesso sul
server di autorizzazione che scambia funziona
così è una richiesta di back-channel così
non passa attraverso il browser
contro server a server in modo che possa
usa semplicemente un post che usa il
intestazione di autorizzazione è di base a
trasmetti le credenziali del cliente che sono
incorporato in là e fornisce il
codice che ha ottenuto prima che il codice sia qui
la richiesta le idee del cliente di nuovo qui
e il tipo di concessione indica che il
client vuole scambiare questo codice in
un token di accesso e questo è il
flusso di concessione del codice di autorizzazione che è
il più complesso per essere onesti ma anche
il più sicuro
oh si, mi dispiace la risposta contiene il
token di accesso che può essere utilizzato per accedere
risorse protette e anche l’aggiornamento
token come si può vedere qui tutto bene sono
ancora bene ancora e poi possiamo parlare
su alcune altre cose quindi per ricapitolare il
la concessione del codice di autorizzazione è delegata
accesso a un’applicazione di back-end che può
essere utilizzato solo su ponte e applicazioni
perché, perché usi questo cliente
credenziali per scambiare questo codice per a
token se si desidera farlo su un client
su un browser web su un’applicazione mobile
sarebbe necessario codificare il tuo segreto
applicazione internet, così sta andando
prendere qualcun altro come due minuti per
in realtà lo escludono e impersonano
il tuo cliente quindi non dovresti mai
mai farlo così questo codice è solo
sviluppato se il tuo cliente può archiviare
segreti in un modo sicuro che significa se lo è
un’applicazione back-end molto importante in modo
Lee anche la ragione per cui solo questo flusso
ti dà un token di aggiornamento perché è
l’ unico flusso che consente al cliente di
autenticarsi per l’autorizzazione
scenario del server numero tre invece di
costruire questo back-end PHP che nessuno
Piace davvero che vogliamo costruire un moderno
Front-end JavaScript che abbiamo come a
centinaia di quadri tra cui scegliere
ne sceglieremo uno e costruiamo il nostro
front-end utilizzando tale framework e in
il nostro front-end vogliamo migliorare l’interfaccia utente
di Twitter, vogliamo renderlo possibile
per interagire direttamente con alcuni tweet
vogliamo che l’utente risponda ai tweet
cose del genere quindi abbiamo bisogno di accesso
l’api ha di nuovo bisogno di accesso
retweet accesso per inviare nuovi tweet o
risposte o qualsiasi altra cosa diamo un’occhiata
come possiamo fare il flusso che stiamo andando
usare qui è il flusso implicito delle sovvenzioni
Ecco come funziona
nota che un client è un front-end
l’applicazione il tuo cliente è un web
applicazione di una pagina Web nel browser
ora sono i tuoi clienti che non abbiamo un
back-end perché non ne abbiamo bisogno
perché il nostro cliente è un front-end
Applicazione JavaScript che sta per fare
interagire con Twitter direttamente senza necessità
per il nostro back-end non serve il nostro
dati poiché interagiamo solo con Twitter
in modo che il cliente sta andando chiedere l’accesso
in genere accade all’interno del
browser quindi non c’è reindirizzamento qui è
solo una navigazione per l’autorizzazione
server
chiederà all’utente di autenticarsi
proprio come prima chiederà all’utente di farlo
autorizzare l’applicazione proprio come
prima di ogni volta che controlla il
il server di autorizzazione torna a questo
reindirizzare l’URI con un token di accesso
tempo non un codice di autorizzazione ma un
accedi direttamente al token e quell’accesso
sovvenzioni gettone questo accesso client al
server delle risorse e siamo pronti per partire
con questo token di accesso al punto sette noi
puoi leggere i tweet che possiamo permettere al
utente per digitare una risposta e possiamo postare
quella risposta su quel server delle risorse
usando quel token di accesso che è ciò che il
implicito ci ha afferrato dagli utenti
prospettiva l’utente vede una pagina da
il client questo è il nostro JavaScript
l’applicazione front-end fa clic su un pulsante
come oh yeah apri i miei piedi e poi il
il flusso inizia così siamo navigati verso
Pagina server di autorizzazione dove siamo
chiesto di autenticare se necessario noi
viene chiesto di approvare l’ applicazione se
necessario mai inviato a una pagina da
quella applicazione front-end che la pagina può
ora estrai il token di accesso da
URL e accesso a risorse protette
direttamente e questo è ciò che è implicito
concedere il flusso fa se si guarda il
richieste dietro a questo puoi vederlo
sembrano molto simili e noi chiamiamo ancora
lo stesso endpoint ma invece di codice noi
ora dillo che vogliamo e gettiamo dentro
risposta quindi questo dice l’autorizzazione
server stiamo eseguendo questa concessione implicita
flusso non stiamo facendo questa autorizzazione
codice che garantisce ma una concessione implicita a noi
fornito un ID cliente che è l’unico
cosa legare questo al nostro cliente e noi
di nuovo fornito un reindirizzamento si arriva il
la risposta arriverà a quel reindirizzamento
URI fornirà un token di accesso
nella risposta direttamente non aggiorna
segno molto importante dettaglio nota come
questo è un hash e non un punto interrogativo
questo significa che questo è parte del
frammento e il frammento delle URI è
mai inviato al server ogni volta che il
il browser carica l’URL con un frammento
quel frammento rimane nel browser
il browser invia solo ciò che è prima
quello al server e lo carica
risorsa ma un frammento fa parte del
URL ma non viene mai inviato tramite la rete
quindi qui questo ha senso perché il
il token di accesso è destinato a essere utilizzato su
il lato client e questo è quello che siamo
facendo qui non ci sono passaggi aggiuntivi
ovviamente questa cosa diventa un po ‘complicata
se il token di accesso scade perché quello
implicherebbe che tu debba eseguire il
Flusso di nuovo ma ancora una volta è molto
dibattito acceso in questa comunità su come
per gestire questi casi e non lo farò
entra nei dettagli lì quindi se lo guardi
questo dal punto di vista generale
delegato la concessione implicita ti dà
accesso delegato a un front-end
applicazione mai e poi mai usare questo
flusso quando si utilizza anche un back-end
perché le cose andranno male posso
garantire che molte applicazioni
per errore, eseguono l’implicito
concedere per e quindi prendono l’accesso
token e spedirli a loro
back-end e poi fanno qualcosa in
il back – end attraverso quel token di accesso se
lo fai correndo seriamente
problemi quindi per favore non farlo sempre
scegli il flusso appropriato per il tuo scenario
I token di accesso molto importanti sono
ottenuto direttamente tramite il reindirizzamento
attraverso il frammento dell’URI e a
anche l’applicazione front-end non lo è
dovrebbe avere accesso per l’aggiornamento
token perché i front end sono di
definizione insicura So che le persone
pensa come si, ma è a
Framework JavaScript e lo voglio davvero
questo accesso a lungo termine e lo farò
questo comunque modificherò il flusso a
bit per dare un token di aggiornamento che è un male
idea perché il token di aggiornamento è solo
emessi nell’altro flusso perché questo
richiede l’ uso di questo segreto del cliente
che nessuno dovrebbe sapere tranne il tuo
client quindi se inizi a utilizzare l’aggiornamento
token senza segreti del cliente
sbagli e ti stai aprendo
voi stessi per serio
vulnerabilità se qualcuno lo ruba
hanno accesso eterno a questo
sistema di back-end fino a quando non esplicitamente
revocare ciò se è possibile
e questo conclude il cliente
prospettiva so che questo è molto breve
panoramica quindi sarò molto felice di rispondere
tutte le domande dopo il discorso se ne hai
di più specifici parliamo di
prospettiva del servizio di risorse se sei un
server delle risorse si ottiene un token di accesso
e tu dovresti prendere una decisione
con quel token di accesso
nota che il token di accesso è inviato a
tu dal cliente uno dei comuni
idee sbagliate è che i clienti sono
dovrebbe leggere l’accesso e supposto
per capire cosa significano
ma per quanto riguarda il cliente è interessato
il token di accesso può anche essere
dinosauro non importa quello che è
può essere dinosauro un cane da uccello o un po ‘funky
token qualunque cosa non importa cosa
è importante che il server delle risorse possa
fare qualcosa con esso
questi sono due token di accesso perché tu
hanno due tipi diversi comunemente usati
in OAuth un tipo è chiamato riferimento
gettone e l’altro è chiamato a
discorsi autosufficienti di questo tipo
il token di riferimento è prima un riferimento
il token è in realtà solo un identificatore
è un identificatore che punta a a
pezzo della nostra serie di metadati tenuto dal
server di autorizzazione così ogni volta che tu
Dillo a un cliente che non sei
divulgare informazioni sensibili
gli stai solo dando un identificatore e
l’identificatore verrà in seguito utilizzato da
il server delle risorse per recuperare le informazioni
dal server di autorizzazione e con
questa informazione può prendere una decisione
e quel processo è chiamato token
l’introspezione è una delle cose
in OA che è stato specificato un po ‘più tardi
rispetto alla specifica principale ecco come token
l’introspezione funziona così tu hai il tuo
client hai il tuo server delle risorse e
hai il tuo server di autorizzazione loro
hanno diversi endpoint in questo caso
è un endpoint del token che viene utilizzato
così ovunque il cliente acceda a
risorsa protetta con un riferimento
token invia semplicemente questo identificatore
in un modo o nell’altro di solito è il
intestazione di autorizzazione con lì e poi
l’ identificatore lì dentro la risorsa
il server usa quello per scambiarlo
identificatore in un insieme di set di metadati di
rivendicazioni memorizzati su questo utente la
server di autorizzazione fornisce che e
con quelle rivendicazioni il server può fare un
decisione di controllo di accesso che è richiesta
andando a dire come oh sì questo era
rilasciato per quel cliente ed è
associato a questo profilo Twitter e
sì, questo token è ancora valido, ecco un
esempio di come farlo è di nuovo un
richiesta di back-channel
è comunicazione da server a server
fai una richiesta di posta elettronica inviandola al token
hai ricevuto dal cliente che hai detto al
l’autorizzazione serve questo dovrebbe essere un
token di accesso puoi verificarlo per me
per favore ed è quello che ottieni in cambio
i servizi di autorizzazione come oh si
Conosco questi identificatori è ancora
valido è ancora attivo non è stato
ti ha revocato
non ha annullato questo token di accesso è
associato a questo particolare cliente
e associato a questo argomento questo è
un identificatore univoco per questo argomento
può essere un ID questo può essere anche questo può
essere un nome completo o qualunque sia il sistema
vuole usare e questo è ciò che token
l’introspezione è così se andiamo rapidamente
torna a questa immagine il server delle risorse
ha bisogno di fare questo round-trip ogni volta
vuole risolvere tale riferimento
token è un token di riferimento per design
è più sicuro perché il
il server di autorizzazione mantiene il controllo di
questo token ha tutti i metadati qui
quindi ogni volta che dici “oh merda” ho perso
il mio telefono e il mio telefono ha un
l’applicazione e l’applicazione hanno accesso
a Twitter e voglio revocarlo
può andare su Twitter e dire come oh si
riorientare l’accesso prego innesco la latta
dimentica quell’informazione e quello
l’identificatore ora non è più valido
uno dei poteri di usare il riferimento
token così di nuovo li confronterò
a discorsi autosufficienti e quindi a riferimenti
i token sono un identificatore che lo tengono dentro
mente pieno controllo per l’ autorizzazione
server ma richiede questo canale posteriore
richiesta in realtà facendo così
richiesta di back-channel su ogni singolo
la chiamata API in arrivo probabilmente non è la
la migliore idea che metterà un sacco di carico
sul server di autorizzazione per uno e
c’è molta comunicazione tra
servizi per ogni chiamata che devi
fare così realtà ciò che vediamo nei sistemi
implementando questo è cache
questi token di accesso o questi riferimenti
per un breve periodo di tempo in modo che il
il server delle risorse può decidere come va bene io sono
non lo risolverò ogni volta
perché abbiamo molte chiamate API così
Lo prenderò per due o tre
minuti che è accettabile, ma ovviamente
perde un po ‘ di controllo quindi se l’utente
lo revocherò nel frattempo, allora
l’ atto che lo stalker di riferimento farà ancora
essere memorizzato nella cache per due o tre minuti
questo è il rovescio della medaglia e questo è
sicuramente qualcosa che si potrebbe desiderare di
prendi in considerazione parliamo del
altro lato delle cose vi parlerò di
gettoni autosufficienti che il nome dice
contiene un token autonomo
tutto il necessario per rendere il tuo
decisioni di autorizzazione questo è ciò a
il token autonomo potrebbe sembrare così
è un token web JSON un evento di inseguimento e
Sono parlare andando circa i dettagli su
Token web JSON ma la parte importante
di un token Web JSON è il payload e a
il carico utile è un insieme di affermazioni che sono
protetto in un modo o nell’altro così
di solito un gettone web JSON è firmato a
assicurati che nessuno possa modificarli
reclami senza essere scoperti
e queste affermazioni sono generate dal
server di autorizzazione il token assegnato
dal server di autorizzazione e dal tuo
il server delle risorse può usarli per decidere
è consentito o meno ciò di cui ha bisogno
per fare è necessario verificare il
firma di questo token e ogni volta che
firma controlla che può guardare il
dati lì come oh sì, questo era
Philippe ha fatto quella richiesta oh sì no
no ed è davvero per il cliente giusto
così e viene da Twitter quindi sì, lo sono
fidarsi di questi dati che deciderò
sì, a Philippe è permesso fare o il
il cliente è autorizzato a fare questa chiamata
per conto di Philippa per pubblicare questo tweet su
quella timeline di Twitter e questo è il
lavoro del server delle risorse grande vantaggio
autosufficiente significa no roundtrip voi
non devi tornare al
server di autorizzazione più e più volte
per controllare qual è questo identificatore oh sì
grazie no, puoi farlo semplicemente con
il token stesso così vinci molto
quel dipartimento
il rovescio della medaglia è che non hai alcun controllo
questi token di accesso sono
autosufficiente se l’utente va al
il servizio di autorizzazione dice che voglio
revoca questo token che puoi forse revocare
ma come sarà mai il server delle risorse
sappi che è revocato non c’è
comunicazione più così finché questo
il token rimane abbattuto esso può essere usato da
tutti coloro che hanno accesso a quel token così
se posso rubare il tuo token e rimane
valido per cinque mesi, quindi puoi averlo
cinque punti quattro mesi perché io ora
avere cinque mesi di accesso a questo
API back-end nel tuo nome che è molto
problematico quindi questi token dovrebbero essere
di breve durata è una delle primarie
considerazioni di sicurezza nel
le specifiche utilizzano un accesso di breve durata
gettoni e la gente implementare questo in
vita reale nell’idea, indipendentemente dalle due settimane
buono per andare oh sicuro che funzioni, ma lì
sono sicuramente rischi e coinvolti
che se non sbaglio è il recente
I problemi di Facebook erano legati all’accesso
token e penso che fossero validi
60 giorni
quindi sì, ci sono dei rischi coinvolti lì
quindi un token autonomo contiene tutto
i metadati necessari per prendere decisioni
sono memorizzati sul client
quindi sono fuori liberati dal
server di autorizzazione che significa che tu
non può facilmente revocarli, ci sono
meccanismi per farlo, ma lo sono
difficile sono risorse ingannevoli
i server devono verificare l’integrità di a
token autonomo prima di usarli
molto molto importante se lo dimentichi
le cose andranno davvero in giro
rapidamente questo è l’uso dei token di accesso
potresti aver notato nella richiesta
prima c’era questo parametro
chiamato ambito mi sono sfiorato perché io
Sapevo che ne avrei parlato più tardi
quindi non ho menzionato prima che gli ambiti lo siano
in realtà una proprietà piuttosto interessante
perché l’ambito consente di limitare
le autorizzazioni associate a un
accedi al token quindi se richiedi un accesso
token come client è possibile fornire il
portata remota come autorizzazione hey
server Voglio accedere a questo account e
Voglio leggere l’accesso o l’accesso in scrittura
e il server di autorizzazione sta per
chiedi all’utente che questa applicazione sta provando
per accedere al tuo account che vuole
leggi il tuo feed Twitter e scrivi
messaggi al tuo feed Twitter fai tu
voglio quello e tu puoi decidere di sì o no
e se non vuoi che tu scelga no
ovviamente e l’intero flusso fallisce con
un errore e se si fa clic su Sì allora
il server di autorizzazione assocerà il
Questo è l’ambito con il token di accesso
molto utile un esempio molto pratico in
vita reale ho comprato uno scanner che può
scansione su Evernote che pensavo fosse
una caratteristica molto interessante non più manuale
mettere le cose in Evernote e quando io
sistemarlo ha usato molto e ha chiesto
accesso completo al mio account Evernote come
hey possiamo leggere tutti i tuoi appunti e
quaderni e possiamo scrivere note ed è stato
come perchè hai bisogno di leggere tutto questo
informazioni mia moglie intera è lì dentro
Non ho intenzione di darti accesso
soprattutto non perché l’altro
il software fa schifo quindi non sono sicuro che sia tuo
quale implementazione andrà bene
quindi in realtà queste cose funzionano
gli ambiti di pratica non sono definiti in cosa
l’ OAuth ci specifica come si puoi mettere
i tuoi ambiti in questo parametro ma si
Metti messo lì qualunque cosa tu
sei andato a guardare un esempio reale questo
è come gli utenti chiedono le autorizzazioni
per esempio slick questi sono gli ambiti
offerto da selezionabile molto piccolo
parte degli ambiti che hanno scelto
per avere ambiti a grana molto fine basati
sugli oggetti e il livello di accesso
quindi ad esempio hai un problema artistico
che dà il giusto accesso ai canali e
questo è associato a questo metodo
se si desidera utilizzare uno di questi metodi
hai bisogno di accedere alla scrittura l’ambito necessario
concesso dall’utente e loro fanno un
distinzione tra clienti connessi all’utente
e entrambi i client correlati di nuovo così
l’utente ha una buona idea di cosa
esattamente lui sta concedendo a un cliente e
la migliore pratica per un cliente è
Richiedi tutti gli ambiti che puoi ottenere come
piccoli ambiti in cui puoi cavartela
mi dispiace come pochi ambiti che puoi ottenere
via con così se stai solo mostrando
tweets a un utente non ha senso in
chiedendo per l’accesso in lettura e scrittura solo
chiedere un accesso root è molto importante
considerazione in pratica puoi andare
completamente pazzo con scope quindi se il tuo
Google hai un sacco di api che hanno
scelto di utilizzare gli URL come ambiti così di
certo se richiedi come 25.000 di
loro probabilmente sarà molto lungo
richiesta ma non dovresti farlo
che probabilmente non stai costruendo un
cliente che ha bisogno sia dell’accesso a Google
Analitici e fogli di lavoro di Google Documenti
allo stesso tempo, probabilmente mi non lo faccio
sai cosa stai costruendo ma ottieni
l’idea ma puoi vedere interessante
cose come te hanno pieno accesso a
portata dell’analisi come vista e gestione
dati ma hai anche un ambito di sola lettura
e cose come cancellare utenti o
eliminazione di richieste o eliminazione di dati da
l’analisi è un ambito separato che è
nemmeno parte della vista e gestisci
portata dei dati perché è così sensibile
che lo hanno esplicitamente messo separatamente
e ancora se richiedi un accesso a
commettere solo l’ambito di sola lettura e
qualcuno riesce a rubare il peggio
possono fare è leggere i dati almeno loro
non è possibile cancellare o modificare alcun dato
di nuovo è la tua responsabilità come
implementatore del client per scegliere il
Ambiti che si adattano al tuo cliente e da mantenere
loro come minimo come
e quando lo fai questo meccanismo
funziona davvero abbastanza bene, certo che lo è
la responsabilità della risorsa
server per controllare questi ambiti che sono
parte dei metadati associati a a
gettone
così ogni volta che il token entra nel
server delle risorse si controlla quello che sei
cercando di fare
Pubblica il tweet hai accesso in scrittura
si va bene a parte gli altri assegni
che è fatto, naturalmente, è così
gli ambiti effettivamente funzionano molto bene
contenere le autorizzazioni associate a un
accedi al token fino ad ora per immergerti in Ord
parliamo di open early connect a
la dichiarazione in fondo potrebbe non essere
molto accurata Sono pienamente consapevole di ciò
ma aperte ID Connect è di circa
autenticazione perché come si fa
l’autenticazione con tutte le probabilità non è possibile
davvero evolvono le persone pensano di poter fare a
un po ‘in realtà è molto difficile quindi
se si esegue questo foro o deflusso al
terminare la cliente ottiene un token di accesso è
potrebbe recuperare le informazioni dell’utente con quello
token di accesso che è in genere come
l’autenticazione è implementata ma lo è
quell’asiatico davvero autentico come fai tu
sapere se l’ utente è autenticato correttamente
è un po ‘implicito perché presumi
che il server di autorizzazione ne faccia un po ‘
forma di autenticazione ma è fresca
quando l’utente intende kay, forse l’utente
fatto cinque mesi fa e la sua sessione
con il server di autorizzazione è ancora
valido vale come un
autenticazione per il client se il
client usa questa informazione utente a
autenticare l’utente è un compagno
autenticazione non proprio e tutti
il cliente commette un errore, quindi non lo fai
anche sapere se il token di accesso è
è caduto e finalmente dove prendi
quella informazione utente su Twitter è su quello
endpoint e su Facebook è su quello
endpoint e poi hai Google è
su quell’endpoint e ottieni l’ idea
quindi se vuoi implementare questo login
con Facebook Twitter e Google sei
molto probabile che abbia tre diversi
implementazioni che tutti odiano
nessuno lo vuole così persone in realtà
incasinare questo davvero davvero male e
è qui che entra in gioco Connect aperto
operato Connect è costruito su poet it
segue lo stesso principio di delega
ma invece di risultare in un accesso
token risulta
l’emissione di un token di identità così il
il client avvia nuovamente il flusso
richiede informazioni sull’identità all’utente
autentica concede l’accesso e nel
fine il server di autorizzazione dà un
token di identità per il cliente e quello
il token di identità sta per contenere
informazioni su chi è l’utente quando
lui autenticato e un altro
proprietà e con ciò il cliente può
decidere di perché questo tizio si o no
e se è che autorizzo o
autenticare questo utente e se non lo è
Devo rifiutare questo e questo è quello
open ID Connect è in realtà di
Certo che potresti voler ottenere di più
informazioni da parte dell’utente e questo è
per cosa si dispone l’endpoint di informazioni utente
un ID aperto Connect invece di consentire
il server di autorizzazione per scegliere come
sì, lo metteremo ovunque tu
non voglio se stai già implementando
connetti fornisci un endpoint che è
chiamato informazioni utente non domande che è
proprio come funziona e questo è dove il
il cliente può effettivamente ottenere quell’informazione
da e questo è costruito su parte perché
ha usato scorre, ma si fa un sacco di
decisioni per te dove oh è molto
apri come qui puoi usare questo
meccanismo lo implementa come vuoi tu
Connect afferma apertamente che è così che si fa
questo è ciò che ottieni da questo è
dati nel token di identità e cioè
come si implementa questo e questo diventa
influenze Google interoperabili se tu
accedi con Google stai usando OpenID
Connetti ma se ne userai altri
servizi se implementano anche OpenID
Connetti è la stessa implementazione
che è molto bella e molto pulita in
la tua applicazione questo è un esempio di
un token di identità che potresti riconoscere
il formato ora è di nuovo un JSON
web token è firmato da
server di autorizzazione quindi se vuoi
Selezionare Login con Google si otterrà un
token di Google ed è firmato da
Google quindi sei l’applicazione client
puoi verificare che questo è un token per firmare il mio
Google oh sì questo è caduto oh
si ok ora ho qualche informazione
la richiesta SUV è un identificativo univoco
rappresentando l’utente che è nel tuo
caso non molto utile perché è
ID di Google che non conosco ma anche tu
prendi questa e-mail in fondo e quella
per esempio, l’e-mail ti consente di collegarti
l’identità di quell’utente a qualcosa
tu
concetto nella tua applicazione in modo che tu possa
ora cerca nel tuo database come fa
Ho un utente con il flip alle labbra pragmatiche
carino, vieni, sì, ecco il ragazzo, quindi questo
il token è fella, viene da quel ragazzo, quindi sono
collegarlo al suo account e ora
è autenticato come Phillip in questo
applicazione buffer o qualunque cosa stia usando
puoi vedere che ce ne sono altri
affermazioni coinvolte anche qui, forse
una delle cose importanti è che c’è
un tempo di autenticazione qui così tu
sapere esattamente quando l’autorizzazione
il server è stato autenticato dall’utente e tu
può decidere è accettabile sì o no
se è una transazione di alto valore,
lo stai facendo in un’azienda
e non con il login con Google
per favore, ma in un sistema aziendale, allora
potresti voler richiedere un nuovo
autenticazione perché forse non lo è
valido se l’utente ha effettuato l’accesso ieri no
vuoi una nuova autenticazione ACR
indica la forza del
autenticazione utile per indicare
se l’utente ha utilizzato il multi-fattore
autenticazione sì o no perché
a volte potresti aver bisogno di questo e
questo è un protocollo progettato per fornire
che le informazioni ed è quello che
open ID Connect porta al tavolo aperto
la connessione iniziale si basa sull’arte e sulle offerte
tre flussi che sono in realtà molto
simile al flusso OAuth che noi
discusso prima che io vada rapidamente
su di loro e poi vado a concludere così
abbiamo tempo per una o due domande a
Alla fine c’è un flusso di sussidi impliciti
utilizzato solo per applicazioni di front-end
che non cambia mai i mezzi di concessione impliciti
autenticazione client implicita come in no
davvero l’ autenticazione del cliente solo così
front-end funziona come l’altro
fluire in modo che il cliente inizi a
flusso ma invece di dare la risposta
digita token ora dice che voglio anche un
token di identità un token ID che
indica che sto eseguendo la connessione ID aperta
qui ho bisogno di informazioni sull’identità da
l’utente da te sta per fare il
balla con l’autorizzazione dell’utente sì di
Certo e qui andiamo dà un accesso
token e un token di identità l’identità
token consente al front-end di
autenticare l’utente che in a
l’applicazione front-end non significa molto
molto ma tu hai l’idea ora puoi dire
bentornato per questo Thank You
applicazione front-end il token di accesso
a questo proposito può essere utilizzato per effettuare chiamate
a una risorsa protetta
come in quale parte è stata inserita la porta
uno in modo che tu possa effettivamente fare
qualcosa di utile dopo con le API
così non devi usare che questo
è facoltativo l’uso del token di accesso
ma spesso è fatto insieme che è il
concessione implicita anteriore e unica
il codice di autorizzazione è concesso molto rapidamente
lo stesso setup di prima del cliente
inizia l’intera danza con un reindirizzamento
ancora una volta questo non cambia è ancora
codice si va al luppolo di
autenticare la concessione dell’utente
autorizzazione con cui reindirizza
codici di autorizzazione che vanno al
client e questo è dove operandi Connect
entra in gioco il cliente ora scambia
questo codice di autorizzazione usando suppliant
credenziali e ottiene un token di identità
e un token di accesso e quell’identità
token esegue nuovamente l’autenticazione dell’utente
questo caso è un sistema di back-end quindi è così
andando a cercare nel proprio database o
eppure questo è associato a questo utente così
ora so che questo utente è loggato
invece di fare l’autenticazione
direttamente abbiamo ottenuto che le informazioni da
qui e ora sappiamo che quell’utente è
effettivamente registrato nel back-end
così abbiamo impostato la nostra sessione o qualsiasi altra cosa
facciamo e facciamo la nostra interazione di abilitazione
con l’utente e di nuovo possiamo usare il
accedi al token se vogliamo e poi il
nuovo mi dispiace
questo è per le applicazioni di back-end
quello che abbiamo coperto e poi quello nuovo è
il flusso ibrido questo è il suo bene
è nuovo ma non è davvero nuovo se tu
capire questo flusso di lavoro è giusto
ti aiuta a ottenere il token di identità più velocemente
nel client così essenzialmente ciò che fai
stai iniziando lo stesso flusso ma invece
di soli atti che richiedono un codice anche tu
chiedere un token di identità in questo passaggio
quindi faremo tutto il ballo e
otterremo un codice di autorizzazione
e stai parlando direttamente nell’URL
che lo farà finire direttamente in
il cliente che consente al cliente di partecipare
per autenticare l’utente in quel punto
senza dover fare questo spettro o
richiesta di scambio del codice per il
accedi al token ed è aperto per primo
ti fa risparmiare tempo è più veloce è di più
efficiente ed è spesso usato in
pratica a causa di questi motivi e di
Certo, allora puoi ancora ottenere il tuo
token di accesso a
accedi alle tue risorse protette quindi se
mettere questo nuovo insieme il
il token di identità è inteso per il
applicazione back-end molto importante se
stai usando questo flusso ibrido di cui hai bisogno
per garantire che questo token di identità sia
destinato al tuo cliente
ci sono molte implementazioni che
in realtà fanno questo e poi accettano
qualsiasi token di identità che abbia un significato
che se ho un cliente che tu solo
accedi con Google e se hai un
client che ha effettuato l’ accesso a Google se
non stai controllando il pubblico che posso
darti un token di identità token di accesso
rilasciato dal mio cliente e lo farai
accetta quel significato che potrei prendere
qualcosa dal mio cliente e lo uso
accedi come utente della tua applicazione
a causa di una vulnerabilità e questo è
in realtà molto molto comune in già
collegare gli scenari ed è per questo che questo è
così importante ci sono altri controlli che
deve essere fatto ma questo è veramente
davvero cruciale perché non c’è
non utilizzare nessuna credenziale del cliente
segreto nulla che collega a questo codice I
sapere che tutti sono come riempiti fino a
qui con flussi e token e codici a
ricorda che parte è un meccanismo da delegare
accesso per conto dell’utente ci sono
alcuni altri casi d’uso ma il generale
i flussi difficili consentiti permettono a
applicazione per accedere a una risorsa su
per conto del proprietario della risorsa l’utente
che è associato a quella risorsa
e questa è l’unica cosa che dovresti fare
a meno che ovviamente non ne abbiate altri
scelta ad esempio Facebook ha il loro
proprio protocollo di autenticazione sopra
dispari che non è aperto nessun collegamento ma se
hai una scelta in un set aziendale
in alto avrai una scelta se lo schiererai
il tuo server di autorizzazione se tu
bisogno di autenticazione
le radio usano la parte di connessione addy aperta
non si tratta di autenticazione intelligente
delegazione open ID connect ti offre
le informazioni sull’identità sono progettate per
autenticazione in questi modi e
in realtà gestisce un sacco di più angolo
casi rispetto a quelli che sono stato in grado di
discuti qui e questo è ciò che questi
le cose sono veramente e spero che
questa è la cosa che togli e se
c’è un’altra cosa che devi
ricorda di usare sempre il flusso corretto
guarda non è difficile quando lo sai
che devi cercare questo sguardo cosa
è il flusso corretto dall’applicazione e
effettivamente usare quel flusso adeguato e quello
conclude il discorso grazie, grazie
per ascoltare e se ne hai
domande sarei felice di rispondere loro
tu
Please follow and like us: