【问题标题】:implementing other grants when only authorization code is available当只有授权码可用时实施其他授权
【发布时间】:2018-06-29 20:23:04
【问题描述】:

我正在创建 Web 和移动应用程序,通过桌面应用程序公开可用的 API 重新实现现有桌面应用程序。此 API 仅提供用于身份验证的授权代码授予路径,这需要我:

  1. 以某种方式将客户端密码安全地存储在应用程序中
  2. 在我的网络服务器中实现 PKCE 和隐式身份验证端点作为 API 的传递
  3. 拥有我自己的身份验证系统(通过 auth0 或等效项),然后用户将其链接到他们的 API 帐户

2 是可能的,还是 3 是我唯一真正的选择?

【问题讨论】:

  • 问题是什么?
  • 哇,我的问题非常模糊,现在解决了。 “我可以在我自己的网络服务器上以合理的方式实现 PKCE 和隐式身份验证吗?”
  • 我认为最好的方法是使用一些现有的库,而不是自己实现 oauth :)
  • 我不确定我是否遵循。显然,对于 3,我想使用类似 auth0 的东西,所以我实际上并没有管理用户名/密码,但是对于 2,是否有库可以为我做这件事?我找不到任何东西。
  • 你使用什么技术?

标签: oauth-2.0 access-token


【解决方案1】:

是的,2 是可能的,而且比我想象的要简单得多。在以下示例中,Client 是 Web 或移动应用程序,Server 是您的服务器,而 API 是您尝试访问的 API支持验证码

网页版(隐式):

  1. 客户端向服务器发送标准的隐式请求
  2. 服务器解析此请求,然后将其重组为 Auth Code 请求并转发给 API
  3. API 验证用户登录,并将验证码发送到服务器
  4. 服务器将验证码发送回 API
  5. API 返回访问令牌并刷新
  6. 服务器只向客户端返回访问令牌

对于移动设备 (PKCE):

  1. 客户端向服务器发送标准 PKCE 请求
  2. 服务器解析此请求,然后将其重组为 Auth Code 请求并转发给 API
  3. API 验证用户登录,并将验证码发送到服务器
  4. 服务器向客户端发送验证码
  5. 客户端向客户端发送验证码和验证器
  6. 服务器验证将 Auth Code 发送回 API
  7. API 返回访问令牌并刷新

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-08-12
    • 2020-05-05
    • 2018-11-21
    • 1970-01-01
    • 2018-11-04
    • 2018-01-12
    • 2018-04-13
    • 2016-11-18
    相关资源
    最近更新 更多