Repository navigation
Unable to get tokens for subsequent OAuth Clients when doing first auth through KeyCloak API #35720
Replies: 2 comments 2 replies
|
SSOs work by separating the authentication from the application itself - this is done by having separate sessions for the SSO and the clients. When the user is already authenticated on the SSO, they are no longer required to log in since the SSO can continue using its own session (identified using the cookies stored in the user's browser), even if the clients don't have valid (application) sessions. I assume the REST API circumvents part of the OIDC flows which allows the SSO to create the appropriate cookies in the browser, so the SSO does not have a cookie stored in the browser (or even if it does, the direct grants flow you have described does not use them). |
|
Thanks, @darius-m ... that sounds about right. Can we modify the flow used by the KeyCloak API to enable what's needed... or manually push the auth result from the KeyCloak API to the browsers on the local machine or store what's needed in KeyCloak itself? |
|
I think you would likely be able to save cookies or other information by emulating a browser (e.g., in Python) or using a headless browser, but I'd say using something like Device Authorization Grant instead of Direct Access Grant (which is much less secure, since users hand their password to the client application) would be easier and likely better. After you are able to fetch a token for the user, you can use that to authenticate to other applications (sites that use There are some examples on the internet for using Device Authorization Grant for SSH (e.g., on the Okta blog: https://developer.okta.com/blog/2021/08/20/cli-ssh-oauth-device-grant, but there are other implementations using other programming languages). |
|
Thanks @darius-m. Your suggestion was the key to finding a workable path for this. It took quite a lot of R&D but we worked out a process using a service account with token exchange and an aud claim for all clients that explicitly includes all clients to securely provision tokens that work everywhere regardless of whether they’re given via OAuth flow or the KeyCloak API. |
Uh oh!
There was an error while loading. Please reload this page.
We've been pulling out hair out for weeks trying to figure out a way to get Direct Access Grants through Keycloak to then allow public OAuth Clients to automatically get a token without requiring authentication with username/password a second time. This presents as someone signing in first to our main app (web, Mac, Windows) and then being asked a second time for the same username/password when an OAuth client like oCIS Web or Mountain Duck tries to authenticate. We're desperate to find a way to have someone only sign in once since that's the whole point of us using Keycloak in the first place.
We're using the Keycloak API (via the realms//protocol/openid-connect/token endpoint) to directly exchange username/password for a token, bypassing standard OAuth authorization flows. Documentation says "If your apps are directly obtaining tokens via the Keycloak API without redirecting the user through the Authorization Server, other Clients might not be able to share those tokens." but we've been unable to find a way to ensure tokens care be shared. Could this be an issue with lack of PKCE (Proof Key for Code Exchange)?
Hoping someone in the community has come across this before and can suggest a solution!
All reactions