我是对着这个示例看的OAuth2.0,用的OWIN中间件。
当客户端获得AccessToken后,去获取资源服务器中受保护的资源时,资源服务器是怎样验证客户端的身份呢?示例代码此处并没有做出详细的说明。
我通过web.config配置可以看出认证服务器与资源服务器用的同一组machineKey,猜测资源服务器是可以解析AccessToken,但是并没有验证AccessToken、客户端与用户三者的对应关系。按照我的想法应该是这三者之间应当有个固定关系记录在数据库或者什么地方,当客户端访问资源服务器时,应当读取数据库信息做出验证。
贴出示例代码中资源服务器的部分代码:
namespace ResourceServer
{
public partial class Startup
{
public void ConfigureAuth(IAppBuilder app)
{
app.UseOAuthBearerAuthentication(new Microsoft.Owin.Security.OAuth.OAuthBearerAuthenticationOptions());
}
}
}
namespace ResourceServer.Controllers
{
[EnableCors(origins: "*", headers: "*", methods: "*")]
[Authorize]
public class MeController : ApiController
{
public string Get()
{
return this.User.Identity.Name;
}
}
}
代码很简单,api代码里面也是只加了一个Authorize特性头就完事了。
后面我继续做出了试验,用两个不同的客户端去获取AccessToken,然后互相调换AccessToken去访问资源服务器,发现还是可以访问。到底是示例代码没有在资源服务器做验证?还是说本身OAuth2.0协议规范中资源服务器就不应该做这方面的认证?
大家可以访问http://authcode.rayearth.xyz:81/
http://implicit.rayearth.xyz:81/
获取AccessToken之后交换,然后获取个人信息。
账号密码都是admin
10 个解决方案
#1
AccessToken 应该只能用一次,而且需要在短期之内(例如1分钟之内)使用。至于是不是你的客户端“互相调换”,服务器怎么知道呢?
#2
什么意思啊,,,,
#3
现在就是因为资源服务器只验证AccessToken是否合法,而没验证api调用者的身份,我才有这个疑惑。例如客户端1拿到了授权的AccessToken1,然后把AccessToken1交给客户端2去使用,按照现有逻辑仍然是可以获取到用户的信息的(1分钟之内)。但是很明显,AccessToken1不是用户给客户端1的授权吗,客户端2不能使用才对啊?
#4
就是想知道资源服务器怎么样验证获取资源的程序的身份。
#5
是否可以把客户端ID(或者用户名+密码)+AccessToken,在服务端存起来,校验时同时校验AccessToken和客户端ID信息。
#6
什么意思啊,,,,
就是想知道资源服务器怎么样验证获取资源的程序的身份。
首先资源服务器肯定会验证AccessToken, 至于AccessToken里面包不包含客户端程序信息,这个跟资源服务器有关
其次,不同的资源服务器会有不同的验证逻辑,你只是碰到了其中一个,不能推广到所有,
再有,正常情况下是你主动把这个token给另一个客户端的,难道这个客户端有什么不轨行为,服务器抓不到你吗,(你普通一个basic验证,通过cookie就可以获得操作权限不也是一样的道理)
最后,OAuth只是个理论,具体实现方实现到什么程度跟实现方自身有关。
不知道这么说,你明白否。
#7
AccessToken 应该只能用一次,而且需要在短期之内(例如1分钟之内)使用。至于是不是你的客户端“互相调换”,服务器怎么知道呢?
现在就是因为资源服务器只验证AccessToken是否合法,而没验证api调用者的身份,我才有这个疑惑。例如客户端1拿到了授权的AccessToken1,然后把AccessToken1交给客户端2去使用,按照现有逻辑仍然是可以获取到用户的信息的(1分钟之内)。但是很明显,AccessToken1不是用户给客户端1的授权吗,客户端2不能使用才对啊?
是否可以把客户端ID(或者用户名+密码)+AccessToken,在服务端存起来,校验时同时校验AccessToken和客户端ID信息。
是的,我也是这么想的。打算用数据库记录客户端、用户、AccessToken之间的关系,调用API的时候应该做验证。
#8
什么意思啊,,,,
就是想知道资源服务器怎么样验证获取资源的程序的身份。
首先资源服务器肯定会验证AccessToken, 至于AccessToken里面包不包含客户端程序信息,这个跟资源服务器有关
其次,不同的资源服务器会有不同的验证逻辑,你只是碰到了其中一个,不能推广到所有,
再有,正常情况下是你主动把这个token给另一个客户端的,难道这个客户端有什么不轨行为,服务器抓不到你吗,(你普通一个basic验证,通过cookie就可以获得操作权限不也是一样的道理)
最后,OAuth只是个理论,具体实现方实现到什么程度跟实现方自身有关。
不知道这么说,你明白否。
大体上是明白了,还有些疑惑啊。
1.资源服务器验证AccessToken,这个Token里面有没有客户端信息应该是认证服务器和资源服务器约定决定的吧?如果AccessToken附带了客户端信息,资源服务器就可以从AccessToken中验证客户端信息,是这样的吗?
2.如果AccessToken中不带客户端信息,资源服务器仍然可以通过其它手段验证客户端信息吗?如果AccessToken泄露了,服务器事后再来处理也只是亡羊补牢啊。
3.层主说的Basic验证,仔细想了一下也可能存在这个问题,如果Cookie泄露了,是不是也能窃取用户信息。
#9
http://www.cnblogs.com/mirrortom/p/5931352.html
#10
OWIN的中间件并没有实现你需要的功能,OAuth2.0和MVC一样是一个技术方法,不是一套技术方案。
#1
AccessToken 应该只能用一次,而且需要在短期之内(例如1分钟之内)使用。至于是不是你的客户端“互相调换”,服务器怎么知道呢?
#2
什么意思啊,,,,
#3
AccessToken 应该只能用一次,而且需要在短期之内(例如1分钟之内)使用。至于是不是你的客户端“互相调换”,服务器怎么知道呢?
现在就是因为资源服务器只验证AccessToken是否合法,而没验证api调用者的身份,我才有这个疑惑。例如客户端1拿到了授权的AccessToken1,然后把AccessToken1交给客户端2去使用,按照现有逻辑仍然是可以获取到用户的信息的(1分钟之内)。但是很明显,AccessToken1不是用户给客户端1的授权吗,客户端2不能使用才对啊?
#4
什么意思啊,,,,
就是想知道资源服务器怎么样验证获取资源的程序的身份。
#5
AccessToken 应该只能用一次,而且需要在短期之内(例如1分钟之内)使用。至于是不是你的客户端“互相调换”,服务器怎么知道呢?
现在就是因为资源服务器只验证AccessToken是否合法,而没验证api调用者的身份,我才有这个疑惑。例如客户端1拿到了授权的AccessToken1,然后把AccessToken1交给客户端2去使用,按照现有逻辑仍然是可以获取到用户的信息的(1分钟之内)。但是很明显,AccessToken1不是用户给客户端1的授权吗,客户端2不能使用才对啊?
是否可以把客户端ID(或者用户名+密码)+AccessToken,在服务端存起来,校验时同时校验AccessToken和客户端ID信息。
#6
什么意思啊,,,,
就是想知道资源服务器怎么样验证获取资源的程序的身份。
首先资源服务器肯定会验证AccessToken, 至于AccessToken里面包不包含客户端程序信息,这个跟资源服务器有关
其次,不同的资源服务器会有不同的验证逻辑,你只是碰到了其中一个,不能推广到所有,
再有,正常情况下是你主动把这个token给另一个客户端的,难道这个客户端有什么不轨行为,服务器抓不到你吗,(你普通一个basic验证,通过cookie就可以获得操作权限不也是一样的道理)
最后,OAuth只是个理论,具体实现方实现到什么程度跟实现方自身有关。
不知道这么说,你明白否。
#7
AccessToken 应该只能用一次,而且需要在短期之内(例如1分钟之内)使用。至于是不是你的客户端“互相调换”,服务器怎么知道呢?
现在就是因为资源服务器只验证AccessToken是否合法,而没验证api调用者的身份,我才有这个疑惑。例如客户端1拿到了授权的AccessToken1,然后把AccessToken1交给客户端2去使用,按照现有逻辑仍然是可以获取到用户的信息的(1分钟之内)。但是很明显,AccessToken1不是用户给客户端1的授权吗,客户端2不能使用才对啊?
是否可以把客户端ID(或者用户名+密码)+AccessToken,在服务端存起来,校验时同时校验AccessToken和客户端ID信息。
是的,我也是这么想的。打算用数据库记录客户端、用户、AccessToken之间的关系,调用API的时候应该做验证。
#8
什么意思啊,,,,
就是想知道资源服务器怎么样验证获取资源的程序的身份。
首先资源服务器肯定会验证AccessToken, 至于AccessToken里面包不包含客户端程序信息,这个跟资源服务器有关
其次,不同的资源服务器会有不同的验证逻辑,你只是碰到了其中一个,不能推广到所有,
再有,正常情况下是你主动把这个token给另一个客户端的,难道这个客户端有什么不轨行为,服务器抓不到你吗,(你普通一个basic验证,通过cookie就可以获得操作权限不也是一样的道理)
最后,OAuth只是个理论,具体实现方实现到什么程度跟实现方自身有关。
不知道这么说,你明白否。
大体上是明白了,还有些疑惑啊。
1.资源服务器验证AccessToken,这个Token里面有没有客户端信息应该是认证服务器和资源服务器约定决定的吧?如果AccessToken附带了客户端信息,资源服务器就可以从AccessToken中验证客户端信息,是这样的吗?
2.如果AccessToken中不带客户端信息,资源服务器仍然可以通过其它手段验证客户端信息吗?如果AccessToken泄露了,服务器事后再来处理也只是亡羊补牢啊。
3.层主说的Basic验证,仔细想了一下也可能存在这个问题,如果Cookie泄露了,是不是也能窃取用户信息。
#9
http://www.cnblogs.com/mirrortom/p/5931352.html
#10
OWIN的中间件并没有实现你需要的功能,OAuth2.0和MVC一样是一个技术方法,不是一套技术方案。