Search code examples
identityserver4identitymodel

WinFormsSample with 'native.hybrid' Client does no longer work?

If I change the client in this sample to 'native.hybrid' https://github.com/IdentityModel/IdentityModel.OidcClient.Samples/tree/master/WinFormsWebView

and set Flow = OidcClientOptions.AuthenticationFlow.Hybrid

then the login to IS4 works (after a 5s delay), but a new login form appears in my default web browser.

With the client 'interactive.public' works fine. My question is which 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?

Solution

  • The current rule of thumb for choosing the grant to use with OIDC is:

    • Machine to Machine communication: use ClientCredentials.

    • Interactive client (web applications, SPAs or native/mobile apps): use code + PKCE

    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.

    Code+PKCE: This flow consists on two requests:

    1. 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).

    2. A request to the token endpoint providing the received code that will respond with the actual token requested.

    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).

    Here is when PKCE comes in handy: It enhances the security of this flow by adding an extra check:

    1. 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.

    2. 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.