Question

我们有一个Identity Server 3实例，该实例已经与各种客户端一起使用了一段时间，其中一些使用隐式流，其他使用客户端凭据。现在，我们对将iOS本机应用程序与此身份提供程序集成在一起提出了新的要求。我知道这些天不建议使用隐式流程，而面向公众的应用则应该使用授权代码流程。此类建议的示例为here和here。

据我所知，授权码流程具有一个步骤，通过将接收到的授权码与客户端ID和密码一起提供，可以通过某个反向通道将其转换为JWT令牌。但是，对于SPA和本机应用程序，我们无法存储秘密。我的found here指南建议我可以简单地忽略connect/token请求中的秘密，但是到目前为止，我的测试尚未证实这一点。所以我被卡住了。为了演示，我在我的IS3本地实例上设置了一个客户端以进行以下测试：

{
    'clientId': 'test',
    'flow': 'AuthorizationCode',
    'name': 'test',
    'redirectUris': [ 'http://localhost:8080/' ], 
    'scopes': ['openid','profile']
}

然后我向自己的IdP发出以下GET请求：

[ID_PROVIDER]/connect/authorize?client_id=test&redirect_uri=http%3A%2F%2Flocalhost%3A8080&scope=openid%20profile&response_type=code

这使我可以登录，并将我返回到运行在http://localhost:8080的测试应用中，并在查询字符串中输入了我的授权代码。

我现在尝试通过将POST更改为[ID_PROVIDER]/connect/token并使用以下正文来交换JWT令牌的代码：code=[AUTH_CODE]&grant_type=authorization_code&client_id=test&redirect_uri=http%3A%2F%2Flocalhost%3A8080

但是Identity Server拒绝此操作，并显示HTTP 400和invalid_client错误。当我浏览其日志时，会看到一个ClientSecretValidator事件，消息为“找不到客户端密码”。根据我上面概述的理解，哪种方式有意义，但是鉴于人们建议将这种流程用于面向公众的应用程序，所以我一定会误解。

如果有人可以澄清那太好了，谢谢。

Answer 1

您不能只是忽略客户机密。对于您的本机情况，我会考虑将秘密嵌入到应用程序中。授权请求仍将必须验证return_uri（您的本机应用程序的自定义URI方案），如果仍然感到不安全，您还可以依靠所有权证明（PoP）令牌（https://identityserver.github.io/Documentation/docsv2/pop/overview.html）。

对于SPA应用程序，我将其保留为隐式流程，我认为在其中进行秘密操作毫无意义。

使用SPA为Identity代码流配置Identity Server 3的正确方法是什么？

1 个答案: