secured web services

[warlock9_0]

φτιάχνω μια εφαρμογή για android η οποία θα στηρίζεται πάνω σε web services μέσω των οποίων γίνονται select/insert σε διάφορους πίνακες σε μια βάση

 

επιπλέον οι χρήστες πρέπει να είναι signed in οπότε έχω και αυτών τα στοιχεία

 

εμπειρία από web services έχω ελάχιστη, και από διάφορα tutorial κατέληξα να χρησιμοποιώ jax-ws, γιατί αυτό βρήκα, μέσω netbeans

 

αυτό που ψάχνω είναι κάποιος τρόπος authentication των χρηστών έτσι ώστε να μην χρειάζεται να γίνεται συνέχεια login (θέλω να χρησιμοποιήσω το account manager στο android) και να λειτουργεί με κάποιο token ωστε να μην στέλνονται στοιχεία του χρήστη όλη την ώρα

 

όσο το ψάχνω τόσο πιο πολύ τα μπερδεύω οπότε αν έχει χρησιμοποιήσει κανείς τίποτα παρόμοιο ή αν έχει να προτείνει κάτι άλλο θα βοηθήσει αρκετά

δεν με νοιάζει να το αλλάξω εντελώς γιατί είναι σε πολύ αρχικό στάδιο ακόμα

[defacer]

Αφού ο χρήστης κάνει login μία φορά ο server θα επιστρέψει στην εφαρμογή ένα authorization token. Αυτό δεν είναι τίποτα περισσότερο από ένα (μεγάλο) "τυχαίο" string το οποίο ο server αποθηκεύει σε κάποια database μαζί με πληροφορίες όπως τι επιτρέπεται να κάνει ο κάτοχος του token (π.χ. επιτρέπεται να διαβάσει το email μου αλλά όχι να ποστάρει στο wall μου) και πότε παύει η ισχύς του (αυτό είναι επιθυμητό ούτως ώστε σε περίπτωση που παραπέσει το token να μην έχει αυτός που θα το βρει πρόσβαση "για πάντα"). Για όλες τις λειτουργίες που προσφέρει το web service θα δίνεις πλέον σα διαπιστευτήριο αυτό το token.

 

Αυτή ήταν η περίληψη όσον αφορά τα ελάχιστα πράγματα που χρειάζεσαι για να γίνει η δουλειά. Απο κει και πέρα υπάρχει πολύ περισσότερο ψωμί στο θέμα authorization, αν έχεις διάθεση σου προτείνω να ψάξεις να δεις πώς και κυρίως γιατί λειτουργεί το OAuth 2.0. Δεν είναι ιδιαίτερα εύκολο (ειδικά στο "γιατί αυτό γίνεται έτσι" δύσκολα θα βρεις άμεσες απαντήσεις) αλλά αν το κατανοήσεις σε βάθος δε θα χρειαστεί πιθανόν να ξανακάνεις ποτέ παρόμοια ερώτηση.

[pmav99]

@defacer

Αν είναι εύκολο, μπορείς να δώσεις και μερικά links;

[warlock9_0]

το oauth2 να σου πω την αλήθεια το κοίταγα αλλά δεν του έδωσα αρκετή σημασία και ίσως γι αυτό μου φάνηκε δύσκολο, θα το ξαναδώ

το token πάνω κάτω το ξέρω οτι κάνει αυτά που λες, το θέμα είναι να μην το υλοποιήσω από την αρχή μόνος μου γιατί και overkill είναι για τη δουλειά που θέλω και τρύπες θα έχει, οπότε εψαχνα κάτι έτοιμο

[defacer]

@defacer

Αν είναι εύκολο, μπορείς να δώσεις και μερικά links;

 

• Πρώτα απ' όλα, authentication vs authorization για να μην υπάρχει παρανόηση όσον αφορά τα βασικά.
• Όλο το ζουμί είναι στο RFC 6749 (OAuth 2.0), οπωσδήποτε διαβάζει κανείς πρώτα απ' όλα το πρώτο κεφάλαιο, γενική περιγραφή σε απλά αγγλικά. Η ορολογία είναι λίγο μπερδεμένη γιατί σε κάποια πράγματα αναφερόμαστε με παραπάνω από ένα ονόματα (π.χ. grant type και flow), οπότε αυτό ίσως είναι χρήσιμο.
• Το RFC 6819 εξηγεί το threat modeling του OAuth 2.0, είναι αρκετά βοηθητικό στο να καταλάβει κανείς γιατί κάποια πράγματα γίνονται έτσι (τα "countermeasures" για κάθε threat έχουν αναφορές στο τι λέει το πρότυπο). To RFC 6750 μιλάει πιο συγκεκριμένα για θέματα ασφαλείας που προκύπτουν από τη συμπεριφορά του client που έχει πλέον στη διάθεσή του ένα access token ("bearer").

