是否可以将oauth1 3LO访问令牌和机密迁移到oauth2刷新令牌?
1){“错误”:“unauthorized_client”}
从云控制台使用有效的client_id和client_secret。看起来client_secret是错误的,但我们重新检查并使用了不同的应用程序--同样的问题。
2)我们有一个测试web oauth2应用程序,错误为:{“error”:“disabled_client”,“error_description”:“the OAuth client disabled.”}
OAuth2应用程序工作正常,所以我们不明白这是什么意思。
对于Google API,如何从OAuth1 2LO迁移到OAuth域范围委托?
但是这个问题描述了其他情况:2LO->Domain。
我的要求是
POST/o/oauth2/token HTTP/1.1
授权:OAuth realm=“”,oauth_signature=“iaitn9c0ncu5lpzrdotusdezgmk%3D”,oauth_nonce=“103474114541826”,oauth_signature_method=“hmac-sha1”,oauth_consumer_key=“.apps.googleusercontent.com”,oauth_token=“1%2f9xozjnn4dk2omeyirc-”,oauth_timestamp=“1385471501”
内容类型:application/x-www-form-urlencoded
内容长度:161
主办:accounts.google.com
连接:保持活力
grant_type=urn%3aietf%3aparams%3aoauth%3agrant-type%3amigration%3aoauth1&client_id=.apps.googleusercontent.com&client_secret=ijnelhcljv
回应是
HTTP/1.1 400错误请求
cache-control:no-cache,no-store,max-age=0,必须重新验证
杂注:无缓存
有效期:1990年1月1日星期五格林尼治时间00:00:00
内容类型:application/json
X-content-type-options:nosniff
X-Frame-Options:SAMEORIGIN
服务器:GSE
备用协议:443:QUIC
传输编码:分块
{“error”:“disabled_client”,“error_description”:“OAuth客户端已禁用。”}
HTTP/1.1 400错误请求
cache-control:no-cache,no-store,max-age=0,必须重新验证
杂注:无缓存
有效期:1990年1月1日星期五格林尼治时间00:00:00
日期:2013年11月26日星期二13:27:02格林尼治时间
内容类型:application/json
X-content-type-options:nosniff
X-XSS-保护:1;mode=块
服务器:GSE
备用协议:443:QUIC
问题出在迁移文档中指定的客户端验证中(您的使用者类型-native与您的客户端类型-web不匹配)。
为了解决这个问题,我们在最后做了一些修改,你能再检查一下并确认问题是否仍然存在吗?
我对oauth2中的刷新令牌有点困惑。如它所说的访问令牌限制了黑客可以使用用户凭证的1小时的时间窗口,刷新令牌是万岁令牌,可以用来重新创建访问令牌。 我很困惑,如果有人从cookie中窃取了访问令牌,他也可以窃取刷新令牌,并可以使用刷新令牌创建新的访问令牌,因为我在JQuery中有ajax请求(客户端)
请求你分享你的想法。 提前道谢。
我以前在一个OAuth2应用程序中工作过,其中的逻辑是在旧的访问令牌过期后通过刷新令牌生成新的访问令牌。 如果访问令牌在30分钟后过期,然后您只需要传入刷新令牌(但没有重新生成),那么刷新令牌的意义是什么?
我正在实现一个支持刷新令牌的OAuth2服务器,但是,有一些东西我不能完全理解。 当用户通过请求新的访问令牌,并且他/她请求的范围小于原始访问令牌的范围(5个范围中的3个)时。刷新令牌应该具有原始作用域还是刷新令牌应该具有请求的新作用域? > 如果刷新令牌请求了新的作用域,这是否意味着如果它们继续请求较小的作用域,它们最终将耗尽作用域? 刷新令牌是否应保留原始作用域?这意味着返回的访问令牌对于刷新
我理解客户机应用程序使用refresh_token(连同它的凭据)为最终用户(资源所有者)获取新的访问令牌,而不是存储最终用户的用户名/密码,并在每次access_token过期时发送它们。 然而,在我看来,这听起来像refresh_token和access_token一样好,它几乎只是一个额外的服务器调用,所以为什么不直接使用它,即如果refresh token是有效的授予访问权限呢?
application.yml: