【问题标题】:jhipster oauth2 client secretjhipster oauth2 客户端密码
【发布时间】:2015-11-09 09:53:38
【问题描述】:

我一直在试验 jhipster。 我已将我的应用程序配置为使用 oauth2。 为此,我的 application.yml 中有一个客户端密码

根据我找到的有关此主题的几篇文章,客户端机密应始终保密。例如检查https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified

客户机密必须保密。如果已部署的应用程序(例如 Javascript 或本机应用程序)无法对机密进行保密,则不会使用机密。

我注意到生成的 auth.oauth2.service.js 包含纯文本的秘密:

        return {
            login: function(credentials) {
                var data = "username=" + credentials.username + "&password="
                    + credentials.password + "&grant_type=password&scope=read%20write&" +
                    "client_secret=mySecretOAuthSecret&client_id=myapp";
                return $http.post('oauth/token', data, {
                    headers: {
                        "Content-Type": "application/x-www-form-urlencoded",
                        "Accept": "application/json",
                        "Authorization": "Basic " + Base64.encode("myapp" + ':' + "mySecretOAuthSecret")
                    }
                }).success(function (response) {
                    var expiredAt = new Date();
                    expiredAt.setSeconds(expiredAt.getSeconds() + response.expires_in);
                    response.expires_at = expiredAt.getTime();
                    localStorageService.set('token', response);
                    return response;
                });
            },

我知道在缩小的 javascript 中找到它会有点困难,但是任何寻找“client_secret”的人都会很快得到回报。

我错过了什么吗?还是 jHipster oauth 实现不安全?

谢谢, 安迪

【问题讨论】:

    标签: oauth-2.0 jhipster


    【解决方案1】:

    由于像 jhipster 这样的 JS 客户端不能保持 client-secret “秘密”,因此使用 client-secret 根本没有意义。 jhipster 使用的 OAuth2 资源所有者密码凭证授予流程适用于非常受信任的客户端 - jhipster 的客户端是。它允许您跳过正常的“授权”端点并直接转到“令牌”端点以使用您的用户凭据获取令牌。如果您的 Spring Authorization Server (AS) 定义了一个客户端密钥,则您需要从客户端 JS 传递该密钥。但是,如果您从 AS 中的内存客户端设置中删除机密定义(例如,在 OAuth2ServerConfiguration.java 中注释掉该行),您可以在 JS 中完全忽略它(见下文)

    return {
       login: function(credentials) {
          var data = "username=" + credentials.username + "&password=" + credentials.password + "&grant_type=password&scope=read%20write&";
          return $http.post('oauth/token', data, {
             headers: {
                "Content-Type": "application/x-www-form-urlencoded",
                "Accept": "application/json",
                "Authorization": "Basic " + Base64.encode("myapp" + ':' + "")
             }
          }).success(function (response) {
             var expiredAt = new Date();
             expiredAt.setSeconds(expiredAt.getSeconds() + response.expires_in);
             response.expires_at = expiredAt.getTime();
             localStorageService.set('token', response);
             return response;
          });
       },

    删除您的客户端机密后,我认为您的应用程序实际上并没有更安全,但感觉更干净和诚实——因为您承认使用纯 JS 客户端,您只能如此安全的。对于 JS 和本机客户端,通常使用隐式流,它不会打扰客户端机密。它从更强大的授权代码授予流程中得到了简化,因为使用 JS 或本机客户端无法保密。

    无论如何,jhipster 可能不应该在 JS 源代码中包含客户端密钥,但我认为它不会造成任何伤害(因为唯一的选择是拥有一个不再安全的空白客户端密钥) .你不是不安全的(因为规范允许这种事情),但你会更安全使用授权代码流(这需要在 jhipster 实现中做一些工作)或者让一个轻量级服务器代理添加客户端-对“令牌”端点的请求的秘密,而不是直接来自 JS。服务器到服务器的通信(例如通过代理)使秘密远离浏览器的视图。

    看到这篇文章很好地讨论了使用 oauth2 的纯 JS 客户端的陷阱:http://alexbilbie.com/2014/11/oauth-and-javascript/

    这是一个将 oauth2 与 angularjs 结合使用并在代理上运行的示例:https://spring.io/blog/2015/02/03/sso-with-oauth2-angular-js-and-spring-security-part-v

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-07-06
      • 2018-06-05
      • 2018-03-13
      • 1970-01-01
      • 2019-08-05
      • 2017-06-15
      • 2012-08-22
      • 1970-01-01
      相关资源
      最近更新 更多