Ποιες είναι οι κύριες διαφορές μεταξύ του ελέγχου ταυτότητας JWT και του OAuth;

TL;DR Εάν έχετε πολύ απλά σενάρια, όπως μια ενιαία εφαρμογή πελάτη, ένα ενιαίο API, τότε ίσως να μην αξίζει να πάτε στο OAuth 2.0, από την άλλη πλευρά, πολλοί διαφορετικοί πελάτες (βασισμένοι στο πρόγραμμα περιήγησης, εγγενείς κινητές συσκευές, server-side, κλπ), τότε η τήρηση των κανόνων του OAuth 2.0 μπορεί να το κάνει πιο διαχειρίσιμο από το να προσπαθείτε να αναπτύξετε το δικό σας σύστημα.

Όπως αναφέρεται σε άλλη απάντηση, το JWT (Learn JSON Web Tokens) είναι απλώς μια μορφή token, ορίζει έναν συμπαγή και αυτοτελή μηχανισμό για τη μετάδοση δεδομένων μεταξύ των μερών με τρόπο που μπορεί να επαληθευτεί και να εμπιστευτεί, επειδή είναι ψηφιακά υπογεγραμμένο. Επιπλέον, οι κανόνες κωδικοποίησης ενός JWT καθιστούν επίσης αυτά τα tokens πολύ εύκολο να χρησιμοποιηθούν στο πλαίσιο του HTTP.

Όντας αυτοτελή (το πραγματικό token περιέχει πληροφορίες για ένα συγκεκριμένο θέμα) αποτελούν επίσης μια καλή επιλογή για την εφαρμογή μηχανισμών ελέγχου ταυτότητας χωρίς κατάσταση (ή αλλιώς Look mum, no sessions!). Όταν ακολουθείται αυτή η οδός και το μόνο πράγμα που πρέπει να παρουσιάσει ένα μέρος για να του χορηγηθεί πρόσβαση σε έναν προστατευόμενο πόρο είναι το ίδιο το token, το εν λόγω token μπορεί να ονομαστεί bearer token.

Στην πράξη, αυτό που κάνετε μπορεί ήδη να ταξινομηθεί ως βασισμένο σε bearer tokens. Ωστόσο, λάβετε υπόψη σας ότι δεν χρησιμοποιείτε bearer tokens όπως ορίζεται από τις σχετικές προδιαγραφές του OAuth 2.0 (βλ. RFC 6750). Αυτό θα σήμαινε, ότι βασίζεστε στην επικεφαλίδα HTTP Authorization και χρησιμοποιείτε το σχήμα αυθεντικοποίησης Bearer.

Όσον αφορά τη χρήση του JWT για την αποτροπή του CSRF χωρίς να γνωρίζουμε ακριβείς λεπτομέρειες, είναι δύσκολο να εξακριβώσουμε την εγκυρότητα αυτής της πρακτικής, αλλά για να είμαι ειλικρινής δεν φαίνεται σωστή ή/και αξιόλογη. Το ακόλουθο άρθρο (Cookies vs Tokens: The Definitive Guide) μπορεί να είναι μια χρήσιμη ανάγνωση για το θέμα αυτό, ιδιαίτερα η ενότητα XSS and XSRF Protection.

Μια τελευταία συμβουλή, ακόμη και αν δεν χρειάζεται να κάνετε πλήρη χρήση του OAuth 2.0, θα σας συνιστούσα να περάσετε το διακριτικό πρόσβασης μέσα στην επικεφαλίδα Authorization αντί να χρησιμοποιήσετε προσαρμοσμένες επικεφαλίδες. Εάν πρόκειται πραγματικά για bearer tokens ακολουθήστε τους κανόνες του RFC 6750, εάν όχι, μπορείτε πάντα να δημιουργήσετε ένα προσαρμοσμένο σχήμα ελέγχου ταυτότητας και να εξακολουθήσετε να χρησιμοποιείτε αυτή την επικεφαλίδα.

Οι επικεφαλίδες εξουσιοδότησης αναγνωρίζονται και αντιμετωπίζονται ειδικά από τους μεσάζοντες και τους διακομιστές HTTP. Έτσι, η χρήση τέτοιων επικεφαλίδων για την αποστολή μαρκών πρόσβασης σε διακομιστές πόρων μειώνει την πιθανότητα διαρροής ή ακούσιας αποθήκευσης πιστοποιημένων αιτήσεων γενικά και ειδικά των επικεφαλίδων Authorization.

(πηγή: RFC 6819, ενότητα 5.4.1)

Το OAuth 2.0 ορίζει ένα πρωτόκολλο, δηλαδή καθορίζει τον τρόπο μεταφοράς των tokens, ενώ το JWT ορίζει μια μορφή token.

Το OAuth 2.0 και η αυθεντικοποίηση "JWT" έχουν παρόμοια εμφάνιση όσον αφορά το (2ο) στάδιο όπου ο πελάτης παρουσιάζει το token στον διακομιστή πόρων: το token μεταφέρεται σε μια επικεφαλίδα.

Αλλά το "JWT authentication" δεν είναι πρότυπο και δεν καθορίζει πώς ο Πελάτης αποκτά το token αρχικά (το 1ο στάδιο). Από εκεί προέρχεται η αντιληπτή πολυπλοκότητα του OAuth: ορίζει επίσης διάφορους τρόπους με τους οποίους ο Πελάτης μπορεί να αποκτήσει ένα κουπόνι πρόσβασης από κάτι που ονομάζεται Εξουσιοδοτικός Διακομιστής.

Έτσι, η πραγματική διαφορά είναι ότι το JWT είναι απλώς μια μορφή token, ενώ το OAuth 2.0 είναι ένα πρωτόκολλο (που μπορεί να χρησιμοποιεί ένα JWT ως μορφή token).

Πρώτον, πρέπει να διαφοροποιήσουμε το JWT και το OAuth. Βασικά, το JWT είναι μια μορφή token. Το OAuth είναι ένα πρωτόκολλο εξουσιοδότησης που μπορεί να χρησιμοποιήσει το JWT ως token. Το OAuth χρησιμοποιεί αποθήκευση από την πλευρά του διακομιστή και από την πλευρά του πελάτη. Αν θέλετε να κάνετε πραγματική αποσύνδεση πρέπει να χρησιμοποιήσετε το OAuth2. Η πιστοποίηση ταυτότητας με token JWT δεν μπορεί να κάνει πραγματική αποσύνδεση. Επειδή δεν έχετε έναν διακομιστή ελέγχου ταυτότητας που να παρακολουθεί τα tokens. Εάν θέλετε να παρέχετε ένα API σε πελάτες τρίτων, πρέπει να χρησιμοποιήσετε επίσης το OAuth2. Το OAuth2 είναι πολύ ευέλικτο. Η υλοποίηση του JWT είναι πολύ εύκολη και δεν απαιτεί πολύ χρόνο για να υλοποιηθεί. Εάν η εφαρμογή σας χρειάζεται αυτού του είδους την ευελιξία, θα πρέπει να επιλέξετε το OAuth2. Αλλά αν δεν χρειάζεστε αυτό το σενάριο χρήσης, η υλοποίηση του OAuth2 είναι χάσιμο χρόνου.

Το κουπόνι XSRF αποστέλλεται πάντα στον πελάτη σε κάθε επικεφαλίδα απάντησης. Δεν έχει σημασία αν ένα CSRF token αποστέλλεται σε ένα JWT token ή όχι, επειδή το CSRF token είναι ασφαλισμένο με τον εαυτό του. Επομένως, η αποστολή του CSRF token στο JWT είναι περιττή.