Questions tagged «authentication»

我想在网络上公开资源。我想保护此资源：确保只有某些个人可以访问它。 我可以设置某种基于密码的身份验证。例如，我只能允许在提供文件之前通过Web服务器访问资源，该Web服务器检查传入的请求以获取正确的凭据（可能针对用户的某些后备数据库）。 或者，我可以只使用私有URL。就是说，我可以简单地将资源托管在一些无法猜到的路径上，例如https://example.com/23idcojj20ijf...，它将访问权限限制为知道确切字符串的用户。 从想访问此资源的邪恶者的角度来看，这些方法是否等效？如果没有，是什么使它们与众不同？就可维护性而言，在实施一种或另一种方法之前，我应该意识到这两种方法的优缺点吗？

128 security  authentication 

浏览器指纹识别是唯一识别匿名用户的足够方法吗？如果您合并了诸如鼠标手势或键入模式之类的生物特征数据，该怎么办？ 前几天，我遇到了Panopticlick实验EFF在浏览器指纹上运行。 当然，我立即想到了隐私权的影响以及如何将其用于邪恶。但另一方面，这可以用于极大的好处，至少，这是一个诱人的问题。 在研究该主题时，我发现一些公司使用浏览器指纹来攻击欺诈行为。发送完几封电子邮件后，我可以确认至少有一个主要的约会网站正在使用浏览器指纹作为一种检测假帐户的机制。（注意：他们发现，当扩展到数百万个用户时，它还不够独特，无法充当身份。但是，我的程序员的大脑不想相信他们。） 这是一家使用浏览器指纹进行欺诈检测和预防的公司：http : //www.bluecava.com/ 这是您可以在浏览器中用作唯一标识符的内容的非常全面的列表：http : //browserspy.dk/

96 authentication  identity  online-identity 

我无法理解将base64解码后使JWT的索偿/净荷公开可见的原因。 为什么？ 用秘密对它进行加密似乎会更加有用。 有人可以解释为什么或在什么情况下公开此数据很有用吗？

30 security  json  authentication  jwt 

我已经阅读了有关身份验证的内容，并对类型分类感到困惑。 让我们从基于Cookie的身份验证开始，如果我理解正确的话，关键是用户身份验证所需的所有数据都存储在cookie中。这是我的第一个困惑：我们可能会在Cookie中存储 会话ID，因此它成为基于会话的身份验证？ 索赔，因此应将其称为基于索赔的身份验证吗？ 我发现有些人甚至将JWT令牌存储在cookie中，但这似乎是自定义身份验证流的自定义实现... 现在，我们切换到基于声明的身份验证。主要元素是索赔，索赔的集合可以用作容器 Cookies（如上所述） 令牌（以JWT为例）。 另一方面，当我们谈论令牌时，它可能包含任何类型的信息...例如会话ID ... 那我错过了什么呢？人们为什么在谈论身份验证类型时不定义诸如Cookie-Session-based或Token-Claims-based身份验证之类的东西？

25 authentication 

对于我的工作，我们有一个不错的RESTful Web服务，我们已经建立了该服务，用于驱动我们拥有的几个网站。基本上，Web服务使您可以创建和使用支持凭单，并且网站负责前端。任何网络服务请求都使用auth标头，我们使用该标头来验证用户及其每次呼叫的密码。 今年，我们正在寻求扩展登录选项，以便网站上的用户可以通过Google，Twitter和Facebook（可能还有其他）登录。但是，我在弄清楚如何设计该结构方面很麻烦，因此Web服务可以使用第三方身份验证提供程序来确保用户就是他们所说的。是否有最佳实践来做到这一点？ 当前，我们正在考虑让网站处理用户本身的身份验证，然后使用一个新的setSessionId调用来将其当前会话注册到Webservice后端。对Web服务的每个其他请求都将传递该sessionId并将对其进行验证。这些看起来还可以，但是我的内心深处感到我没有考虑透彻，所有浏览和阅读oauth和openid规范的论坛都让我更加困惑。有什么技巧可以解决这个问题吗？

25 web-services  rest  authentication  oauth  openid 

