28 votes

Des Questions Sur la consommation de Votre API OAuth

Je suis en train de construire une API RESTful pour un projet que je suis en train de travailler sur et je voudrais faire l'application principale de consommer de l'API car:

  1. Elle aura pour conséquence d'avoir un ensemble de code à maintenir
  2. Si nous décidons d'exposer l'API pour la 3ème partie devs c'est déjà fait
  3. Il ouvre la possibilité de faire des applications mobiles qui la consomment
  4. Je veux vraiment apprendre à le faire

L'API sera hébergé sur un sous-domaine https://api.example.com , et le principal de l'application web sera hébergé sur le domaine racine https://example.com.

Conceptuellement, j'comprendre comment tout fonctionne, mais ma principale question est de savoir comment le flux d'authentification va changer, si, à tous. Normalement applications 3ème partie serait:

  1. Obtenir un jeton de demande d' https://api.example.com/request_token
  2. Rediriger l'utilisateur pour s'authentifier sur https://api.authenticate.com/authorize
  3. Obtenir redirigé vers l'application 3ème partie
  4. Obtenir un jeton d'accès d' https://api.example.com/access_token

Depuis que je contrôle les deux domaines, je peux faire quelque chose de similaire à:

  1. Obtenir un jeton de demande lorsque l'utilisateur des terres sur l'écran de connexion à https://www.example.com
  2. L'utilisateur s'authentifie à l'aide d'un formulaire sur https://www.example.com qui appelle le même code que https://api.example.com/authorize
  3. Si les informations sont valides, le jeton de demande est échangé pour le jeton d'accès
  4. Jeton d'accès est enregistré dans la session et expire lorsque l'utilisateur se déconnecte comme il le ferait normalement

Étape 3 se sent comme il est faux puisqu'il y aura des code en double, mais ne serait-il pas m'ouvrir à des attaques XSS est le formulaire de connexion sur https://www.example.com a envoyé les données https://api.example.com depuis qu'ils sont techniquement différents domaines?

Suis-je de compliquer à l'excès ce?

20voto

Jon Nylander Points 4113

J'ai rencontré le même problème et l'a résolu comme ça.

1 Pour les applications de tierces parties, à l'aide de mon API, ils ont de s'authentifier via OAuth sur toutes les demandes.

2 Pour mes propres clients tiers, (mobile, de l'AIR, etc) - ils utiliser OAuth, avec la différence que j'ai autoriser ces à envoyer le nom d'utilisateur et le mot de passe directement dans l'étape de l'autorisation (donc je peux faire un natif de dialogue de connexion). C'est à la condition que votre API est sur SSL/HTTPS.

3 Pour mon application web, j'utilise le cookie d'authentification pour accéder à l'Api. I. e après avoir connecté, l'utilisateur peut simplement l'appel de l'API:url et obtenir JSON/XML dos. Nice pour une rapide exploration de l'Api aussi (bien qu'une vraie API Console comme APIGee fait un meilleur travail là-bas).

0voto

blockhead Points 4654

Je dirais que vous êtes de compliquer à l'excès un peu. Si votre code est séparé correctement, vous pouvez facilement construire un RESTE mince couche de l'application de la couche de service, tout en ayant les controllers de votre application d'être une mince couche de la couche de service ainsi.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X