为什么有三条腿的OAuth2，而两条腿的OAuth2工作得这么好？
双腿OAuth2用于基于浏览器的应用程序，在这种应用程序中，任何客户端凭据都不能对公众隐藏。“Web服务器应用程序”使用三条腿的OAuth2，其中服务器之间有第三个呼叫。这里描述得很好。
问题是：既然两条腿看起来很好，为什么还要用三条腿呢？
这对提供者和客户来说都是更多的工作。为什么其中一个大咖不出手，去掉3条腿？
共有2个答案
存在两条腿的情况。例如，查看有关谷歌应用程序域范围授权的文档。当然，它们只能在受信任的环境中由帐户的超级所有者使用——在我上面提到的示例中：Google Apps域管理员是他所管理的域的所有用户帐户的超级所有者。
当然，三脚机器人必须在开放的网络环境中使用。您确实需要资源所有者的批准才能将其数据的访问权授予第三方应用程序。
“三条腿”并不意味着“基于浏览器”中的某种类型的应用程序。三条腿的意思是应用程序直接代表用户。在三条腿的场景中，有
- 应用程序（消费者），
在两条腿的场景中，没有用户的概念。通常，这与应用程序到应用程序解决方案有关。在那里，应用程序（消费者）代表自己行事。因此，在双腿OAuth中，有：
- 应用程序（消费者），
- API（服务提供商）
不同的是，在2条腿的方法中不需要用户授权步骤。
-
我想知道是否有人知道如何获得多条腿？ i、 e如果我尝试从两个不同的地址从谷歌方向获取方向，它只会给我一条腿，但当我在谷歌地图上做完全相同的请求时，它会给我4条路线。你知道我怎么走这四条路吗？ 我的请求：https://maps.googleapis.com/maps/api/directions/json?origin=48安大略省多伦多市永街
-
我正在尝试使用2legged oauth对Web服务进行身份验证。我有下一个使用路标库创建经过身份验证的URL的工作java示例： http://example.com/my/method?oauth_consumer_key=KEY 我正试图用ruby的oauth重新创建它。我的代码现在看起来像这样： 并生成如下URL： http://example.com/my/method?oauth_si
-
通过“隐式”流，在资源所有者（即用户）给予访问权之后，客户端（可能是浏览器）将获得一个访问令牌。 然而，对于“授权代码”流，客户端（通常是web服务器）仅在资源所有者（即用户）给予访问权之后才获得授权代码。使用该授权代码，客户机然后对API进行另一次调用，传递client_id和client_secret以及授权代码，以获得访问令牌。这里都有很好的描述。 这两个流具有完全相同的结果：访问令牌。不过
-
简单得可笑的问题，我似乎找不到任何答案： 通过oauth2三条腿的身份验证，我有userId+accessToken+refreshToken来访问google用户的日历范围。 现在，我想列出该用户的所有日历。 google calendar api参考(https://developers.google.com/google-apps/calendar/v3/reference/)谈到了cale
-
本文向大家介绍你觉得如果团队有人拖后腿怎么办？相关面试题，主要包含被问及你觉得如果团队有人拖后腿怎么办？时的应答技巧和注意事项，需要的朋友参考一下 分析有成员落下进度的原因，是分工不合理还是成员态度问题导致。明确问题原因后，针对性调整，分工不合理就进行分工调整，如果是成员态度问题，则进行沟通，督促工作进度。总值分析表象下的原因，对症下药。