5

我将angular-oauth2-oidc库与隐式流（带有 IdentityServer4 服务器）结合使用。我已经成功设置了文档中的静默刷新建议。

这是我在包装服务中引导事物的方式：

private userSubject = new Subject<User>();

constructor(private config: ConfigService, private oAuthService: OAuthService)
{ }

// Called on app load:
configure(): void {
    const config: AuthConfig = {
      issuer: this.config.getIdentityUrl(),
      logoutUrl: this.config.getIdentityUrl() + '/connect/endsession',
      redirectUri: window.location.origin + '/',
      silentRefreshRedirectUri: window.location.origin + '/silent-refresh.html',
      clientId: 'my_client_id',
      scope: 'openid profile my_api',
      sessionChecksEnabled: true,
    };

    this.oAuthService.configure(config);
    this.oAuthService.tokenValidationHandler = new JwksValidationHandler();

    this.oAuthService
      .loadDiscoveryDocumentAndLogin()
      .then((_) => this.loadUserProfile());

    this.oAuthService.setupAutomaticSilentRefresh();
}

private loadUserProfile() {
  this.oAuthService.loadUserProfile()
    .then((userProfile) => {
      const user = new User(userProfile['name']);
      this.userSubject.next(user);
    });
}

但是，如果我在新选项卡中打开应用程序，用户也会被重定向到 IdentityServer（并立即返回我的应用程序）。

我的问题：我可以让图书馆从同源的其他选项卡中检索现有的访问令牌（以及可选的用户信息），以防止重定向？（首选，因为它不需要 Ajax 调用。）

或者，在我们将某人发送到 IdentityServer 之前，是否有一种简单的方法可以尝试使用静默刷新机制？

4

2 回答 2

7

sessionStorage首先：我不知何故得到了适合代币的想法，并且localStorage应该始终避免。但这是来自另一个涉及更强大（刷新）令牌的项目，并且通过隐式流程，我只有短暂的访问令牌，因此localStorage也不比sessionStorage. 最后：根据您自己的具体情况评估攻击媒介：“这取决于”。

我没有提到我有这个想法，而另一个答案帮助我重新思考事情并考虑使用 localStorage。这实际上是一个很好的解决方案。

事实证明，该库已内置支持localStorage用作令牌和其他数据的后备存储。起初虽然我在尝试：

// This doesn't work properly though, read on...
this.oAuthService.setStorage(localStorage);

但是这种引导方式不适用于我的情况，请参阅库 GitHub 问题列表中的问题 321 以获取我的登录信息。从该线程重复解决方案（或解决方法？），我通过在应用程序模块中执行此操作解决了问题providers：

{ provide: OAuthStorage, useValue: localStorage },

现在库将正确使用 localStorage 并且新选项卡（甚至新窗口）将自动选择它。

作为脚注，如果您出于安全原因不想使用localStorage，您也可以提供自己的存储，只要它实现OAuthStorage接口即可。然后，您自己的实现可以使用任何可用的选项卡间通信技术来“询问”来自其他选项卡的数据，如果需要，可以回退到 sessionStorage。

于 2018-05-18T09:47:47.037 回答
1

有一个解释，为什么它总是去 IdentityServer 来澄清当前用户，它是你展示的代码。

每次打开选项卡时，都会启动您的应用程序，并执行上面的代码。现在 - 所有这些支持 SPA'a 和Implicit流程的 oidc 库都将用户数据 ( access_token... ) 存储在浏览器会话存储中。通过打开一个新选项卡，您将拥有一个新会话。

我的意思是 - 在尝试对 Identity Server 进行身份验证之前，您需要做一些事情。我指的是诸如将所有用户信息从Session storage, 移动到Local storage. 然后，位于同一应用程序（分别为同一来源）下的选项卡将具有共享的Local storage.

所以你在应用程序开始的流程应该是这样的：

  1. 检查本地存储以获取用户信息
  2. 如果存在，请设置身份验证服务（包括静默刷新），但不要尝试登录。并将数据移动到会话存储（不确定是否需要，但我猜图书馆会在那里寻找它）
  3. 如果没有 - 登录，然后将数据从会话存储移动到本地
  4. 当然，在静默更新回调中，您必须更新本地存储中的值（它们应该由会话中的库更新）。
  5. 最后但并非最不重要的一点是 - 在注销时，您必须进行清理。

对我来说，这似乎是你的解决方案。现在 - 由您决定是否值得。

PS：只是为了澄清-我还没有尝试过。我不能保证它会起作用，但是按照事件的顺序，它应该会起作用。

于 2018-05-16T15:21:49.517 回答