当前位置: 首页 > 知识库问答 >
问题:

OAuth用户身份验证与服务器身份验证和访问层相结合

戚繁
2023-03-14

我正在使用预装的Visual Studio解决方案开发我的首批OAuth解决方案之一。

不过,同时我也希望我的服务器应用程序拥有“完全访问权限”。他们需要能够获得列表增加多个用户,删除东西等等。

下面是我的问题,我认为这些问题可以很容易地一起回答:

  1. 如何管理两个短期令牌(承载令牌?)连同永久令牌(API令牌?)
  2. 我在访问级别上有何不同,因此某些方法需要永久令牌?
  3. 在同一方法中,我在访问级别上有何不同(即,典型的GET方法,在该方法中,用户只应获得“His Items”,而管理令牌可以获得“All”)

共有1个答案

邵文乐
2023-03-14

它可能看起来很简单,但它涉及到很多概念,将从你的问题中证明其中的一些:

1.如何管理两个短期代币(不记名代币?)连同永久令牌(API令牌?)

通常,web-api项目可以用作身份验证机制的承载令牌,但它不支持您所要求的高级授权场景,因此,为了满足这些需要,您需要使用身份模型的自定义和基于角色的授权实现

您需要创建一个RoleManager类,并且需要将其添加到OWIN上下文中,现在可以在authorize中修改属性以查看角色,如下所示[authorize(roles=“admin”)]

3.我在访问级别上有什么不同,所以有些方法需要永久令牌?

您需要基于角色创建一个自定义逻辑,以便该用户是否为管理,并且可以基于此为具有管理访问权限的人员创建永久令牌。我希望我的第二点解释也能回答这个问题

4.在相同的方法中,我在访问级别上有何不同(例如,典型的GET方法,用户只应该获得“His Items”,而管理令牌可以获得“All”)

根据角色,您可以获得所有用户或单个用户的列表,这里是一个伪代码,供您理解

    if (userManager.IsInRole(user.Id, "Admin")) {

     // this roles is authorized to get the All records

    }
else{

  // Send a single record ...
 }
 类似资料:
  • OAuth术语已经困扰我很久了。OAuth授权是像一些人建议的那样,还是认证? 如果我错了,请纠正我,但我一直认为授权是允许某人访问某个资源的行为,而OAuth似乎没有任何实际允许用户访问给定资源的实现。OAuth实现所讨论的都是为用户提供一个令牌(签名的,有时是加密的)。然后,每次调用都会将该令牌传递到后端服务endpoint,在后端服务endpoint上检查该令牌的有效性,这也不是OAuth的

  • 于是我在这里看到:https://firebase . Google . com/docs/auth/web/account-linking # link-auth-provider-credentials-to-a-user-account现在可以在Firebase中链接用户账号了。我还看到Firebase提供了匿名认证的功能,它为一个用户创建一个用户会话,不需要任何凭证。 在我们的应用程序中,

  • 我试图扩展用户身份验证示例,这里也给出了这个示例,以便多个用户可以登录到服务器。我还想为每个用户分配一个不同的主目录。到目前为止,我还没有找到Apache SSHD API提供的任何此类实用程序,因此我尝试了以下解决方案,使用Apache FTPServer提供的实用程序。 我试图做的是:

  • 问题内容: 我一直在研究一个简单的API示例,即带有身份验证的ServiceStack Hello World示例的修改版本。概念验证的目的是创建一个RESTful API,该API包含要求身份验证的服务,这些服务完全可以通过Ajax从多个不同的Web项目访问。 我已经阅读了有关Wiki的认证和授权以及实现CORS的实现,(很多,结果[抱歉,没有足够的信誉指向相关链接])。此时,我的Hello服务

  • 我正在使用Spring OAuth2实现单独的资源和自定义身份验证服务器。我已经通过发出和验证JWT令牌配置了与身份验证服务器的交互,看起来一切都很好。 现在我正在尝试添加SSO功能,但真的坚持了下来。我研究了官方的Spring示例和附带的指南,但是当涉及到将SSO部分与自定义服务器身份验证连接时,它的措辞非常简短。而且实际上作者只使用外部提供程序资源(“user”信息)来显示进程。 我认为这是正

  • 身份验证 PDF版下载 企业应用中的URL链接可以通过OAuth2.0验证接口来获取员工的身份信息。 通过此接口获取员工身份会有一定的时间开销。对于频繁获取员工身份的场景,建议采用如下方案: 企业应用中的URL链接直接填写企业自己的页面地址; 员工跳转到企业页面时,企业校验是否有代表员工身份的cookie,此cookie由企业生成; 如果没有获取到cookie,重定向到OAuth验证链接,获取员工