search

jhipster / generator-jhipster

JHipster is a development platform to quickly generate, develop, & deploy modern web applications & microservice architectures.
https://www.jhipster.tech
Apache License 2.0
21.54k stars 4.02k forks source link

Is direct access to keycloak server safe for oauth2 authentication #19306

Closed paris0120 closed 2 years ago

paris0120 commented 2 years ago
Overview of the issue

I am not very familiar with how keycloak works under the hood but I'm not very conformable with exposing the whole keycloak server to the public. Currently, I modified it in this way. The front-end send username password to the gateway and the gateway pass them to the keyclock server and store the token and add the token to every api call to microservices. I am wondering if this is a safer way to keep a private oauth2 server?

Beside, I also added eureka client to keycloak server so that the frontend can use the gateway pass through. There is my server: https://github.com/paris0120/keycloak-server

Motivation for or Use Case

Hide the keycloak from the public.

Reproduce the error
Related issues
Suggest a Fix

The front-end send username password to the gateway and the gateway pass them to the keyclock server and store the token and add the token to every api call to microservices. I am wondering if this is a safer way to keep a private oauth2 server?

Beside, I also added eureka client to keycloak server so that the frontend can use the gateway pass through. There is my server: https://github.com/paris0120/keycloak-server

JHipster Version(s)
JHipster configuration
Entity configuration(s) entityName.json files generated in the .jhipster directory
Browsers and Operating System
atomfrede commented 2 years ago

To be honest I am not sure, but I would consider keycloak to be safe to be exposed. Its build for that purpose.

paris0120 commented 2 years ago

To be honest I am not sure, but I would consider keycloak to be safe to be exposed. Its build for that purpose.

It's built for safety, yes, but only when you config it right and if it will never have a security bug. Right now the users not only can access the realm of the choice but can also access the other realm and the admin panel (/auth). Besides, the one provided by jhipster is with http. If we make it as a microservice behind the gateway, many things can be done at the gateway such as rate limit, ssl, access control, integrated user login/logout UI, app access with session id instead of token, etc.

atomfrede commented 2 years ago

Yes hardening keycloak for production and correct configuration is needed. If that means hide it from the public thats the way to go, but I guess it depends on your use case and environment

vishal423 commented 2 years ago

It seems you want to follow the Resource Owner Password Flow, and that's not recommended. Refer https://www.scottbrady91.com/oauth/why-the-resource-owner-password-credentials-grant-type-is-not-authentication-nor-suitable-for-modern-applications for possible issues that can come out.

If you have suggestions to improve the current OIDC integration with Keycloak, feel free to contribute.