带有"native.hybrid"客户端的WinFormsSample不再起作用? [英] WinFormsSample with 'native.hybrid' Client does no longer work?
问题描述
如果我将此示例中的客户端更改为"native.hybrid" https://github.com/IdentityModel/IdentityModel.OidcClient.Samples/tree/master/WinFormsWebView
if I change the client in this sample to 'native.hybrid' https://github.com/IdentityModel/IdentityModel.OidcClient.Samples/tree/master/WinFormsWebView
并设置 流= OidcClientOptions.AuthenticationFlow.Hybrid
and set Flow = OidcClientOptions.AuthenticationFlow.Hybrid
然后登录IS4(延迟5秒)即可，但是默认的网络浏览器中会出现一个新的登录表单.
then the login to IS4 works (after a 5s delay), but a new login form appears in my default web browser.
与客户端"interactive.public"一起正常工作.我的问题是本机寡妇应用程序应该使用流动性最强的软件吗?我的意思是它是"OpenID Connect混合流"，请参见 https://identityserver4.阅读thedocs.io/en/latest/topics/grant_types.html
With the client 'interactive.public' works fine. My question is wich flow should I used for my native widows app? I mean it is the 'OpenID Connect Hybrid Flow' see https://identityserver4.readthedocs.io/en/latest/topics/grant_types.html
如果要使用混合流，如何适应此样本?
If to use the hybrid flow, how can adapt this sample?
推荐答案
选择与OIDC一起使用的授权的当前经验法则是:
The current rule of thumb for choosing the grant to use with OIDC is:
-
机器到机器的通信:使用ClientCredentials .
交互式客户端(Web应用程序，SPA或本地/移动应用程序):使用代码+ PKCE
ClientCredentials :该流程包括对令牌端点的单个请求，提供client_id和client_secret(如用户名/密码)以根据权限对自身进行身份验证.
ClientCredentials: This flow consists on a single request to the token endpoint, providing a client_id and a client_secret (like a user/password) to authenticate itself against the authority.
代码+ PKCE :此流包含两个请求:
Code+PKCE: This flow consists on two requests:
-
在任何情况下都将使用Web浏览器在Front-Channel中完成对端点进行授权的请求，并且将通过重定向到提供的
redirect_uri(以前在服务器上配置)进行响应(如果成功). ).在此重定向中，授权机构将在其他参数中添加代码"作为片段"或查询"(example.com/signin#code=1234).
A request to authorize endpoint which will be done in Front-Channel, using a web browser in any case, and will respond (if succeed) with a redirection to the provided
redirect_uri(previously configured on the server). In this redirection the authority will add the "code" among other parameters as "fragment" or "query" (example.com/signin#code=1234).
对令牌端点的请求，提供接收到的代码，这些代码将以请求的实际令牌进行响应.
A request to the token endpoint providing the received code that will respond with the actual token requested.
这里的问题是如何对发出第二个请求的客户端进行身份验证.在混合流中，我们使用秘密，例如使用客户端凭据，问题不是所有应用程序都能够安全地维护此秘密(即:SPA将所有代码都加载到客户端浏览器上，因此任何人都可以窃取该秘密. )(这就是为什么我们区分机密(能够保护机密安全)和公共客户).
The problem here is how to authenticate the client making the second request. In Hybrid flow we use a secret, like with client credentials, problem is not all the applications are able to maintain this secret securely (ie: an SPA loads all its code on the client browser so the secret will be there for anyone to stole it) (this is why we make distinction between confidential (able to keep secret secure) and public clients).
这是PKCE派上用场的时候:它通过添加额外的检查来增强此流程的安全性:
Here is when PKCE comes in handy: It enhances the security of this flow by adding an extra check:
-
在第一个授权请求中，客户端先前创建了一个随机字符串"asdfasdf"并计算其哈希值.该哈希值将与用于计算该哈希值的算法一起添加到请求中，例如:SHA256.
In the first request to authorize, the client previously creates a random string "asdfasdf" and computes its hash. This hash gets added on the request along with the algorithm used to compute it, eg: SHA256.
在第二个请求中，客户端将字符串包括在纯文本"asdfasdf"中，这样，授权机构可以计算该字符串的哈希值，并检查其是否与第一个请求中提供的匹配.如果是这样，那么我们可以得出结论，发出第二个请求的客户端与发出第一个请求的客户端相同.鉴于第一个请求在先前配置的redirect_uri上结束，只有授权的客户端才能完成该流程.
In the second request, the client includes the string in plain text "asdfasdf", this way the authority can compute the hash of this string and check if it matches with the provided on the first request. If it does, then we can conclude that the client making the second request is the same as the one that made the first request. Given that the first request ends on a previously configured redirect_uri only the authorized client can complete the flow.
这篇关于带有"native.hybrid"客户端的WinFormsSample不再起作用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
