关于 OAuth 与内部用户管理的使用的简单英语解释
我是 OAuth 新手，虽然我扫描了许多文档，但我似乎还没有一个好的安全 Web 应用程序架构/设计，无法回答大多数/全部 OWASP 十大问题
我的新手问题是
- “为什么可以”我只是纯粹依赖 OAuth？为什么用户在我自己的应用程序中需要凭据？
- 如果我这样做，如果我保存它，我需要哈希/盐吗？我不存储任何密码，但是令牌呢？
- 我仍然需要保留用户，这样他们就不会每次都登录（就像在操作系统中一样）-我吗
- 以某种方式使用 OAuth 令牌（保存它？它是否有意义）？
- 或者使用普通的旧式 httpOnly 安全 cookie（如果是这样，如果他们退出 Oauth 提供程序会发生什么？在这种情况下我不应该忽略我的 cookie 并让他们退出吗？
- 我如何实现注销？我不能强制他们退出 OAuth 提供程序，如果我只删除 httpOnly cookie/使他们的会话在本地无效，那么
- 在批准后我如何实现单点登录？再次点击“使用 Facebook / Twitter / Google 登录”我想要类似于 SO 的效果（页面刷新和“欢迎您回来”，最好的做法是什么？为什么 SO 刷新页面（我认为这与事实上它需要在客户端，但我不完全理解它是如何工作的，甚至不知道要问什么）
我想我有很多东西要学，但是阅读了这么多潜在的安全问题，并且必须掌握这么多不同的问题主题对我来说似乎是一个很好的潜力，错过了一些东西稍后有人会利用。
使用 Spring Security 等框架或使用 Lift 的内置用户管理会帮我解决所有这些麻烦吗？或者我是否必须确切地知道我在做什么以避免会话固定、跨站点请求伪造、跨站点脚本、彩虹表和其他我只能远程获取的东西......
I'm new to OAuth, and although I have scanned through many documents, I don't seem to have yet a good architecture / design to a secure web application, answering most/all of OWASP Top Ten
My newbie questions are
- Why can't I just rely purely on OAuth? why do a user needs credential in my own application?
- If I do, do I need hash / salt anything if I save it? I don't store any passwords, but what about tokens?
- I still need to persist the users so they won't login everytime, (like in OS) - do I
- Somehow use the OAuth token (save it? does it make even sense)?
- Or use the plain old httpOnly secure cookie (if so, what happens if they log out of the Oauth provider? shouldn't I in this case ignore my cookie and let them log out?
- How do I implement logging out? I can't force them to log out of the OAuth provider, and if I only delete the httpOnly cookie / invalidate their session locally, is that enough? and security issues?
- How do I implement single sign on? I don't want the user, after approving to click again "log in using Facebook / Twitter / Google" I want an effect similiar to SO (page refreshes and "welcomes you back" what are the best practices to do that? Why does SO refreshes the page (I assume it has to do with the fact it needs to be client side, but I don't fully understand how it works to even know what to ask)
I guess I have a lot to learn, but reading on so many potential security issues, and having to master so many different topics seems like a good potential for me missing something that someone later will exploit.
Is using a framework such as Spring Security, or using Lift's built in user management going to save me all this headache? or do I have to know exactly what I am doing to avoid things like Session Fixation, Cross Site Request Forgery, Cross site scripting, Rainbow tables and other things I only remotely get...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从服务提供商的角度来看，OAuth 是控制第三方应用程序对业务逻辑的访问的一种手段。最终用户不必向第三方应用程序提供密码，并且可以控制访问。例如，提供商可以在有限的时间内限制仅访问部分服务。
如果您编写第三方应用程序，则并不严格需要拥有“自己的”用户工件。您可以信赖对您的应用程序进行身份验证的用户。
您可以要求用户拥有 Facebook 或 Twitter 等提供商的帐户，并且不要自己实施任何密码内容。
（您可能需要某种工件来代表用户，在这种情况下，它应该包含有关该用户如何对您的应用程序进行身份验证的信息，例如 OAuth 令牌或 OpenID URL）。
需要澄清的是，在 OAuth 中，令牌通常既是密钥又是秘密，并且需要以明文形式对请求进行签名（此处存在差异，具体取决于您使用的 OAuth 版本）。因此，您可以加密存储它们，只要它对您来说是可逆的。
是的，这是有道理的，令牌代表您的应用程序对特定用户数据的访问。如果您想保持“会话”活动，请保存令牌。
不存在从 OAUth 中“登录”的概念，令牌要么有过期时间，要么没有。您当然可以通过简单地选择忘记令牌来“注销”。下次您必须重新进行身份验证。您不能强迫用户使访问令牌失效，除非提供商有相应的 API。
您可以将令牌保存在 cookie 中，但我会为您想要保持活动状态的会话使用其他唯一标识符。您可以保留令牌服务器端的详细信息。您存储在 cookie 中的信息应该可以检索您需要的令牌。
如果您将令牌保存在数据库中，请保存ID为了这个令牌在一个很好的安全当用户访问您的服务时，使用 cookie 中的信息从您的服务向服务提供商进行调用，以检查令牌是否仍然有效，如果有效，则您已建立了足够的信任“。在您的应用程序中登录“用户，而不必再次经历 OAuth 过程的痛苦。
另一方面，StackOverflow 使用 OpenID 而不是 OAuth 进行用户身份验证。OAuth 可以用于相同的目的，但主要是一种规范 对申请授权
我希望这 有所帮助，并且不要低估自己。这个网站是用来发帖提问的，不是用来显得无所不知的。
From a service providers perspective, OAuth is a means of controlling access of third party applications to the business logic. The end user does not have to give out his password to the third party app, and the access can be controlled. For example, the provider could restrict the access to only parts of the service for limited amount of time.
If you write a third party application, there is no strict need for you to have your "own" user artifacts. You can rely on the users that authenticate your application.
You could require that user's have an account with a provider such as Facebook or Twitter and not implement any password stuff yourself.
(You probably need some sort of artifact to represent a user, it should in this case contain information about how that user authenticates your application, for instance an OAuth token, or an OpenID URL).
Just to clarify, in OAuth a token is typically both a key and a secret, and they are needed in cleartext to sign requests (there are differences here depending on which version of OAuth you use). So you can store them encrypted, as long as it is reversible for you.
Yes this makes sense, a token represents your applications access to a specific user's data. Save the token if you want to keep a "session" alive.
There is no concept of "logging" out of OAUth, a token either has an expiration time or not. You can of course "log out" by simply choosing to forget the token. The next time you will have to redo the authentication. You cannot force users to invalidate an access token, unless the provider has an API for that.
You could save the token in a cookie, but I would use other unique identifiers for the session you want to keep alive. You can persist the details of the tokens server side. The information you store in your cookie shold make it possible to retrieve the token you need.
If you save a token in a database, save an ID for that token in a nice secure cookie. When a user goes to your service, use the information in the cookie to make a call from your service, to the service provider, to check if the token is still valid. If so, you have established enough trust for you to "log in" the user in your application without having to go through the pain of the OAuth process again.
And as a side not, StackOverflow uses OpenID and not OAuth for user authentication. OAuth can be used for the same purpose but is mainly a specification for application authorization.
I hope this helped, and don't sell yourself short. This site is for posting questions, not for appearing all-knowing.