Currently running version 12.3.0 and have a need to support client credentials flow. Is this currently supported?
5 Answer(s)
-
0
Hi,
Yes, you can use it. You need to configure your clients in appsettings.json as shown below;
-
0
Hey Ismail,
Thanks for following up. I had found this section of the config and had already attempted to enable it and login with that client. Unfortunately, I wasn't able to get it to work so I logged this support request.
When I turn on the IsEnabled flag for OpenIddict in that config section, it does create the client in the OpenIddictApplications table and that client does have the listed gt:client_credentials permission in the database. I had also created a second client (client2) to test custom scopes with which you also see in the screenshot:
Here is what I did to test. I set up an ASP.NET Core MVC web app to simulate that client. I configured that MVC application based on the client from the Aridka sample app from OpenIddict samples collection listed here:
https://github.com/openiddict/openiddict-samples/blob/dev/samples/Aridka/Aridka.Client/Program.cs
I had to slightly modify the sample code as the MVC template isn't quite the same as their console app sample (eg...building of the service provider had to change). Here is what my client application code looks like:
When I try to run the client code, the GetTokenAsync request fails. The failure happens because the TokenController that is part of %MyAspNetZeroProjectName%.Web.Core has the following code which appears to only support Resource Owner Password and Authorization Code flows (the commented out client credentials code is mine and is described below). The AspNetZero template code out of the box throws the "grant type client_credentials is not implemented" exception which then returns to the GetToken call with a HTTP 500 error:
When it appeared that the flow wasn't actually supported, I created the support request and while I waited I decided to see if I could add support for the client credentials flow based on the server side example from the Aridka sample. I had to slightly adapt that sample to the AspNetZero template but nothing major was changed from the Aridka server side sample (changes: hardcoded claim names and broke up the scopes logic for troubleshooting). Here is my implementation:
This is where I also added support to the HandleAsync method in TokenController as such:
Now when I run the client MVC app, it runs my custom handler for the client credentials flow and signs the client in:
The GetToken call now succeeds and returns an access token. It seems like all is well now.
Unfortunately, the token that gets generated can't be validated. The reason is because the AddDevelopmentSigningCertificate method that gets called from OpenIddictRegistrar::Register will generate a RS256 signing certificate which is asymmetric but the TokenValidationParameters class that is configured in AuthConfigurer::Configure uses an IssuerSigningKey that is symmetric:
This mismatch in the signing key generates the following validation error: "{"IDX10503: Signature validation failed. Token does not have a kid. Keys tried: 'PII of type 'System.Text.StringBuilder' is hidden. For more details, see [https://aka.ms/IdentityModel/PII.]'. Number of keys in TokenValidationParameters: '1'. \nNumber of keys in Configuration: '0'. \nExceptions caught:\n '[PII of type 'System.Text.StringBuilder' is hidden."
If the client credentials flow is supported out of the box, I must be doing something wrong in my implementation on the client side. Any help would be appreciated.
-
0
Hi,
Could you revert your changes and see if the test project under test folder named
YourProjetcName.ConsoleApiClient/Program.csworks ? It uses client credentials to get a token and retrieve user list using this token. -
0
I can run that app as is and it runs fine and generates an access token, but the problem is that it is not the right flow. In this screenshot, you can see that flow passes the OidcConstants.GrantTypes.Password type, not client credentials. I haven't touched this app.
-
0
Hi @ZeroAviationLenexa
Sorry, you were right. It seems like
client_credentialsflow is not supported at the moment. You can create an issue on GitHub to request this feature. For now, you can create a user for each client and use Password flow.
