I'm building a central authentication service(auth.xyz.com), similar to what Google has on accounts.google.com. I have multiple applications, each running on a different subdomain(app1.xyz.com, app2.xyz.com) which will be integrating with my auth service.
I am currently following a cookie based system, written on ".xyz.com" domain, so that it is readable by all the subdomains.
My problem is that I cant figure how to handle the cookie expiry. If the user logs in at time t, and spends 45 mins on app1.xyz.com, and then goes to app2.xyz.com, I dont want him to have to login again. Also, if the user logs in on app1.xyz.com and is then idle for 45 mins, and then hits app2.xyz.com, I want him to have to relogin. How can I achieve this?
I dont want to touch the auth server on every request I get on app1 or app2.
I do not think that is really possible.If that is the case, there will be a security hole in the entire flows of the applications.An cookie expired user can still access the resources on server app1 and app2 without authentication or some other trusted mechanism!.
Related
We are currently implementing keycloak and we are facing an issue that we are not sure what’s the best way to solve it.
We have different webapps making use of the sso and that’s working fine. The problem we have is when we make log in using the sso in one webapp and then we do the same in a different webapp.
Initially this second webapp does not know which user is coming (and it’s not necessary to be logged in to make use of it). When clicking on “login”, it automatically logs in the user (by making a redirection to keycloak and automatically logging the already logged user in the other webapp). This second logging happens “transparently” to the user, since the redirection to keycloak is very fast and it’s not noticeable. This behaviour is not very user friendly.
The question is: Taking into account that this second webapp can’t know upfront which user is accessing the site (unless actively redirecting to keycloak), is it possible to force always the users to log in for a specific keycloak client? By this I mean actually ask the visitor for user/pw even if keycloak knows already them from other keycloak clients.
Thanks in advance!
In the mail listing from keycloak, they gave me a good solution but for version 4:
in admin console, go to Authentication
make a copy of Browser flow
in this new flow, disable or delete Cookie
go to Clients -> (your client) -> Authentication Flow Overrides, change Browser Flow to your new flow, click Save."
Use logout endpoint as a default login button action in your app and redirect uri param use for login page, where you use your specific client (of course you need proper URI encoding):
https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/logout?redirect_uri=https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/auth?client_id=client_id&redirect_uri=.....&other_params....
=> user will be logged out and then it will be redirected to the login page
Question
I am pretty sure my question is not directly related to IdentityServer’s features, but I hope you, guys, can give me an advice to help with next issue. In our environment, we have several web applications running on different domains/machines, which are using IdentityServer as an authentication authority. Everything is working just fine in terms of authentication and authorization and with SSO users can get access to all apps.
This is a problem:
User navigates for the first time on, let’s say, WebApp1 (http://domain1/WebApp1) which requires authentication – user automatically redirected to IdSrv login. Users enters credentials and then redirects back to WebApp1. Everything is working fine, base “.AspNet.Cookies” –cookie is created and user can navigate within WebApp1 resources without concerns. After wile users navigates to WebApp2 on the same domain (http://domain1/WebApp2). During navigation app makes roundtrip to IdSrv making sure that user is authenticated and returns to WebApp2 (no new login required) – this is ok. But then, if user wants to go back to WebApp1, the new roundtrip to IdSrv is occurred and that is what I want to avoid! And this happends each time user switches between apps.
Is there any way to prevent those IdSrv roundtrips on every navigation between multiple WebApplication on same/different domains? One workaround I found is to use different names for ASP.NET cookies for each applications, but this makes identity sign-out way more complicated.
Also got advice from #brockallen to use diffent cookie name for each separate webapp, but what about single sign out? Once logging out on WebApp1, WebApp2 still remains logged in until new roundtrip to IdScrv will ooccur or cookie exp
We have a project that uses IdentityServer4
https://github.com/IdentityServer/IdentityServer4
We have 3 domains: auth, admin and www
IdentityServer runs on auth and the other two are ‘clients’.
www uses the Hybrid flow (cookies)
admin uses the Implicit flow (it is a SPA, using oidc-client)
We have a single login page hosted on auth. When the user logs in they are taken to www. Some users are allowed to access admin and they will see a link in the navigation.
After you login, when you access the admin you can see the authentication happen automatically and return to the callback URL. This all works fine.
However if I logout from the admin I can still access the www, and vice versa. Ideally we would like the logout to log the user out of both clients at once.
Is this possible?
Note: I'm the front end developer on this project, so the guy who actually implemented it may provide additional details in comments below.
Yes this is possible.
The docs for idsrv4 are not done yet - but it works pretty much like this
https://identityserver.github.io/Documentation/docsv2/advanced/signout.html
This is an implementation of the signout spec for JS
https://openid.net/specs/openid-connect-session-1_0.html
..and for web apps
https://openid.net/specs/openid-connect-frontchannel-1_0.html
you need to read those documents to understand the mechanisms
I can not seem to find a SIMPLE answer to the question on how to persist OAuth2 authentication... Let's take Google+ OAuth2 API as an example.
User goes to page
User is not authenticated, and gets redirected to authentication page where he logs in
User logs in successfully and authorises my app
User gets redirect to specified (by me) URI with Authorisation Code
I use authorisation code to obtain a token in order to submit queries in the name of the user
All is good and well. My question is: how do you SECURELY know at step 2 that the user visiting the page is already logged in, without having to go through the whole process of redirecting him to all these pages.
I assume storing the Authorisation Code retrieved at step 4 in a cookie is not an option.
All of this will happen in a server-side (Go - if that matters) application.
Any help is much appreciated... I need a simple solution.
Thank you!
use server-side sessions to store any authentication state or even access tokens if you need them.
one solution is to use a database for session store (an encrypted cookie holds the session id)
and another is to use cookie sessions (encrypted cookies that hold the session data).
using encrypted cookies that only the server is able to decrypt should be safe enough.
I've searched all of google and stackoverflow for this, but with no success. I'm starting to feel the simple answer to this question is "no", but I haven't been able to confirm this either.
Is there a way to limit apache to 1 session per authenticated user?
Say I'm logged in as admin1 (using .htaccess and .htpasswd). Is there a way to stop another user from also logging in as admin1 as long as I am connected?
Basic authentication by itself has no concept of a user session, and the HTTP protocol is stateless without such a concept. As such, there is no concept of "connected". You might however be able to use mod_auth_form - http://httpd.apache.org/docs/current/mod/mod_auth_form.html - to provide a session-backed basic authentication. I don't know that there is any provision for limiting a single session per login though. Chances are you need to do this in the application layer.