受信任桌面客户端的客户端凭据流或授权代码流（使用 PCKE）

Question

I'm developing the authentication/authorization architecture for several APIs.

I'm using IdentityServer4 as a Security Token Service (STS).

From what I've read from "Dominick Baier" (one of the persons that built IdentitySever4), there are only two types of Flows that should be used :

• Client Credentials Flow. (machine-to-machine)
• Authorization Code Flow + PCKE. (for iteractive users).

I have several C# Web API's that will communicate with each (Machine-To-Machine), and I will use the Client Credentials Flow.

But then there are some WPF Desktop Applications, that will need to access some APIs, and don't have a user. Which flow should be used?

I've read that: Desktop/Native & Mobile Applications should use Authorization with Authorization Code Flow (with Public Client and PKCE), since they are hosted on the Client side, and the Client/Secret is can be leaked (maybe on a Desktop application we can Encrypt the Secret? But then will need to manage a way how to store the secret that decrypts that right?)

Then I've read: "Anytime you have a system that isn't concerned with the end-user identity (and just needs to authenticate the system), use the OAuth2 Client Credential Grant."

For now, this is my case, I'm not concerned with the end-user identity (but maybe in a near future I will).

So since the above points conflict with each other: - Which flow should I use? - Can I have a Desktop Client using Clients Credential Flow and be safe?

Also, I've read a bit about Mutual TLS, If I use that, does this change which flow should I use?

Answer 1

You can't trust a client because you can't be sure a request originates from the client. And another problem is that clients are not good in keeping secrets. But there are different types of clients.

Clients that run on servers often having a single task, like synchronizing data which is user independent, are suitable to use the client credentials flow. To some degree they can keep a secret (running on a server).

You can use unique credentials for each instance but that doesn't make it safer. It helps you to identify the client, but doesn't add security. Security is about monitoring behaviour and detecting anomalies. Or perhaps narrowing access by filtering on ip address.

But you are not limited to use the two flows you've mentioned. Being a token provider, you can extend IdentityServer with custom flows using extension grants .

Without user the client credentials are somewhat similar to the resource owner password credentials (ROPC) flow (another option that is no longer covered in the grant type documentation but still exists, see the old docs ). Neither are really safe in the sense that both can be automated. The user factor can be eliminated since user interaction isn't required for these flows.

But I wonder why your app has no user, running on a user machine. Because ideally you have a client (without secret) where the user logs in and let the client contact the api ( delegation ).

So there are two things: do you need to identify the client? If not you could suffice with an ApiKey, like eg Sendgrid. And you can never trust a client. Security has to be server side.

So basically it doesn't really matter, there is nothing you can do to make it much safer client side. The only thing you can do is add the requirement of user interaction. So perhaps now you don't need it, but it will increase security and allows you to delegate api access to the client.

Answer 2

To add to Ruard's very good answer and point you to some links:

For your WPF desktop applications the standard technique is to open the system browser for logins and then receive the response in your app. This is a little tricky but the below IdentityModel code samples show how:

• Loopback Web Server Example
• Private URI Schemes Example

RESOURCES OF MINE

The user experience is a little tricky though, so to understand the behaviour you may want to have a look at my visual blog posts.

• Loopback Code Sample + Blog Posts
• Private URI Scheme Code Sample + Blog Posts

The blog posts are accompanied by a couple of code samples you can easily run from your local PC.