2011-12-15 11 views
28

Sto costruendo un'API RESTful per un progetto su cui sto lavorando e mi piacerebbe fare l'applicazione principale consumano l'API perché:domande di consumare la tua API con OAuth

  1. il risultato sarà ad avere un set di codici per mantenere
  2. se decidiamo di esporre le API per 3rd sviluppatori partito sarà già essere fatto
  3. si apre la possibilità di rendere le applicazioni mobili che consumano
  4. ho molta voglia di imparare come farlo

L'API sarà ospitata su un sottodominio https://api.example.com e l'applicazione Web principale sarà ospitata nel dominio radice https://example.com.

Concettualmente capisco come tutto funzioni, ma la mia domanda principale è come cambierà il flusso di autenticazione, se non del tutto. Ordinariamente applicazioni 3rd party sarebbero:

  1. ottenere un token richiesta https://api.example.com/request_token
  2. Redirect all'utente di autenticarsi su https://api.authenticate.com/authorize
  3. reindirizzato indietro all'applicazione 3a parte
  4. Ottenere un token di accesso da https://api.example.com/access_token

Poiché controllo entrambi i domini, posso fare qualcosa di simile a:

  1. ottenere un token di richiesta quando le terre utente sulla schermata di accesso a https://www.example.com
  2. L'utente viene autenticato tramite un modulo sul https://www.example.com che chiama lo stesso codice come https://api.example.com/authorize
  3. Se le credenziali sono valide, il token di richiesta è scambiato per il token di accesso token di
  4. l'accesso viene salvato nella sessione e termina quando l'utente si disconnette come farebbe normalmente

Fase 3 sente come se fosse sbagliato poiché ci sarà Duplica codice, ma non mi aprirebbe agli attacchi XSS? Il modulo di login su https://www.example.com ha inviato i dati a https://api.example.com poiché sono tecnicamente domini diversi?

Sono troppo complicato?

risposta

20

Mi sono imbattuto nello stesso problema e l'ho risolto in questo modo.

Per le app di terze parti, utilizzando la mia API, devono autenticarsi tramite OAuth su tutte le richieste.

per il mio client di terze parti, (mobili, AIR ecc) - usano OAuth, con la differenza che permetto questi per inviare il nome utente e la password direttamente nella fase di autorizzazione (così posso fare un nativo dialogo di accesso). Questo è previsto che la tua API sia su SSL/HTTPS.

Per la mia applicazione Web, utilizzo l'autenticazione cookie per accedere alle API. Dopo l'accesso, l'utente può semplicemente chiamare API: urls e ottenere di nuovo JSON/XML. Bello anche per esplorare rapidamente le API (anche se una vera API Console come APIGee fa un lavoro migliore lì).

+2

Puoi approfondire l'articolo 3? Quando l'utente esegue il login, si salva un ID di sessione in un cookie e quindi lo si utilizza come token di pseudo accesso per quando si effettua una chiamata API e quindi si cerca quando si riceve la richiesta API? Sembra che sarebbe una vulnerabilità di sicurezza ... – Steve

+1

In sostanza si. Ma come è una vulnerabilità? Non uso OAuth quando chiami le API dall'app web. Se hai effettuato l'accesso (come determinato dalla convalida del cookie), allora le API sono accessibili semplicemente chiamando l'URL. Ho dimenticato di menzionare tuttavia che servo l'API: s all'app Web sullo stesso dominio. –

+0

Suppongo che finché non ci si basa esclusivamente sull'ID di sessione per identificare l'utente sul lato server, non lo è. Stavo pensando che potresti aprirti a [Session Hijacking] (http://en.wikipedia.org/wiki/Session_hijacking), ma è il venerdì dopo che la scuola è uscita e sono stanco. In base alle tue risposte ad altre domande, sei decisamente un tipo molto esperto! Grazie per l'aiuto! – Steve

0

Direi che lo stai complicando un po '. Se il tuo codice è separato in modo appropriato, puoi facilmente creare un sottile strato REST sul livello di servizio dell'applicazione, mentre i controller dell'applicazione saranno anch'essi uno strato sottile sul livello di servizio.

+2

Cosa intendi per livello di servizio? Sono i modelli all'interno dei controller che fanno tutto il sollevamento pesante? Se è così, allora è un po 'il mio piano - è davvero il bit di autenticazione che mi sta gettando per un ciclo. Voglio spostare tutta la logica aziendale in un sottodominio API separato perché dovremo esporlo per lo sviluppo di app mobili e I * think * mi aiuterà con scalabilità nel senso che posso ruotare il numero di client stupidi che si collegano all'API e hanno solo l'API centrale per gestire tutta la cache dei dati. Non so ancora molto sulla scalabilità, anche se ... – Steve

Problemi correlati