You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was reviewing the example with Keycloak, and it was really helpful for the implementation I'm currently working on.
In the example, I noticed that the Blazor SSR application is using the application token (client credentials). While it makes sense that the API only allows authenticated applications to make requests, I think it would be better to use another flow, since user-based authentication is more common in many scenarios.
It would be beneficial for the API to know which user is making the request, what role they have, etc.
Although I have limited experience with Keycloak, I think simplifying the example would help users achieve the following:
Authenticate from the front end.
Have the API handle an authenticated user, including user identification and roles.
Handle token storage and refresh tokens, as access tokens have a short lifespan by default. To simplify the example, I believe using cookies to store tokens would be a good approach.
Regarding the Client Credentials flow, while it's useful, it might be better as a secondary example. For instance, you could show how a console application could call the API using this flow.
As mentioned, I don’t have much experience with Keycloak, but I’d be happy to help in any way I can.
Thanks again for the example—it has been very helpful.
Thanks for the suggestion. I specifically didn't want to have the API require tokens from end users as it has no need for it in this example. The eShop workshop does what you're suggesting, as the backend APIs actually deal with user-specific data. I could see this example be expanded to show both flows via different backend APIs, e.g. one that deals with user data and another that doesn't.
Ultimately there's no "one size fits all" solution when dealing with distributed app identity, authentication, and authorization concerns. This sample is really only intended to showcase how the Keycloak integration can be used with Aspire, but not to be an exhaustive reference for Keycloak itself, or ASP.NET Core authentication/authorization in general.
Should show how to configure the following app types to use a Keycloak instance to manage authentication (user, app -> api), and authorization:
The text was updated successfully, but these errors were encountered: