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!
Related
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.
I want to implement login and logout functionality and retrive user details like username and user role using Azure Active Directory.
We are using Docker to deploy Spring cloud microservices project on Azure cloud. Could you please suggest me steps to get user details?
Do we need to secure all microservices edge points using Spring cloud OAuth2 security using JWT or just we can secure one web microservice ? Do I need any permission ,specific user roles to implement this?
You can find Azure's documentation about OAuth 2.0 support for AAD here
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-protocols-oauth-code
I've got an application that's using OAuth 2.0 with a different Authentication Server, and I'm about to see if I can use AAD as the Authentication Server. But, whatever ends up being your Auth Server, the rest of the application should be the same...
The Auth Server handles the log in (typically as a Single-Sign On pattern)
The Auth Server will return a Json Web Token (at some point, depending on the Grant Type being used to retrieve it)
The JWT should be included in each subsequent request to ensure the caller has authorization
From a Spring perspective, you'll need at least a SSO Client (denoted by the #EnableOAuthSSO annotation). If everything in hosted by that process, you'll need that JWT to call subsequent methods. If you have processes hosted in other processes, it's likely you'll want them secured as well. Using the #EnableResourceServer annotation will configure Spring Security to look for the JWT, just not attempt to retrieve one if the request does not have it.
Unless the endpoint is meant to be publicly accessible, you will want to secure it. Of course, I really don't know the context of your application, so this statement is purely an uninformed opinion based on zero knowledge of what you're trying to do with your application. Take it for what it's worth.
EDIT
This has become a little more complex than I originally thought. I have been able to write some code to dynamically retrieve the public key from Microsoft in order to validate the returned JWT.
But, the main issue is the fact the Azure AD supports Open Id Connect when acting as an Identity/Authentication Server. And, at the moment, spring-security-oauth2 doesn't support Open Id Connect.
I was able to make some small changes to the spring code, but I did ask the question to the Spring group and they are actively working on adding support for Open Id Connect. They hope to have a release two months (ish?).
For the short term, the oauth2 support doesn't support Open Id Connect. Given this is the protocol used by AAD, the current version of oauth2 won't work with AAD. That said, I will be happy to wait for the official support which shouldn't be too long.
I have in the past done a hand rolled app that stores a user token on client side $window.sessionStorage.
I have since then realized this is not safe. I am now looking for the most safe, standard way to secure an app that uses a node/express backend api that I will make, and also uses a front end that makes requests to this api such as angular for web or a native mobile app. Plus, whenever I would close the browser, I would have to re-log in because the $window's session storage was wiped out.
From what I've researched thus far, one of the safest ways to date if you're going to handroll it is to store a jwt in an http only secure cookie.
However, I'd kind of like to use a service that already exists, such as oAuth. Couple questions:
1) How safe is oAuth in terms of keeping ownershp of your userbase? What if 3 years from now oAuth just suddenly or slowly dies out? Aren't all my users technically stored on their server? How would I keep my users native to my app?
2) If I'm going to be creating a startup app in the same realm as snapchat, twitter, tumblr, etc... would it be generally recommended to use a service like oAuth to handle my authentication? Of course the future is unknown, but assuming the best, that my app would reach millions of users, would using a service like oAuth still be a smart choice? It seems like once you start using oAuth, there's never any going back to storing your users in your own database a year or two down the road.
Thanks
OAuth is an open standard for authorization.
Maybe you're thinking about Auth0. There are a lot of services that can handle user authorization for you, including Auth0, Stormpath, Apigee, UserApp, AuthRocket or Amazon Cognito. Whichever you choose, make sure that you can get the database from them in case you want to stop using their service. Not everyone explicitly offers an easy way to leave them but if that's important for you then make sure who suits your needs and who doesn't, and base your decision on that.
As for OAuth, see the https://en.wikipedia.org/wiki/OAuth article.
There's a huge list of OAuth providers on Wikipedia but those are services like Twitter, Google or Facebook. In a way you can use one of those services to manage all your logins but as soon as they see you as their competition, you're in trouble. I've heard stories like that.
Some interesting read on the subject:
The dangers of OAuth/Social Login
Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services
OpenID Vulnerability report: Data confusion
Social Login Setups – The Good, the Bad and the Ugly
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 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.