我已经安装了Windows 10和Git。这个Git使用我的C:/Users/MyName目录作为HOME目录以及其中的/.ssh/目录，以适当地获取我的私有SSH密钥。 我刚刚启用并设置了“ Windows上的Ubuntu上的Bash”（真是个大难题！），并且还在其中安装了Git。我希望两个Gits都使用相同的密钥集，这样无论我在此计算机上工作的环境如何，我的提交始终来自我。 麻烦的是，bash中的HOME目录不同（/home/MyName），因此看不到位于现在远处的键../../mnt/c/Users/MyName/.ssh。我以为我可以通过使用以下方法更改HOME环境变量来成为赢家 export HOME=/c/mnt/Users/MyName 这确实成功更改了HOME目录，但bash git仍然看不到该./.ssh目录中包含的密钥。 我不确定这是否是A），因为bash git期望键采用其他文件格式？（当前是id_rsa和id_rsa.pub）B）bash git忽略更改后的HOME变量？或两者兼而有之。 我也不确定C）像这样随意更改HOME变量是否在一般情况下是一个好主意，而其他可能引用它的程序也可以吗？

18 git  authentication  bash  ubuntu  windows-10 

我在HTTP标头中使用JWT令牌来验证对资源服务器的请求。资源服务器和身份验证服务器是Azure上的两个单独的辅助角色。 我不能决定应该将请求存储在令牌中还是将请求附加到请求/响应中。Claims列表影响客户端UI元素的呈现以及对服务器上数据的访问。因此，在处理请求之前，我想确保服务器收到的声明是真实的并经过验证的。 声明示例包括：CanEditProductList，CanEditShopDescription，CanReadUserDetails。 我要为其使用JWT令牌的原因是： 更好地防止客户端对声明进行编辑（即入侵声明列表）。 无需在每个请求上查找索赔。 我不想使用JWT令牌的原因： 然后，身份验证服务器必须知道以应用程序为中心的声明列表。 令牌成为黑客入侵的单一点。 我读过几句话说，JWT令牌不用于应用程序级数据。 在我看来，两者都有缺点，但是我倾向于将这些声明包含在令牌中，并且只想由以前处理过此问题的人员来处理。 注意：我将对所有API请求使用HTTPS，因此在我看来，令牌将“足够”安全。我正在使用AngularJS，C＃，Web API 2和MVC5。

18 security  http  authentication  authorization 

我正在设计一个通过API密钥使用授权/身份验证的REST API。 我试图找出最合适的位置，然后发现许多人建议使用自定义HTTP标头ProjectName-Api-Key，例如： ProjectName-Api-Key: abcde 但在Authorization标头上使用自定义方案也是可能的，从思想上来说也是正确的，例如： Authorization: ApiKey abcde 另一方面，我发现一个考虑，自定义授权方案可能出乎意料，并且不受某些客户端支持，并且无论如何都会导致自定义代码，因此最好使用自定义标头，因为客户对此没有任何期望。 您希望以哪种方式发送API密钥？

17 rest  api  authentication  authorization  headers 

我正在构建一个使用JWT令牌进行用户身份验证的RESTful API（由login端点发出，然后在所有标头中发送），并且需要在固定时间后刷新令牌（调用renew端点，该端点将返回更新的令牌） ）。 用户的API会话有可能在令牌到期之前变得无效，因此我的所有端点都首先检查以下各项：1）令牌仍然有效，以及2）用户会话仍然有效。由于客户端将令牌存储在本地，因此无法直接使令牌无效。 因此，我所有的端点必须向我的客户发出两种可能情况的信号：1）是时候续订令牌了； 2）会话已变为无效，并且不再允许它们访问系统。我可以想到两种替代方法，当两种情况之一发生时，我的端点可以向其客户端发出信号（假设客户端可以适应任一选项）： 如果会话无效，则返回http 401代码（未经授权），或者在令牌到期且需要调用renew端点时返回412代码（前提条件失败），这将返回200（正常）代码。 返回401，表示会话无效或令牌已过期。在这种情况下，客户端将立即调用该renew端点，如果它返回200，则刷新令牌，但是如果renew还返回401，则意味着该客户端不在系统之外。 您会推荐上述两种选择中的哪一种？哪一个会更标准，更容易理解和/或更RESTful？还是您会建议完全不同的方法？您发现这两种选择有明显的问题或安全隐患吗？如果您的答案包括支持您的观点的外部参考，则可以加分。 更新 伙计们，请关注一个真正的问题- 表示续订/会话无效的两个http代码替代方案中哪一个最好？不要介意我的系统使用JWT 和服务器端会话的事实，这是我的API针对非常特定的业务规则的特性，而不是我正在寻求帮助的部分;）

