Comments on: Microservices with Spring Cloud Gateway, OAuth2 and Keycloak

By: Kris

Kris — Sun, 04 Aug 2024 22:57:32 +0000

Great blog.
I was getting error with tests (quickstart is similar to demo)
2024-08-04T23:24:04.309+01:00 INFO 17036 — [gateway-app] [ream-1518476187] tc.quay.io/keycloak/keycloak:24.0 : STDOUT: 2024-08-04 22:24:04,308 WARN [org.keycloak.events] (executor-thread-1) type=”LOGIN_ERROR”, realmId=”384d6b71-7c16-450c-9961-7cc02023d851″, clientId=”resource-server”, userId=”null”, ipAddress=”172.17.0.1″, error=”user_not_found”, auth_method=”openid-connect”, grant_type=”password”, client_auth_method=”client-secret”, username=”alice”

Added Users to the export as mentioned in the article. Wish keycloak updates their export to include users also.
Thank you

By: piotr.minkowski

piotr.minkowski — Thu, 13 Jun 2024 08:00:03 +0000

In reply to Maksym. Hi, Everything works here as expected. But, maybe you have different assumptions. Such logic is automatically priovided by Spring Security.

By: Maksym

Maksym — Sun, 19 May 2024 11:25:29 +0000

Hi!
This code does not work.
Basically, there is no logic for exchanging an authorization code after the user loggged in throw Keacloak page.

By: piotr.minkowski

piotr.minkowski — Fri, 05 Apr 2024 11:36:36 +0000

In reply to Sławek. Hi, Thanks. Yes, pleease prepare a PR

By: Sławek

Sławek — Thu, 04 Apr 2024 11:35:03 +0000

Hi,

Great article. There are some fixes required in the code though.
@PreAuthorize(“hasAuthority…
will is not actually executed. @EnableMethodSecurity annotation has to be added for it to work.
I forked your repo and may prepare a PR if you wish to include fixes and tests.

Regards

By: Simon

Simon — Fri, 08 Mar 2024 09:45:07 +0000

In reply to piotr.minkowski.

Yeah, I’m aware of the options… more just wondering what best-practices are in that space. Custom “environment-unique” scopes are how we’re currently doing it, and it works, but no idea if I’m re-inventing wheels by doing so.

For perspective, I’m an architect working on an ageing monolith, and articles like this one are very helpful in understanding what a modern target architecture can look like. I understand that it’s a simplified example — but it’s one with enough complexity and moving parts to be meaningful, so thanks for that.

By: piotr.minkowski

piotr.minkowski — Thu, 07 Mar 2024 12:36:18 +0000

In reply to Simon. Well, you can have more scopes, also use roles, define multiple realms etc. Here, it is not important who generated the token, but what privileges it has. Of course, you can provide a logic e.g. on the app side to analyze more things in the JWT then just a scope

By: Simon

Simon — Wed, 06 Mar 2024 06:44:41 +0000

A question that’s a little peripheral to this… what’s the recommended practice around verifying that when you’re a resource server receiving a token, you’re actually an intended recipient for that token?

For example, “callme”, “caller” and “gateway” all require a token… “callme” and “caller” also require that the token carry the TEST scope. But nothing in this picture seems to ensure that the token wasn’t created for some other application which happens to share the same auth server, and should not grant _any_ privileges within this set of services…

By: piotr.minkowski

piotr.minkowski — Sun, 03 Mar 2024 22:07:37 +0000

In reply to Vinit Patel. Thanks for suggestion. I'll think about it.

By: piotr.minkowski

piotr.minkowski — Sun, 03 Mar 2024 22:02:20 +0000

In reply to enthusiast. You're welcome