I am using GAE User Service to Authrnicate my GWT Application.
Depending on whether the User is logged in the User is presented with LoginPage/Dashboard.
The GWT Application calls a Auth Servlet (Window.Location.assign("/googleauth"); causing application to unload which then transfers control to Google Authentication Page, after authentication we are redirected to CallBack servlet.
I can check whether user is loggedin successfully in Callback Servlet. However if I simply redirect back to my application the session login is lost.
The Application loads from scratch.
If I set up a cookie-->
HttpSession session =
request.getSession();
String sessionid = session.getId(); //Get sessionID from
server's response to your login
request
Cookie cookie=new Cookie("sid",sessionid);
response.addCookie(cookie);
response.sendRedirect(AppURL.getApplicationBaseURL());
In my client code check -->
String sessionID =
Cookies.getCookie("sid");
if(sessionID!=null) { //show
dashboard }
Is the way I am using secure? How long are the cookies valid for?
You said:
I simply redirect back to my application the session login is lost.
This should not happen. Once you login the session should be there until you logout or session timeouts (you can set this in GAE settings).
You can simply make a GWT-RPC call to server and check if user is logged in: UserServiceFactory.getUserService().isUserLoggedIn().
Note: if you are looking for session cookies, AppEngine uses different cookie names in production and development servers. It uses ACSID cookie in production and dev_appserver_login.
Related
in my react-django app,my scenario is each user has multiple accounts and when user login there will be a session check call and if no data in session then we have to select particular account and store it in session thus django and react passes session cookie in every request.suppose if cookies are blocked in user browser then what to do? how to handle session data then?
My Auth Server uses IdentityServer4.
Redirect configured as follows for a client
RedirectUris = new List<string>
{
"https://localhost:44342/signin-oidc"
}
this works fine for those users for whom MFA is not enabled. But when it is enabled, and kicks in, the redirect doesn't work. After successful 2nd FA, user stays back on the AuthServer page.
Any idea why?
Multifactor authentication is not implemented by Identityserver4. Identityserver4 is about how the third party application gets access to protected resources on behalf of the user.
The means of how the user gets authenticated are out of the identityserver4 scope. In other words, this is not related to identityserver4.
If you're using the identityserver4 quickstart it comes with ASPNET Identity, ASPNET Identity provides you with a local authentication system for ASPNET applications. MultiFactor Authentication is probably there.
Being said that, when you try to POST to the /authorize endpoint (note authorize not authenticate) from your client application IdentityServer tries to authorize your request and to do so it makes you authenticate first, by presenting you the Login Form.
If you look at the Address bar on this point, you'll notice there's an encoded url as returnUrl param, on the controller code you'll see a check that if that param is present, redirect to that url after successful login.
So, check the flow on your application and see where does that parameter get lost on the redirect hell, at some point you're not passing the returnUrl.
To introduce my current setup, I have 3 components:
Website with some static (CMS) and dynamic parts, a couple of Single Page Applications, everything works on domain spa.com.
REST API, which provides any dynamic functionality (user profile) and is hosted on api.com and requires SSO tokens to work.
SSO server is hosted under sso.com domain
I'd like to determine in my SPA whether user has an active SSO session, so when I'm logged in but I do not have tokens, I can:
do a redirection dance to get tokens
do not allow user to use registration form
I'm using Keycloak JS adapter, which uses iframe mechanism and checks for KEYCLOAK_SESSION cookie and communicates with host window via some flags:
var cookie = getCookie('KEYCLOAK_SESSION');
if (cookie) {
data.loggedIn = true;
data.session = cookie;
}
The problem is that I can not rely on this cookie to check if user is logged in because the cookie has 30 day expiration date, which is way more than an actual Keycloak session lasts, let's say 15 minutes.
This cookie is being set when user gets authenticated and is not refreshed on each token update. I do not understand then it's purpose and the purpose of this flag.
I'm also thinking about relying on local storage and keeping refresh & access token there to determine if user is logged in, either by checking timeout or trying to refresh access token. BUT.. this also is not reliable, because user might have already authenticated using some other application.
To add more context to the problem... one of my SPA applications is a registration wizard, which uses REST API to register user and receives login_hint in return. This login_hint can be used as a wildcard in SSO redirect to pass the challenge and log in immediately.
However, if some other user is already logged in, we get in return session of this other user, not the one that should be logged in because of used login_hint.
We have discovered that our users very often for the first time visits our web application by browsing the direct URL of the OIDC client (https://oidcclienturl.com/), The ASP.NET Core OIDC authentication middleware kicks in and the user gets redirected back to Identityserver 4 login page.
Everything works fine but then they decide to add the (temporary? state, nonce, cookies...) authorization URL as a bookmark in their browser before entering their credentials and continuing back to the web application.
This causes an issue when the user later uses the bookmark in a new session. The login seem to actually work after entering valid user credentials even if the user uses an old authorization URL, but when the user gets redirected back to the web application they end up on a blank page (https://oidcclienturl.com/signin-oidc).
After the blank page have been loaded the user is able to browse the direct URL (https://oidcclienturl.com/) sucessfully and appear as an authentcated user in the web application.
Any ideas whats causing the blank page?
That blank page shouldnt exist, if I understand it correctly its the default callback path of the oidc authentication middleware in ASP.NET Core.
Unfortunately, the real-world problem of users bookmarking the login page isn't handled cleanly by OIDC, which requires the client app to initiate the login flow.
I've addressed this by adding a RegistrationClientId column to my user data table, which is the Identity Server ClientId corresponding to the client app that called IDS when the user account was created. In the client app configuration, we use the custom Properties dictionary to add a URI fragment:
new Client
{
ClientId = "some_client",
ClientName = "Some Client",
ClientUri = "https://localhost:5000",
Properties = new Dictionary<string, string>
{
{ "StartLoginFragment", "/Auth/StartLogin" }
}
// other config omitted
};
When a user logs in, an empty return URL indicates IDS wasn't called by a client app, so we use RegistrationClientId to query IClientStore, then we combine the ClientUri and StartLoginFragment URIs and use the resulting URI to redirect the user back to the client application.
Over in the client application, that endpoint kicks off the OIDC sign-in flow, and since the user is already signed-in on IDS, it comes right back to the correct location in the client app. The controller action looks like this:
[HttpGet]
public async Task StartLogin()
{
await acctsvc.SignOutAsync();
await HttpContext.ChallengeAsync("oidc",
new AuthenticationProperties()
{
RedirectUri = "/"
});
}
The call to SignOutAsync just ensures any client-app signin cookies are cleaned up. It's in our custom account service, but it just runs HttpContext.SignOutAsync on the usual "Cookies" and "oidc" schemes. Normally that would also result in a signout call to IDS, but the redirection by the subsequent ChallengeAsync replaces the pending signout call.
The downside is that the action is an HTTP GET meaning pretty much anyone could theoretically trigger this action. At most it would be an annoyance.
In the special case where your IDS is only handling auth for a single client, you can skip a lot of that -- if they land on the page with no return URL, just send them to your client app start-login endpoint straightaway, before they login.
I have a web app which is MVC 5 using OWIN cookie authentication. It also uses AngularJS from which web api calls are made. The Angular code is only invoked after the user has successfully logged in and been authenticated and everything works as you would expect.
However, can someone please explain what component (Chrome, OWIN, IIS, ...) is responsible for eventually issuing a 401 if the user has been idle for 20 or so minutes. In MVC this is not a problem because the redirect automatically re-authenticates but with web api my only option is to get the user to log back in again.
Ok so thats the first thing, who is responsible for timing the session out and giving the 401 (and can i alter it) but ALSO is there any way to get web api calls to keep the session alive so that even if the user is idle the api calls stop it timing out?
Specifically, I have implemented SignalR in a way that the signal to the client results in the client issuing an api call to refresh its data. I realise i could push the refresh but at the moment thats a bit tricky. So whats happening is the updates are occuring nicely but eventually this results in a 401 which i want to avoid.
below is an ideal flow
server logs in => creates cookie sets expiration time, passes it to client
client saves cookies & passes it with each request
server checks the cookies for validity including expiration time
if invalid or expired, server responds with 401
the cookie expiration time can be configured in the CookieAuthenticationOptions. See file ~/App_Start/Startup.Auth.cs
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
ExpireTimeSpan=TimeSpan.FromDays(365),
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
Provider = new CookieAuthenticationProvider
{
// Enables the application to validate the security stamp when the user logs in.
// This is a security feature which is used when you change a password or add an external login to your account.
OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
validateInterval: TimeSpan.FromMinutes(30),
regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
}
});
Set your ExpireTimeSpan to the desired TimeSpan.
For web api calls that fail authentication you could catch 401's and send back a response that tells the browser it's logged out - you could pop up a login dialog or redirect to login url.