17 design  rest  web-services  http  authentication 

当API要求客户端对其进行身份验证时，我已经看到使用了两种不同的方案，并且我想知道哪种情况适合我的情况。 示例1.一个公司提供的API，允许第三方使用HTTP Basic使用令牌和机密进行身份验证。 示例2. API通过HTTP Basic接受用户名和密码来认证最终用户。通常，他们会获得令牌以供将来请求。 我的设置：我将有一个JSON API，它将用作移动和Web应用程序的后端。对于移动应用程序和Web应用程序来说，似乎都附带令牌和秘密发送的好习惯，因此只有这两个应用程序才能访问阻止任何其他第三方的API。 但是移动和Web应用程序允许用户登录和提交帖子，查看其数据等。因此，我希望他们也可以通过HTTP Basic在每次请求时登录。 我会以某种方式同时使用这两种方法还是仅在每个请求上发送最终用户凭据（用户名和令牌）？如果仅发送最终用户凭据，是否将它们存储在客户端的Cookie中？

17 api  rest  authentication 

我刚刚读了这篇已有几年历史的文章，但是描述了一种保护REST API的聪明方法。实质上： 每个客户都有唯一的公钥/私钥对 只有客户端和服务器才知道私钥。它永远不会通过电线发送 对于每个请求，客户端都会获取多个输入（整个请求本身，当前时间戳和私钥），并通过HMAC函数运行它们以生成请求的哈希 然后，客户端将常规请求（包含公钥）和哈希发送到服务器 服务器会查询客户端的私钥（基于提供的公钥），并进行一些时间戳检查（我当然不理解），以验证请求是否不是受害对象。 重播攻击 如果一切正常，则服务器使用私钥和相同的HMAC函数来生成其自己的请求哈希 然后，服务器比较两个哈希（客户端发送的哈希值以及它生成的哈希值）；如果它们匹配，则对请求进行身份验证并允许其继续 然后我偶然发现了JWT，听起来很相似。但是第一篇文章根本没有提到JWT，因此我想知道JWT是否与上述auth解决方案不同，如果有所不同，怎么做。

16 security  rest  authentication  keys  hmac 

我即将开始一个新项目，该项目针对所有主要移动平台（iOS，Android，Windows）的移动应用程序。这将是一个客户端-服务器架构。 该应用程序具有信息性和交易性。对于交易而言，他们必须先拥有一个帐户并登录才能进行交易。我是移动开发的新手，所以我不知道在这些平台上如何完成身份验证部分。客户端将通过REST API与服务器通信。当然会使用HTTPS。 我尚未决定是否要让用户在打开应用程序时登录，还是仅在执行交易时登录。 我有以下问题： 1）像Facebook应用程序一样，您只有在首次打开该应用程序时才输入凭据。之后，您每次打开应用程序都会自动登录。如何做到这一点？只是简单地通过将凭据加密并存储在设备上并在每次应用启动时发送凭据即可？ 2）我是否需要针对对REST API进行的每个（交易）请求对用户进行身份验证，或使用基于令牌的方法？ 请随时提出其他验证方式。 谢谢！

16 rest  authentication  mobile 

我们计划将公司系统重构为基于微服务的系统。该微服务将由我们自己的公司内部应用程序以及需要的第三方合作伙伴使用。一种用于预订，一种用于产品等。 我们不确定如何处理角色和范围。这个想法是创建3个基本用户角色，例如Admins，Agent和End-Users，并让消费者应用程序根据需要微调作用域。 管理员可以默认（针对其公司）创建，更新，读取和删除所有资源。 代理可以为其公司创建，更新和读取数据。 最终用户可以创建，更新，删除和读取数据，但不能访问与代理或管理员相同的端点。他们也将能够创建或修改数据，而不必与代理或管理员处于同一级别。例如，最终用户可以更新或阅读他们的帐户信息，就像代理可以为他们完成此操作一样，但他们看不到或更新管理员注释。 假设代理默认情况下可以为其公司创建，读取和更新每个资源，这是可以为其令牌/会话请求的最大范围，但是客户端（API使用者）应用程序的开发人员已决定他们的代理之一可以仅读取和创建某些资源。 更好的做法是在我们的内部安全性中处理此问题，然后让他们在数据库中写入该数据，还是让客户端通过请求范围较小的令牌在内部进行处理，并让他们编写哪个代理在数据库中具有哪个范围？这样，我们仅需跟踪令牌范围。 不利的一面是，我们的团队还需要在内部应用程序中创建经过微调的访问机制。 用这种思维方式，微服务及其授权系统不应受到客户需求的困扰，因为它们只是消费者，而不是系统的一部分（即使其中一些消费者是我们自己的内部应用程序）？ 这是一个好的方法吗？

