We have created a vb.net web app, it is secured with Azure AD easy auth.
The custom token policy has been created to log the user out after 20 minutes of inactivity, but the user always remains logged in for 8 hours.
Azure support have advised that this is because of the session cookie used when using easy auth over-riding the token policy. They also advise this cannot be changed from 8 hours which is far too long for a web app containing sensitive data.
Has anyone come across this or know of a workaround? As easy auth is “code-less” there seems to be nothing I can do in my project to affect this.
I think your Azure Support contact recently asked me about this case. Unfortunately the cookie lifetime is hard-coded at 8 hours. We can add support for making this configurable or to have it match the Azure AD token lifetime, but unfortunately it would take some time before such a change would be able to reach production.
Related
We are deploying a simple webassembly application that will be secured by Azure B2C.
We've got this setup and deployed and is logging in correctly and communicating with a secure API. The problem we are running across is timing out a user's session.
We are using MSAL in the program.cs to communicate with Azure B2C as recommended, but this means our front end application is using the Access token, rather than a session token to track access on the front end.
builder.Services.AddMsalAuthentication(options => { builder.Configuration.Bind("AzureAdB2C", options.ProviderOptions.Authentication); options.ProviderOptions.DefaultAccessTokenScopes.Add(builder.Configuration["SwaggerAADApiScope"]); options.ProviderOptions.LoginMode = "Redirect"; });
This has resulted in a user seemingly never being timed out on the front end, even if they leave it for an hour and come back they are still logged in. This is seen as a security issue so we need to correct that.
Is it possible to secure a Webassembly application using a session cookie rather than an access token? I'm guessing not as that doesn't seem to be the recommended way of doing it.
Alternatively I assume the access token can be set to have a much shorter lifespan, not sure if this would have any significant performance implications, but might be the better option- in the longterm.
Any insight appreciated!
My understanding: In an Azure App Service, you can set the service to basically never "fall asleep" by setting the "Always On" setting in Azure Portal.
While this is an easy change to the service, I am trying to avoid having the service constantly run when not in use, and driving up the monthly expense of hosting the service.
My dilemma is that I have an Azure App Service running, which I authenticate a Xamarin Forms app against. In the process of logging in, I return an OAuth token to the client which is set to expire in 15 days (something long for testing).
Everything works fine while the Azure Service is running, but if the Azure Service "falls asleep" then I am forced to login again - which leads me to believe that the tokens issued by the service have been lost after the service falls asleep.
My question is: Is there a way to store the current tokens in an Azure Table Storage (or something) prior to "falling asleep", then pull from the same storage when the service "wakes up"??
I did find the below question, but couldn't get a clear understanding of how to persist the bearer tokens:
How are bearer tokens stored server-side in Web API 2?
I have been searching high and low with clear indication of how to do this, let alone if this is even possible.
Any help would greatly be appreciated.
The answer of How are bearer tokens stored server-side in Web API 2? you find is right. Usually, we will store the access token in client side. You can store it any place in your clients, local storage, sqlite, even files. Just to make sure, your application can get back the access token.
When your application send HTTP requests to the protected server, you will set the access token in Authorization header.
And your server once get a HTTP request, it will verify the token and authorize the user.
I am currently using Auth0 for the offline authentication with downloading the token and validating the user against it. I am now looking to migrate to the Azure Active Directory - just want to double check if they have anything to support my existing process.
How long do you remain offline? Access tokens in Azure AD have a validity time of one hour and are automatically cached. Technically you could relax the expiration check if you want them to last longer, although that's usually not recommended.
I am developing a healthcare related web app and part of HIPPA compliance is that public available web apps need to enforce certain log-out behaviors. One such requirement is that when the users clicks "logout" in the app they must be logged out. Relying on the user to close the browser to clear session storage is not an option.
I am using ADAL-js with angular to handle auth for my app. When you log into the app login.microsoftonline.com stores cookies. As a result if you navigate back to the app you are auto logged back in without being prompted for credentials. That violate the requirement described above. If you use the dev tools in chrome to delete the cookies for that host the problem goes away.
Does anyone know of a way with the Azure AD Oauth service to enforce this more strict requirement?
We ended up opening a bug against Azure AD with Microsoft. They have since deployed a fix. This all occurred earlier this year. So this update is a bit late.
ADAL.js exposes a couple of functions clearCacheForResource() and clearCache() in the adalAuthenticationService Service. After calling adalAuthenticationService.logout(), you can clear the browser cache by calling the above functions. They should clear the cookies.
You can also try using the $cookieService provided AngularJS, for better control on the cookies.
With the recent release of Azure AD, we would like to use Azure AD for our web application authentication, but we do not want to use SSO. We do not want users to be redirected to the Microsoft Account login screen, and then come back. We want to supply them with the login credential screen where we capture their username and password, and then we want to programatically do the authentication against Azure AD, and get back the claims identity.
The problem I have is that I cannot see how I can do that using the Graph API, and all the examples that look like it might work, only works on the previous [0.8] release. There is such a mix of examples that is supposed to work, but they don't simply because of the new release.
Can anyone tell me if this is even possible, and maybe point me in the direction of how to do it please.
I do not want to use ACS.
What you are asking for is not technically possible with Azure Active Directory today. That scenario could possibly be supported in the future, so check back from time to time.
We really encourage developers to rely on the in browser sign in experience. The reason is that because the browser allows the server to define the experience, it allows for much greater flexibility with respect to the kinds of credentials that can be employed. For instance, if you code your app to use only username and password, then it may need to be updated in order to take advantage of two factor authentication. If you rely on the browser based experience then your app can be totally agnostic to whether 2FA is being employed, or any other kind of authentication dance.
We recognize that there are some scenarios where this is not ideal or even practical and are looking at solutions to those scenarios that may be supported in the future.