Oauth2 客户端应用程序是否需要 SSL 连接? [英] Are Oauth2 client apps required to have SSL connection?

查看:83
本文介绍了Oauth2 客户端应用程序是否需要 SSL 连接?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Oauth 2.0 的哪些方需要 SSL 连接?

Which parties of Oauth 2.0 are required to have an SSL connection?

  • 身份验证服务器:需要 SSL
  • 资源服务器:需要 SSL
  • 客户端应用:是否真的有必要,只要它使用 SSL 进行资源服务器通信?

推荐答案

根据 要求授权服务器使用 SSL/TLS规范,例如:

由于对授权端点的请求导致用户身份验证和明文凭证的传输(在HTTP 响应),授权服务器必须要求使用 TLS如第 1.6 节所述,向授权端点.

Since requests to the authorization endpoint result in user authentication and the transmission of clear-text credentials (in the HTTP response), the authorization server MUST require the use of TLS as described in Section 1.6 when sending requests to the authorization endpoint.

由于对令牌端点的请求导致传输明文凭据(在 HTTP 请求和响应中),授权服务器必须要求使用 TLS,如向令牌端点发送请求时的第 1.6 节.

Since requests to the token endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the authorization server MUST require the use of TLS as described in Section 1.6 when sending requests to the token endpoint.

相同的规范并不要求客户端应用程序使用它,但强烈推荐它:

That same specification does not require it for the client application, but heavily recommends it:

重定向端点应该要求使用所描述的 TLS在第 1.6 节中,当请求的响应类型是代码"或令牌"时,或者当重定向请求将导致传输开放网络上的敏感凭据.本规范不不强制使用 TLS,因为在撰写本文时,要求客户部署 TLS 对许多人来说是一个重大障碍客户端开发人员.如果 TLS 不可用,授权服务器应该在不安全的端点之前警告资源所有者重定向(例如,在授权期间显示消息请求).

The redirection endpoint SHOULD require the use of TLS as described in Section 1.6 when the requested response type is "code" or "token", or when the redirection request will result in the transmission of sensitive credentials over an open network. This specification does not mandate the use of TLS because at the time of this writing, requiring clients to deploy TLS is a significant hurdle for many client developers. If TLS is not available, the authorization server SHOULD warn the resource owner about the insecure endpoint prior to redirection (e.g., display a message during the authorization request).

缺乏传输层安全会对客户端及其授权的受保护资源的安全性访问.传输层安全的使用是特别的当授权过程用作一种形式时至关重要客户端委托的最终用户身份验证(例如,第三方签到服务).

Lack of transport-layer security can have a severe impact on the security of the client and the protected resources it is authorized to access. The use of transport-layer security is particularly critical when the authorization process is used as a form of delegated end-user authentication by the client (e.g., third-party sign-in service).

对资源服务器的调用包含访问令牌并需要 SSL/TLS:

Calls to the resource server contain the access token and require SSL/TLS:

访问令牌凭据(以及任何机密访问令牌属性)必须在运输和存储过程中保密,并且仅在授权服务器之间共享,资源服务器访问令牌对其有效,以及访问令牌所针对的客户端发布.访问令牌凭证必须仅使用 TLS 传输如第 1.6 节所述,服务器身份验证定义为[RFC2818].

Access token credentials (as well as any confidential access token attributes) MUST be kept confidential in transit and storage, and only shared among the authorization server, the resource servers the access token is valid for, and the client to whom the access token is issued. Access token credentials MUST only be transmitted using TLS as described in Section 1.6 with server authentication as defined by [RFC2818].

原因应该很明显:在任何这些不使用安全传输的情况下,令牌都可以被拦截并且解决方案是不安全的.

The reasons should be pretty obvious: In any of these does not use secure transport, the token can be intercepted and the solution is not secure.

您的问题专门调用了客户端应用程序.

You question specifically calls out the client application.

客户端应用:是否真的有必要,只要它使用 SSL 进行资源服务器通信?

Client apps: Is it really necessary, as long as it uses SSL for the resource server communication?

我假设您的客户端是一个 Web 应用程序,并且您正在谈论在身份验证发生后浏览器和服务器之间的通信.我还假设您提出了这个问题,因为(在您的实施中),这种通信不是通过访问令牌进行身份验证的,而是通过其他方式进行的.

I am assuming that you client is a web application, and you are talking about the communication between the browser and the server after authentication has happened. I am furthermore assuming that you ask the question, because (in your implementation), this communication is not authenticated with access tokens, but through some other means.

这就是你的答案:该通信以某种方式进行了身份验证.服务器如何知道谁在打电话?大多数网站使用他们在会话开始时设置的会话 cookie,并使用它来识别会话和用户.任何可以获取该会话 cookie 的人都可以劫持该会话并冒充用户.如果您不希望那样(而且您确实不希望那样),则必须使用 SSL/TLS 来保护浏览器和服务器之间的通信.

And there you have your answer: that communication is authenticated in some way or another. How else would the server know who is making the call? Most web sites use a session cookie they set at the beginning of the session, and use that to identify the session and therefor the user. Anyone who can grab that session cookie can hijack the session and impersonate the user. If you don't want that (and you really should not want that), you must use SSL/TLS to secure the communication between the browser and the server.

在某些情况下,客户端的浏览器部分直接与资源服务器对话;服务器部分仅提供静态内容,例如 HTML、CSS、图像以及最后但并非最不重要的 JavaScript.也许您的客户端是这样构建的,您想知道静态内容是否必须通过 SSL/TLS 下载?好吧,如果不是,中间的人可以插入他们自己的恶意 JavaScript,窃取您用户的访问令牌.您确实希望保护静态内容的下载.

In some cases, the browser part of the client talks to the resource server directly; and the server part only serves static content, such as HTML, CSS, images and last but not least, JavaScript. Maybe your client is built like this, and you are wondering whether the static content must be downloaded over SSL/TLS? Well, if it isn't, a man in the middle can insert their own evil JavaScript, that steals you user's access tokens. You do want to secure the download of static content.

最后但并非最不重要的一点是,您的问题是基于一个隐藏的假设,即可能存在不使用 SSL/TLS 的正当理由.人们经常声称证书的成本太高,或者加密需要太多​​的 CPU 能力,因此需要更多的硬件来运行应用程序.我不认为这些成本在几乎所有情况下都是显着的.与构建和运行解决方案的总成本相比,它们非常低.与不使用加密的风险相比,它们也非常低.不要花时间(和金钱)讨论这个问题,只需全程使用 SSL/TLS.

Last but not least, your question is based on a hidden assumption, that there might be valid reasons not to use SSL/TLS. Often people claim the cost of the certificate is too high, or the encryption requires too much CPU power, hence requiring more hardware to run the application. I do not believe these costs to be significant in virtually all cases. They are very low, compared to the total cost of building and running the solution. They are also very low compared to the risks of not using encryption. Don't spend time (and money) debating this, just use SSL/TLS all the way through.

这篇关于Oauth2 客户端应用程序是否需要 SSL 连接?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