summaryrefslogtreecommitdiff
path: root/docs/chapters/introduction.tex
diff options
context:
space:
mode:
authorSanto Cariotti <santo@dcariotti.me>2022-11-23 10:13:31 +0100
committerSanto Cariotti <santo@dcariotti.me>2022-11-23 10:13:31 +0100
commitbd19a23e37e2598636ddb7cf19736773ade248ea (patch)
treedef194b9d1f40dfbb991d9cd22ff534be3fcc134 /docs/chapters/introduction.tex
parent19fa69ea37bc83141c74f5327b9a2f4c0a0e9f82 (diff)
fix typos
Diffstat (limited to 'docs/chapters/introduction.tex')
-rw-r--r--docs/chapters/introduction.tex12
1 files changed, 7 insertions, 5 deletions
diff --git a/docs/chapters/introduction.tex b/docs/chapters/introduction.tex
index ce461ee..34fec8b 100644
--- a/docs/chapters/introduction.tex
+++ b/docs/chapters/introduction.tex
@@ -1,15 +1,17 @@
Questa relazione fa riferimento a quanto riportato dalla OWASP Foundation \cite{OWASP:1} in merito alla classifica dei Top 10 rischi nei dispositivi mobile dell'anno 2016 \cite{OWASP:2}.
-Definire cosa sia un'\textbf{autorizzazione} è compito di ogni studente del corso di Internet Security ma, stando a quanto citato nell'articolo \cite{auth0:1} un'autorizzazione è \emph{il processo di dare a qualucuno l'abilità di accedere ad una risorsa}.
+Definire cosa sia un'\textbf{autorizzazione} è compito di ogni studente del corso di Internet Security ma, stando a quanto citato nell'articolo di Auth0\cite{auth0:1} un'autorizzazione è \emph{il processo di dare a qualcuno l'abilità di accedere ad una risorsa}.
-Proprio questo, infatti, è quello di cui abbiamo ampiamente discusso nel modulo di \emph{Identity and Access Managment} ed è quello che Auth0 fa esattamente: un gateway per implementare autenticazione e autorizzazione mediante servizi terzi. Per intenderci, esso risolve il classico problema del "Sign in with Google/Facebook/Microsoft".
+Proprio questo, infatti, è quello di cui abbiamo ampiamente discusso nel modulo di \emph{Identity and Access Management} ed è quello che Auth0 fa esattamente: un gateway per implementare autenticazione e autorizzazione mediante servizi terzi. Per intenderci, esso risolve il classico problema del "Sign in with Google/Facebook/Microsoft".
\section{Autenticazione vs Autorizzazione}
-Oltre ad essere un header in una richiesta HTTP differente essi hanno un significato semantico differente.
+Sono innanzitutto due differenti header in una richiesta HTTP, oltre ad avere anche un diverso significato semantico.
Il primo dà la conferma che la coppia di informazioni - come ad esempio (nome utente, password) - inserite si riferiscano realmente ad un utente presente nel sistema.
-Il secondo no, avviene, in teoria, dopo che l'utente ha eseguito il sign in.
+Il secondo vede se l'utente registrato ha i permessi per la risorsa; avviene dopo che l'utente ha eseguito il sign in.
\section{Problema nell'autenticazione}
-In poche righe, dato che non è argomento di questa relazione, un'autenticazione all'interno di un dispositivo mobile non è \emph{necessariamente} un bug o un errore di progettazione all'interno di un server. Questo perché si potrebbe avere un'applicazione single-page che non si interfaccia ad un backend presente in un server remoto e quindi i dati di autenticazione si possono riferire al dispositivo mobile locale.
+In poche righe, dato che non è argomento di questa relazione, un'autenticazione all'interno di un dispositivo mobile non è \emph{necessariamente} un bug o un errore di progettazione all'interno di un server a cui si fanno richieste.
+
+Infatti ci si potrebbe riferire ad un problema circoscritto localmente al dispositivo mobile, come ad esempio fingerprint o WiFi.
\section{Problema nell'autorizzazione}
L'autorizzazione invece può spaziare, dare per assodato che l'autenticazione è stata fatta, e quindi rilasciare una risorsa solo perché quel token che gli stiamo passando è effettivamente \emph{un token valido}, o meglio, un token abilitato (che quindi ha il permesso) a visualizzare (o modificare) una determinata risorsa. \ No newline at end of file