I'm trying to use keycloak with a react app, this is my current client configuration...I did this inside the master realm
this is my keycloak config
export const keycloakConfig = {
"realm": "master",
"auth-server-url": "http://localhost:8180/",
"ssl-required": "external",
"resource": "demo",
"public-client": true,
"confidential-port": 0,
"clientId" : "demo",
"url" : "http://localhost:8180/"
};
I based my code on this repo
now...I can login without problems in my app, and the displayed url is this
http://localhost:8180/realms/master/protocol/openid-connect/auth?client_id=demo&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2F&state=ba9daf04-ffdb-4ad3-b912-8be846f0684b&response_mode=fragment&response_type=code&scope=openid&nonce=558d71b7-2c66-44f8-9297-84694dc571a8
but when I try to logout I get a message
Invalid parameter: redirect_uri
the logout url is this
http://localhost:8180/realms/master/protocol/openid-connect/logout?redirect_uri=http%3A%2F%2Flocalhost%3A3000%2F
I'm not sure if my client config is correct because this has several missing parameters in almost all tutorials that I've found
Do you know what could be the problem here?
thank you guys
From the Release Notes:
OpenID Connect Logout
Previous versions of Keycloak had supported automatic logout of the
user and redirecting to the application by opening logout endpoint URL
such as
http(s)://example-host/auth/realms/my-realm-name/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri.
While that implementation was easy to use, it had potentially negative
impact on performance and security. The new version has better support
for logout based on the OpenID Connect RP-Initiated Logout
specification. The parameter redirect_uri is no longer supported;
also, in the new version, the user needs to confirm the logout. It is
possible to omit the confirmation and do automatic redirect to the
application when you include parameter post_logout_redirect_uri
together with the parameter id_token_hint with the ID Token used for
login.
The existing deployments are affected in the following ways:
If your application directly uses links to logout endpoint with the redirect_uri parameter, you may be required to change this as
described above. Consider either removing the redirect_uri parameter
entirely or replacing it with the id_token_hint and
post_logout_redirect_uri parameters.
If you use java adapters and your application does logout by call httpServletRequest.logout(), you are not affected because this call
uses the backchannel variant of the logout endpoint and that one was
not changed.
If you use the latest javascript adapter, you are also not affected. However if your application uses an older version of the
JavaScript adapter, you are affected as this adapter uses the variant
of the logout endpoint with the deprecated redirect_uri parameter. In
this case, you may need to upgrade to the latest version of the
JavaScript adapter.
For the Node.js adapter, the same guideline applies as for the JavaScript adapter. You are encouraged to update to the latest version
as the older version of the adapter uses the deprecated redirect_uri
parameter. With the latest Node.js adapter, you are not affected as
long as you use the logout based on the /logout URL as described in
the documentation or in the Node.js adapter example. However, in the
case when your application directly uses the method
keycloak.logoutUrl, you can consider adding idTokenHint as the second
argument to this method. The possibility to add idTokenHint as second
argument was newly added in this version. The idTokenHint needs to be
a valid ID Token that was obtained during the login. Adding
idTokenHint is optional, but if you omit it, your users will need to
confirm the logout screen as described earlier. Also they will not be
redirected back to the application after logout.
There is a backwards compatibility option, which allows your
application to still use the old format of the redirect_uri parameter.
You can enable this parameter when you start the server by entering
the following command:
bin/kc.[sh|bat]
--spi-login-protocol-openid-connect-legacy-logout-redirect-uri=true start
With this configuration, you can still use the format with the
redirect_uri parameter. Note the confirmation screen will be needed if
the id_token_hint is omitted. Warning The backwards compatibility
switch will be removed in some future version - probably Keycloak 21.
You are encouraged to update your clients as soon as possible as
described above rather than rely on this switch.
I've got the same problem already for hours. The only way I found a workaround is manually sending the user to:
/realms//protocol/openid-connect/logout
I started using Keycloak 18.0.0 since a few days and I cannot find any other solution for this problem. I guess it's only happening to when using the newest version. Maybe we should read the documentation better.
For last Keycloack versions you have to redirect explicitly to
https://you server url/auth/realms/matrix/protocol/openid-connect/logout
This issue comes when the keycloak is upgraded to version 18. So we also need to upgrade Keycloak JS & keycloak-angular package.
https://www.npmjs.com/package/keycloak-js
https://www.npmjs.com/package/keycloak-angular
Rest everything will be similar
Related
Keycloak inserts session_state, state and code in url fragment params.. sometimes after successful login these remain on the url...
Or, when alternate routes are clicked in the app, these appear again.
Unnecessarily exposing the internals of keycloak params to users.
Is there some solution to not have these appear or delete them?
e.g. http://localhost:3000/home/#state=e625140e-c4f9-4500-858e-32c80e89f8a9&session_state=445229c3-d7eb-46e9-bfba-3339253dd17e&code=af0abde4-a60d-4f34-a101-8db5c76546b9.445229c3-d7eb-46e9-bfba-3339253dd17e.59915134-a59b-4ffb-878a-d02e7e84f2dd
Update:
with more tests narrowed down the issue to occur when
anything on the keycloak instance is touched. e.g. keycloak.token
any function call of keycloak is invoked... then after that these params get added and removed for every url route thereafter...
e.g. await keycloak.updateToken()
Keycloak Sever and js lib Version : 9.0.2
It is not a Keycloak issue. That's how used login flow works (maybe you need different flow, which will be more suitable for your use case). Your app code (used OIDC/OAuth library) should "clean" URL fragments. Cleaning can be: exchange code for the token (in this particular case), remove URL fragments, clean browser history, etc.
Trying to retrofit an old webforms application.
Got my configuration working so that it's prompting for login and successfully redirecting back to the application. The folks that manage the IP can see the response is generated.
However in the callback to my application the User is null. I'm told if it's configured correctly it should be populated.
We have a custom IHttpModule and that is where I can see getting hit with the call to /Saml2/Acs with the User not populated. I think this may be expected as the handler for that is supposed to populate the User, I think? However the following call (the returnUrl configured in sustainsys.Saml2) still has no User and I don't see any sort of error or anything.
Anyone with experience have an idea how to debug this?
The call to /Saml2/Acs should be taken care of by the Sustainsys.Saml2.HttpModule. It will process the response and then call the SessionAuthenticationModule to set a cookie that preservers the User across calls.
To get some more information about what's happening in the library, you can assign an implementation of ILoggerAdapter to Sustainsys.Saml2.Configuration.Options.FromConfiguration.SPOPtions.Logger to get some logging output from the library.
My issue turned out to be that I had another authentication module loaded before SessionAuthenticationModule and Saml2AuthenticationModule in the web config.
The comment in the example was
Add these modules below any existing. The SessionAuthenticatioModule
must be loaded before the Saml2AuthenticationModule
However in my case with I had another authentication module involved that needed to go last.
hellojs twitter error
When i run the twitter demo from demo folder and clicked on twitter button it give me following error
url is undefind in hello.js file on this line if(url.indexOf(x)>-1){
how to fix this error
thanks
When running the demo page in question
http://adodson.com/hello.js/demos/twitter.html
You'll see...
hello.init({
'twitter' : TWITTER_CLIENT_ID
},
{
redirect_uri:'../redirect.html',
oauth_proxy: OAUTH_PROXY_URL
});
The setup includes an OAUTH_PROXY_URL variable. This tells HelloJS the location of the server-side shim in order for this to work with OAuth1 authorisation providers like Twitter (unlike OAuth2 providers which can share authentication tokens purely client-side)
If running this from a local domain like //localhost this will have been an undefined value.
You'll need to do two things to get the demo working.
Define the oauth_proxy option in the demo code. See http://auth-server.herokuapps.com for setting one up. OR remove it entirely and by default it will use the above service - you'll need to register third party apps there (recommended).
Change your development environment in your host file to something other than //localhost, that way you can register OAuth2 providers which are domain sensitive and often wont let you use localhost when registering your apps callback URI. If you change your development environment to be local.knarly.com with hello.js project as a subfolder - then you can skip step 1 as the oauth_proxy will be defined correctly.
I have the following Auth object in my app:
App.Auth = Ember.Auth.create
signInEndPoint: '/users/sign_in'
signOutEndPoint: '/users/sign_out'
tokenKey: 'auth_token'
tokenIdKey: 'user_id'
userModel: 'App.User'
modules: ['emberModel', 'rememberable', 'actionRedirectable']
actionRedirectable:
signInRoute: 'home'
signOutRoute: 'login'
rememberable:
tokenKey: 'remember_token'
period: 7
autoRecall: true
Everything with authentication is working great. The problem I'm seeing now, though, is that when a user attempts to access, say, 'mydomain.com/#/articles/12' and has a valid remember token, accessing the application is tantamoun to starting a new boot of the application. The user is signed in via remember token, and actionRedirectable takes over and takes the user to HomeRoute instead of going to the requested resource.
I feel like I could get around this by manually transitioning the routes in the relvant login/logout controllers, but I wonder if there's a baked in way of solving this in EmberAuth?
ember-auth dev here.
This looks like a known issue. Try the fix in this comment from github issue #69.
In short, module order does matter. actionRedirectable needs to register the route (probably the article route in your case), before rememberable signs in the user and requests a redirect. Otherwise it would have nowhere to redirect to, and falls back to your home route as specified.
There have already been requests of fixing this unexpected behavior, but I haven't been able to find a fix yet - sorry.
I'm using OpenAM for authentication on my application. I access to my app using such URL:
http://my.company.com/appfolder/appservlet?lang=EN&user=test
On first access, OpenAM agent catches the URL and redirect my browser to the authentication page using this redirection URL:
...openam/UI/Login?goto=http%3A%2F%2Fmy.company.com%3A8080%2Fappfolder
After correct authentication, I'm finally redirected to the following URL:
http://my.company.com/appfolder
This is logic since this is the URL referenced in goto param. But it's not the same than original one: the servlet and custom params (lang and user) are missing.
Any idea how to configure my agent to make it keep servlet and params after redirection ?
take a look at this step of the tutorial "Add Authentication to a Website using OpenAM".
In section "Creating An Access Policy" -> "Wildcard matching" is your answer:
The wildcard * in policy URLs does not match '?'. As such if you
wish to allow GET parameters to be submitted then a second policy for
http://webserver.example.com/*?* is required.
Thanks for your answer. As mentionned in my previous comment, the adding of new policy does not resolve my issue. Actually, I'm not sure to understand how the policies can solve the issue since the goto parameter is generated by the J2EE agent, which acts before policies are applied (as far as I know... I'm maybe wrong).
Anyway, I could solve my problem by re-compiling the J2EE Agent: I've build a new agent.jar based on v3.0.3 available at forgerock. Then I replaced the AmFilterRequestContext.class by a new one, build on source available here:
http://www.docjar.com/html/api/com/sun/identity/agents/filter/AmFilterRequestContext.java.html
With this new agent, my goto is now correct, and redirection works well (and I don't have to define any policy).
The strange thing is that I don't understand why it works now ! I couldn't find any difference between java source mentionned above and uncompiled version of original class! I just added some System.out.println to get variables values and functions results, and built the jar. After restaring my jboss, the goto was correct. I'll try to understand why this finally work now when I've time.