Oleksii Nikiforov

I think env variables are a great way to control this one. We can still add them to Keycloak.Aspire package

Yes, I would like to do that. But, I think the auto-generated client is the way to go.

Closes via: #154

Hello, Here is an example of MVC project. ref: https://nikiforovall.github.io/keycloak-authorization-services-dotnet/examples/web-app-mvc.html Aspire provides some variables, but not all, you still need to complete the configuration by providing missing variables, like here...

@ekomsctr looks good to me. However, you may consider the following suggestions: 1. Read typed keycloak options instead of using "KeyCloak:ClientId": https://nikiforovall.github.io/keycloak-authorization-services-dotnet/qa/recipes.html#how-to-get-options-outside-of-iserviceprovider (you might not need it if you apply...

@adrianhall That is a great blog post, we need to add it somewhere to the docs 👍

One small additiona, there is token propagation middleware that you might want to re-use: https://github.com/NikiforovAll/keycloak-authorization-services-dotnet/blob/main/src/Keycloak.AuthServices.Authorization/AuthorizationServer/AccessTokenPropagationHandler.cs

> @adrianhall That is a great blog post, we need to add it somewhere to the docs 👍 Added to

There is nothing wrong with your approach, but alternatively, you can use - So, instead of using `Keycloak__ClientSecret` and `Keycloak_ClientId`, You can use `Keycloak__Credentials__Secret` and `Keycloak__Resource`. This is a convention...

It is a supported scenario: Please see: https://nikiforovall.github.io/keycloak-authorization-services-dotnet/configuration/configuration-authorization.html Also, to use ASP.NET Role Authorization, please enable Role claims transformation, see: But, claims mapping works differently for API and MVC scenarios,...