15 security  authentication  microservices  authorization 

我一直在开发将支持许多用户的应用程序。问题是我不知道如何验证客户端/用户。 我正在构建一个http://quickblox.com/之类的应用程序，在该应用程序中我将向用户提供凭据，他们将使用这些凭据来构建N个应用程序，在这些应用程序中，他们无法输入用户名和密码来进行身份验证。 让我们假设它如下。（就像QuickBlox一样） 1.用户在我的网站上创建帐户。 2.用户可以创建N个API密钥和保密凭证。（对于多个应用程序） 3.用户将在其应用程序（Android，iOS，Javascript等）中使用这些凭据与我的REST API进行通信。（REST API具有读写访问权限。） 我的顾虑？ 用户会将其凭据（API密钥和秘密密钥）放入他们构建的应用程序中，如果有人获得了这些密钥并尝试模仿用户该怎么办？（通过反编译APK或直接查看JavaScript代码。 我在某处错了吗？我对构建这种三级用户机制感到困惑。

14 design-patterns  architecture  api-design  authentication  enterprise-architecture 

我从概念的角度（即私钥/公钥）背后的数学，使用哈希和加密来签署证书，使用交易或文档进行数字签名等，对PKI相当了解。 C库与用于安全通信和身份验证的证书一起使用。我也非常熟悉openssl命令行工具。 但是，我对基于Web的启用PKI的项目几乎没有经验，因此我试图设计和编写个人项目以更好地理解这一点。 要求 这是一家银行的网站。允许所有网上银行用户使用由一些已知CA（verisign，Thawte，entrust等）颁发的任何证书。银行不负责为用户购买证书。这些证书将用于银行网站的身份验证。平台/操作系统等仍未修复。 设计 我想知道什么是进行身份验证的最佳方法。 我看到Apache有一种启用2种方式的SSL的方法-在这种情况下，我认为导航到该网站会自动向用户请求证书。但是我不确定这是否足够，因为似乎它所验证的只是证书是否由受信任的CA签名，还可能是证书是否位于证书主题行的白名单中，等等。但这还不够银行案例，因为您需要能够将bankuserid与证书相关联。 IIS似乎有一种方法可以让我为Active Directory中的每个用户存储证书。通过阅读几篇MSDN文章，我了解了这一点。您在IIS中打开2种方式的SSL，然后，当用户尝试导航到网站时，IIS将向浏览器发送带有已批准CA列表的请求，浏览器将允许用户从其证书库中选择适当的证书并将其发送到后端。我假设IIS将做2件事 确保用户具有与证书相对应的私钥（通过掩盖协商） IIS根据AD用户证书映射，将用户名报告给应用程序。 通过调用加密函数显式地进行身份验证，而不是依赖于依赖于Web服务器的身份。 显示一个用户屏幕，在该屏幕上他上传证书，并且应用程序确保用户具有与证书相对应的私钥（通过要求前端使用证书对某些字符串进行签名）。 该应用程序具有数据库，其中存储了一些数据，该数据允许每个用户映射到其用户ID。这可能是 与每个用户标识相对应的整个证书 与每个用户ID对应的CA和证书序列号。 我想知道哪种是常用的方法？最佳做法是什么？如果我应该选择＃3，那么最好的方法是什么？ 可以轻松与智能手机应用程序一起使用的功能将是额外的好处。 更新资料 让我澄清一下我的声明“自己编写身份验证部分”，因为某些答案似乎表明它已经被误解了-我的缺点是不清楚。 这并不意味着我自己写加密货币。这只是意味着我实际上将显式调用加密例程，而不是依赖IIS或任何其他Web服务器隐式地执行加密例程。

14 authentication