Τώρα, παρόλο που το λέει στο threat modeling είναι ultra σημαντικό οπότε θα το πω και γω: η πρακτική υλοποίηση του OAuth 2 είναι πολύ απλούστερη από αυτή του OAuth 1 επειδή το 2 δεν περιλαμβάνει κανένα μηχανισμό προστασίας από παρακολούθηση των επικοινωνιών (κλοπή δηλαδή του access token) ούτε και από replay attacks -- αυτές οι λειτουργίες υλοποιούνται από το HTTPS το οποίο είναι απαραίτητο.

 

Σε περίπτωση που δεν είναι διαθέσιμο κάποιο κρυπτογραφημένο, ασφαλές κλπ κανάλι (π.χ. επικοινωνία μέσω HTTP) τότε τα πράγματα στην πράξη περιπλέκονται πολύ (βλέπε OAuth 1.0, RFC 5849, guide) αν και η ιδέα από μόνη της δεν είναι τίποτα το ιδιαίτερο:

• Υπάρχει ένα shared secret ανάμεσα στον client και τον server ("API secret")
• Κάθε request στο API (δηλαδή όλες οι παράμετροι που μαζί αποτελούν το API call) είναι signed με το secret μέσω κάποιου HMAC -- αυτό εξασφαλίζει πως δεν μπορεί κάποιος χωρίς το secret να στέλνει "νόμιμα" request.
• Μία από τις παραμέτρους που αποτελούν το API call είναι ένα nonce -- αυτό εξασφαλίζει προστασία από replay attacks.
• Τέλος μπαίνει μέσα κι ένα timestamp το οποίο δεν είναι τεχνικά απαραίτητο όσον αφορά σε θέματα ασφαλείας, αλλά είναι απαραίτητο στην πράξη για να μπορεί κανείς να υλοποιήσει το server-side κομμάτι του πρωτοκόλλου (για να μη χρειάζεται βασικά ο server να θυμάται όλα τα nonce που έχει δει από τη δημιουργία του σύμπαντος και μετά).

Το παραπάνω combo (shared secret + HMAC + nonce) είναι στάνταρ πακέτο όπου χρειάζονται ασφαλείς επικοινωνίες, εξ ου και το "τίποτα ιδιαίτερο". Βεβαίως όπως πάντα στην κρυπτογραφία είναι πολύ εύκολο να τα έχεις όλα σωστά στη θεωρία αλλά να κάνεις λάθος στην πράξη, οπότε δε θέλω να αφήσω την εντύπωση ότι "μπορείς να το κάνεις και με κλειστά τα μάτια".

 

Για ένα παράδειγμα του πώς λειτουργεί αυτό στην πράξη υπάρχουν πληροφορίες στο documentation του Twitter API (χρησιμοποιήστε το μενού πάνω δεξιά, λίγο πιο κάτω από το search box, για πλοήγηση).

 

Μερικά χύμα links ακόμα:

• OAuth (1.0) for dummies
• Google Developers OAuth 2.0 playground (για να τα δει κανείς στην πράξη)

Τέλος να ξεκαθαρίσω ότι στο RFC υπάρχουν πολλά διαφορετικά authentication flows για να υποστηρίξουν διαφορετικά σενάρια (πρόσβαση στο API μέσω website, μέσω app, μέσω συσκευής η οποία μπορεί να είναι τελείως χαζή, κλπ). Δεν χρειάζονται όλα αυτά για μία συγκεκριμένη περίπτωση χρήσης -- απλά επιλέγει κανείς αυτό που ταιριάζει.

[παπι]

authentication vs authorization

Ωραια απαντηση ο "φουκαρας".

[warlock9_0]

επανέρχομαι με νέα απορία

 

τελικά χρησιμοποιώ τα services της google για authentication, παίρνω στο κινητό ένα google token, το στέλνω στο server που χρειάζεται η εφαρμογή και από εκεί κοιτάω αν είναι valid το token για να συνεχίσω

 

το θέμα μου είναι κάθε πότε πρέπει να ζητάω token? πριν από κάθε request?

 

Site: εδώ διαβάζω αυτό

 

 

4. Refresh the access token, if necessary.

Access tokens have limited lifetimes. If your application needs access to a Google API beyond the lifetime of a single access token, it can obtain a refresh token. A refresh token allows your application to obtain new access tokens.

Note: Save refresh tokens in secure long-term storage and continue to use them as long as they remain valid. Limits apply to the number of refresh tokens that are issued per client-user combination, and per user across all clients, and these limits are different. If your application requests enough refresh tokens to go over one of the limits, older refresh tokens stop working.