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

OIDC: Use Authorization Code Flow instead of implicit flow #21636

Closed codeindustriesnl closed 9 months ago

codeindustriesnl commented 1 year ago
Overview of the feature request

The current OIDC method of logging in uses the "implicit flow"-pattern to obtain the JWT access token. This is considered deprecated, see e.g. here and here.

The request is, when using the OIDC authentication/authorization method, to implement the Authorization Code Flow with PKCE.

Motivation for or Use Case

To remove vulnerabilities in the OIDC protocol usage.

Related issues or PR

Unknown / could not find.

mraible commented 1 year ago

@codeindustriesnl We do not use implicit flow. We use authorization code flow on the server with Spring Security. What makes you think we use the implicit flow?

gpcmol commented 1 year ago

This is the web_app client configuration in Keycloak: image

Here is the Keycloak client snippet for web_app. It says "implicitFlowEnabled": true and "publicClient": true although it has a secret in the configuration. But since it is a public client, the secret is not used. Do I overlook something? { "id": "6e8deddb-b4d6-4e2e-b389-b397d3f74fcd", "clientId": "web_app", "rootUrl": "http://localhost:8080", "adminUrl": "http://localhost:8080", "surrogateAuthRequired": false, "enabled": true, "alwaysDisplayInConsole": false, "clientAuthenticatorType": "client-secret", "secret": "web_app", "redirectUris": [ "dev.localhost.ionic:", "http://127.0.0.1:", "http://localhost:", "https://127.0.0.1:", "https://localhost:", "https://oauth.pstmn.io/v1/callback" ], "webOrigins": [""], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": true, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": true, "frontchannelLogout": false, "protocol": "openid-connect", "attributes": { "saml.assertion.signature": "false", "saml.force.post.binding": "false", "saml.multivalued.roles": "false", "saml.encrypt": "false", "post.logout.redirect.uris": "+", "saml.server.signature": "false", "saml.server.signature.keyinfo.ext": "false", "exclude.session.state.from.auth.response": "false", "saml_force_name_id_format": "false", "saml.client.signature": "false", "tls.client.certificate.bound.access.tokens": "false", "saml.authnstatement": "false", "display.on.consent.screen": "false", "saml.onetimeuse.condition": "false" }, "authenticationFlowBindingOverrides": {}, "fullScopeAllowed": true, "nodeReRegistrationTimeout": -1, "defaultClientScopes": ["web-origins", "jhipster", "roles", "profile", "email"], "optionalClientScopes": ["address", "phone", "offline_access", "microprofile-jwt"] }

mraible commented 1 year ago

You can turn implicit flow off in Keycloak and everything will still work. You're right that the default configuration should turn it off by default. Can you please create a PR with this change?

codeindustriesnl commented 1 year ago

We will. There are more realms with implicit flow so I need to test it first.

codeindustriesnl commented 1 year ago

I'm not sure how to build the current main branch... the "npm i" and then "npm run test" seems to fail on my end.

mraible commented 1 year ago

Are you using Node 18? If so, can you please share the errors you're seeing.

github-actions[bot] commented 9 months ago

This issue is stale because it has been open for too long without any activity. Due to the moving nature of jhipster generated application, bugs can become invalid. If this issue still applies please comment otherwise it will be closed in 7 days