关于使用 OAuth 使用自己的 API 的问题 [英] Questions About Consuming Your Own API with OAuth

查看:16
本文介绍了关于使用 OAuth 使用自己的 API 的问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在为我正在处理的项目构建一个 RESTful API,我想让主应用程序使用该 API,因为:

I'm building a RESTful API for a project I'm working on and I'd like to make the main application consume the API because:

  1. 这将导致需要维护一组代码
  2. 如果我们决定为 3rd 方开发者公开 API,它已经完成
  3. 它开启了制作使用它的移动应用程序的可能性
  4. 我真的很想学习怎么做

API 将托管在子域 https://api.example.com 上,主 Web 应用程序将托管在根域 https://example.com.

The API will be hosted on a subdomain https://api.example.com and the main web application will be hosted at the root domain https://example.com.

从概念上讲,我理解一切是如何工作的,但我的主要问题是身份验证流程将如何改变,如果有的话.通常,第 3 方应用会:

Conceptually I understand how everything works, but my main question is how the authentication flow will change if, at all. Ordinarily 3rd party apps would:

  1. https://api.example.com/request_token 获取请求令牌
  2. 重定向用户以在 https://api.authenticate.com/authorize
  3. 上进行身份验证
  4. 重定向回第 3 方应用程序
  5. https://api.example.com/access_token 获取访问令牌
  1. Obtain a request token from https://api.example.com/request_token
  2. Redirect the user to authenticate on https://api.authenticate.com/authorize
  3. Get redirected back to the 3rd party application
  4. Obtain an access token from https://api.example.com/access_token

既然我控制了两个域,我可以做类似的事情:

Since I control both domains, can I do something similar to:

  1. 当用户登陆 https://www.example.com
  2. 登录屏幕时获取请求令牌
  3. 用户使用 https://www.example.com 上的表单进行身份验证,该表单调用与 https://api.example.com/authorize 相同的代码
  4. 如果凭据有效,则将请求令牌交换为访问令牌
  5. 访问令牌保存在会话中,并在用户像往常一样注销时过期
  1. Obtain a request token when the user lands on the login screen at https://www.example.com
  2. The user authenticates using a form on https://www.example.com that calls the same code as https://api.example.com/authorize
  3. If the credentials are valid, the request token is swapped for the access token
  4. Access token is saved in the session and expires when the user logs out like it normally would

第 3 步感觉是错误的,因为会有重复的代码,但它不会让我面临 XSS 攻击吗?https://www.example.com 上的登录表单发送了https://api.example.com 的数据,因为它们技术上是不同的域?

Step 3 feels like it's wrong since there will be duplicate code, but wouldn't it open me up to XSS attacks is the login form on https://www.example.com sent the data to https://api.example.com since they are technically different domains?

我是否过于复杂了?

推荐答案

我遇到了同样的问题,并像这样解决了.

I have come across the same issue and solved it like this.

1对于使用我的 API 的第三方应用,他们必须通过 OAuth 对所有请求进行身份验证.

1 For third party apps, using my API, they have to authenticate via OAuth on all requests.

2对于我自己的第三方客户端(移动、AIR 等) - 他们使用 OAuth,不同之处在于我允许它们在授权步骤中直接发送用户名和密码(因此我可以进行本地登录对话).前提是您的 API 通过 SSL/HTTPS.

2 For my own third party clients, (mobile, AIR etc) - they use OAuth, with the difference that I allow these to send username and password directly in the authorization step (so I can make a native login dialogue). This is provided that your API is over SSL/HTTPS.

3对于我的 Web 应用程序,我使用 cookie 身份验证来访问 API.即登录后,用户可以简单地调用 API:urls 并获取 JSON/XML.也很适合快速探索 API(尽管像 APIGee 这样的真正的 API 控制台在这方面做得更好).

3 For my web application, I use cookie authentication to access the APIs. I.e after having logged in, the user could simply call API:urls and get JSON/XML back. Nice for quick exploring the APIs also (although a real API Console like APIGee does a better job there).

这篇关于关于使用 OAuth 使用自己的 API 的问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