We have a Keycloak 18.0.2 with realms integrated to external IdP (Okta / Ping / Azure). In one realm we started seeing lots of IDENTITY_PROVIDER_LOGIN_ERROR / cookie_not_found in login events. And had users reporting that they were only able to login if they cleared their browser’s cache and cookies.
We found some ways to reproduce this behaviour in dev environment:
Multiple browser tabs:
At the browser, tab 1, user opens application menu-navigator and is redirected to the External SSO login page (after Keycloak auth flow redirection). We see this login page being initialized with cookie KC_RESTART (auth endpoint).
At the same browser, tab 2, user opens application dashboard-frontend and follows a similar flow as previous app.
Both websites are written in Vue.JS and are using oidc-client-ts library. When initialized, OIDC lib loads the realm metadata, creates a user storage, and executes signin flow. After user is authenticated and has an active session KC_RESTART cookie is expired.
As a result, when user back to tab 1 which is opened at step and try to login, user encounters an error since system cannot find authentication session and then try to use KC_RESTART cookie to reset authentication session however the cookie is even not there since it is expired at step c.
Then user is redirected to Keycloak and sees the Cookie not found message.
Stale sessions:
User opens the application (menu-nav or dashboard), sign in, do some operations, and close the tab.
Users opens the application again in a moment between Session Idle and Session Max timeouts.
User is redirected to Keycloak and sees the Cookie not found message.
We’ve seen the message in other situations, but we couldn’t consistently reproduce.
While we were debugging this problem, we saw a Keycloak redirection to applications call-back endpoint with erro=login_required. So, we decided to handle this and other possible errors trying to make the client app do a silent signin or do a signin redirect if signin silent fails.
This seems to be effective to that error and now we see some IDENTITY_PROVIDER_LOGIN_ERROR / expired_code which we believe it’s OK and associated with the session max timeout and makes user go to the SSO login screen.
Any thoughts about this?
Related
I have developed an SAML application which only uses Microsoft as IDP for successful login and logout of specific users. So after logout, I want Microsoft to redirect me to the website I have configured in the Logout URL of MyApplication in Azure Active Directory. The log-in functionality works everytime but when I logout in presence of only one Microsoft Signed-In account, it logouts perfectly and redirects me to the website I specified. I am facing the issue when I am asked to choose account to logout from a set of accounts (refer Image) of which when I select the configured account, it log me out perfectly but is unable to redirect me to my specified page. The page gets stuck on "You signed out of your account It's a good idea to close all browser windows." (refer Image). Thus I want to be redirected to the specified page when I am asked to select an account while logging out.
Logout Issue Redirect Image reference
Logout Issue Redirect Image reference
This is a known bug in this library.
Here are some alternatives.
You can use silent logout.
The post logout redirect isn't expected after calling logout. This could be a timing issue.
You can achieve a 'clean' logout by opening a new window and calling logout from there. Then a user is left with an extra open window; but at least they've retained a view of the app and it hasn't lost state.
I'm researching on SSO but there is one thing I coudn't understand is how SSO consumer can get session without clicking on Login Button. I can explain the case as below:
I have:
accounts.domain.com (Identity Server. Already Allow consumer 1 & 2)
myapp.com (Consumer 1)
yourapp.com (Consumer 2)
When I go to myapp.com -> I have no permisson or no session to access the server resources.
I click on Sign In button in myapp.com, this will redirect to accounts.domain.com and after authenticated, I get back to myapp.com with my local session.
The question is: When I go to yourapp.com, I already have session without click on Sign In button.
The real case is google.com, accounts.google.com, youtube.com, ...
I don't know how it works and how to implement this?
And one more question, Can I use Auth0 or Google Cloud Identity or AWS Cognito to build my Identity Provider like google did?
Can someone support me in this?
To better understand the concept u should 1st know what happens when u use SSO login.
I will take google and YouTube as examples.
When u login to google using your credentials u will not only get a local session but a single sign on token. We generally have this as SAML which is security assertion markup language token.
This SAML token will be stored in your client or browser in this case.
Now when u try to load youtube in the same browser this token will be sent to the IDP along with the request. Since the IDP knows that this user is already authenticated it will check for authorization for the particular website in this case YouTube, the page loads.
I'm seeing a very strange issue with OAuth2 based social logins on my website. A small percentage of social login users are being redirected TWICE to the redirect URI used during the OAuth2 flow:
NOTE: This is not logging error, I'm seeing plenty of OAuth redirects which are hitting my servers just once.
This is also happening across a range of OAuth providers including Facebook and Google.
When I'm able to reproduce this in Chrome, I see the first request to the redirect_uri is cancelled in browser and the second request goes through successfully. This creates a small window for a race condition where the first request changes the session key on the server after successful login (to avoid session fixation vulnerabilities), so that when the second request hits the server with the old session key, it is missing state information in the session and the OAuth flow fails.
I have absolutely no clue what could be causing this as it's happening after the users are redirected to the 3rd party OAuth providers. Have you seen something similar on your production environments?
I have four custom apps (that are SPs), using Auth0 or OneLogin as my IdP. In Auth0 I create a connector for each application. When I login to one application and then open the other application, I get redirected to Auth0 to login again.
Is it possible to log the user into my IdP (or Auth0/OneLogin) automatically on that second app without having to click the login button on Auth0, since they've already authenticated with Auth0?
There is an unfortunate need to embed the second app into the first app and it's a poor UX to have the user login to the first app and then login again in the iFrame.
Auth0 Dev here, Yes this is supported Out of the box in Auth0, for this to work you'd have to turn Use Auth0 as IdP "ON" in your Client. When doing this Auth0 will then remember the client for 10 hours upto 3 days if the client is active.
The flow in your scenario will be
User logs in to any of the application.
User visits the other application.
The other application sees no session.
The other application redirects to /authorize endpoint.
Auth0 notices the session and redirects it back to your application immediately.
This is further detailed and explained at https://auth0.com/docs/sso
SSO is not having to re-enter credentials again but you only get SSO once you redirect to the IDP and you authenticate under the hood i.e. seamlessly.
So you still have to do something to trigger the redirect.
You could programmatically redirect to a dummy page that requires authentication that then redirects via your client stack e.g. OWIN OIDC.
Also, there is no standard for the cookies so you don't get SSO across multiple IDP unless they are federated together.
So if no federation and you login to Auth0, you will still have to login to OneLogin.
I have this GWT application which login/logout to a server.
The server side is ok as it can login/logout a connection.
However I need that when the application login in with a browser, the application will stay logged in for each new instance of the application.
Use cookies on the browser to store login details. When a new tab is opened, and requests the page from the server, the cookies will be passed along automatically and you can log the user in from there.
Make sure you understand the security implications of storing login details in cookies before deploying this strategy!
You could store the information if a user has been successfully authenticated in the http session on the server side and provide a service like
public boolean isAuthenticated();
which checks that property.
Before showing any sensitive information in the client, call that service to make sure, the current user is authenticated. I would recommend not to store login credentials in a cookie.