I hope you are doing well!
We are working on a project that consists of 3 projects/websites. It's basically something like a Management Platform for the resources, a Platform to display information and updates, and a Platform to manage both those platforms. (Something like Office365 and PowerPoint, Word, Excel where Office365 is the main application between them).
In our project, we want to integrate a navigation drawer in which the user can navigate to the different application from our 3 websites without having to re-login. In this case it would be easy. However, would there be a way that if the user access the other website from the browser (ex:"www.exameplwebsite.website2.com") we login the user directly if he was already logged in to a previous application from ours?
We thought about local storage however the local storage and cookies accessible depend on the domain we are accessing.
Is there a way to make this happen? Or would using a navigation drawer the only way possible?
(For context we will be using ReactJS)
I think it wouldn't be that hard with JSON Web Token (JWT) for authentication. When you redirect the user from one site to the other do it with a post request and include a JWT token in it. The new site can capture that token and send the token to the browser and the browser can catch it and saves it into its own localstorage.
I can think of two solutions ->
Use micro frontends (Recommended)
If all three apps have different domain names (app1.com, app2.com, app3.com) then you're right you cannot share any token using cookies and local storage.
Here, You can take the login/signup pages and the navigation drawer into one parent app and load all your other apps using micro frontends.
Use SSO
SAML and OIDC are made for this specific purpose but this is a very complex topic. Basically, your users will need to log in once(at someplace like google or OneLogin or your own identity server)
Related
We have a solution which using multiple SPAs written in Angular and AngularJS. These application implement the oidc-client-js library and authenticate in Identity Server 4. Due to limitation of AngularJS we need to render our legacy AngularJS apps in iframe. There is one main application that allows to login through IdentityServer4 and then we can open different SPA inside that main application. This is working fine until we logout and then login on different user. On the main app and apps that are written in Angular7 the user is correct but when we enter on application that is rendered in iframe the user stays from previous session.
According to the IdentityServer docs I was trying to add
FrontChannelLogoutUri to notify all logged in clients and end all sessions.
But I haven't found what this logout page supposed to do.
Also I was trying to clear all grants when logging out but there is no grants to be cleared. To acheive this I used following method:
await _persistedGrantService.RemoveAllGrantsAsync(subjectId, clientId);
This method from IdentityServer returns empty list.
var grants = await _interaction.GetAllUserConsentsAsync();
I believe after FrontChannelLogoutUri is rendered the session should be ended but I have no idea how to achieve this.
After redirect to FrontChannelLogoutUri probably need to clear session storage in iframe. For now this is working fine.
I have developed several web applications with the own login forms/logic etc. I would like to simplify these by creating a single dedicated web app to handle all the login logic using FirebaseUI. The way I imagine this working is when the user needs to login with one of my apps they are redirected to my login web app. The user supplies their credentials and if successful the login app redirects back to the original app with data to confirm whether the login was successful.
If this is possible I shouldn't have to repeat the login logic in my other web applications and any changes to login code are only required in my login app. I'm not sure if such an approach is possible, however, or how I could securely and safely let each web app determine that the user has successfully logged in. Can anyone offer advice on how to implement this or point to examples where this has been done already?
You might be looking for single sign-on.
Google does something similar. Every time you login you're redirected to accounts.google.com, and after that you're redirected to your app.
You're right in saying that it's trickier than it appears on first sight though. Most web login systems are based around cookies and the whole client-server process around them. Cookies are set per domain. If all your webapps are on the same domain or subdomains of a single domain, you should be OK to go with this approach and get the results you want. If not, you're going to need some extra work to get code from different domains to speak with each other and make everything possible.
In general, if designing a login system from scratch is considered a big endevour, designing a single sign-on system is an order of magnitude harder. OWASP had this to say about them in 2011.
I am trying to get it so that when the user on the local network opens up the webpage it will log them in with their active directory username and password through a react js system with a C# API back-end. would react just say someone has connected on load and then send a message to the web api telling it to pull the user and authenticated it pushing that to the webpage for me to use as the login details.
You can achieve by using common authentication/authorization protocol OAuth 2, which is commonly used.
for example google have different product like gmail, drive, doc etc which is hosted in different domain. But when you login in any of this domain, you don't require to login again in any of its product. it use Signle Sign on concept
Im working on an web application using the MEAN Framework, within that app I want to give the users the ability to upload files.
Now heres the main thing:
All users uploaded files should be uploaded to a SINGLE dropbox account (my account)
They will only upload files of with the max size of 20MB (I've already built the functionality to check the file size before upload)
What I've done:
Ive gone to a Dropbox developers and I have setup my app. And now I have access to my appKey, appSecret and also a Access Token
My questions:
Is it possible for me to connect a single dropbox account (my
account) to my app and give users in my app access to upload/download files from the dropbox but by using my apps interface?
As I already have the access token would I or every user in my app still need to go through
the OAUTH process?
Can I just send my Access Token with each request to Dropbox api every
time a user uploads a file through a specific form on my app?
If you can provide an example or a link that would be very helpful.
UPDATE:
I generated my token using the following button on the dropbox developers console:
Assumption: it is supposed the user of your apps are "legit" and that they won't do anything of your dropbox files that should concern you.
Yes, it is. You can configure your app to be the consumer of your dropbox; of course, your app will also have to make sure the users of the app are legit (check them with user/password login and so on) --note: consequences can be that any unauthorised person able to use your app can delete permanently all your files (or do anything as bad as possible according to the privileges)
The access token is part of OAuth, so I am not sure what you mean when you say "process". I will interprete your question as "how do I refresh my token?". Simply, before every call to dropbox API by your app, you check the expiration of your access token: if it is still valid you just perform the call, otherwise you request a new token. You do not need a Refresh token in this case: the OAuth mechanism (or 'grant flow' as per OAuth jargon, or 'process' to use your word) you are using is called "client credentials grant flow"
See above 2)
Some links for you: Here some overview of the grant flows.
Here a schema of that grant flow (note: MS uses another component called "ActiveDirectory" to grant permission; in your case, both "Azure AD" and "Resource API" are just "the dropbox server")
I have an ASP.NET MVC website deployed as Azure website (called website). That website has a section that needs authorization. I already have set up Windows Azure Active Directory (WAAD) to protect access to that section. Once that protected section has loaded, it will load a Javascript app that allows integration with the Azure Mobile Service.
I also have a separate Azure Mobile Service that I use for data storage (called mobserv). I want to access mobserv table and api endpoints from website. I am using the .NET backend for Azure Mobile Services.
Of course, I need to protect those mobserv endpoints using [AuthorizeLevel].
Tutorials show how to do this when I want to authenticate as Application (using [AuthorizeLevel(AuthorizationLevel.Application)]) - just add a reference to the proper Javascript Client (MobileServices.web-1.2.5.js), provide mobserv app id and token. CORS is set up to allow interaction. So far, so good.
But now, I want to protect certain endpoints using [AuthorizeLevel(AuthorizationLevel.User)]. So now, the request has to be authorized as User. Since the website already has been protected by WAAD, I do not want the client to perform a new sign in for the javascript client - I want to reuse the current WAAD authentication headers to have a Single Sign On Experience, so that mobserv will recognize the user.
I have not found any hints on how to do this. Tutorials only show application level auth against mobserv or using explicit login dialogs.
Does anybody have a clue how to do this?
Following up on vibronet's post, Mobile Services does support HTTP POST of an access token, but the access token must specify the audience as your mobile service. So a token issued for your website will not work on its own. You will need to transform it through one of the AAD flows.
So in AAD, you need you have two web application registrations, one for your web site and one for the mobile service. On the mobile service registration, you would need to define permissions that can be exposed to the other resource. The first section of the Mobile Services + ADAL tutorial ("Register your mobile service with the Azure Active Directory") walks you through this. Then, instead of registering a native client app which accesses that permission, you would go to your web site registration and configure the access there.
Once you have an AAD token for your website, you can leverage this permission to get a token for the mobile service. This can best be accomplished using an on-behalf-of flow in the Active Directory Authentication Library (JS or .NET, depending on where you want to do things). The AAD team has a nice sample on how to do this, and mobile services also has a tutorial which might be helpful, although it does mobile service access to SharePoint Online as opposed to web site access to a mobile service)
Then you can send the token to your mobile service using the "client flow" method, as described in "How to: Authenticate Users" for the HTML/JS SDK. For AAD, the call will look something like:
client.login(
"aad",
{"access_token": "<TOKEN-FROM-AAD>"})
.done(function(results){
alert("You are now logged in as: " + results.userId);
},
function(error){
alert("Error: " + err);
});
The user will not see any new UI, but they will be logged in, and subsequent calls from the SDK will be authenticated.
It might also be easier to do this from your MVC backend. I believe you can get the access token from the ClaimsIdentity, and then you can just use the Mobile Services .NET client SDK to do the login action and facilitate calls from the MVC site to your mobile service:
JObject payload = new JObject();
payload["access_token"] = "<TOKEN-FROM-AAD>";
MobileServiceUser user = await App.MobileService.LoginAsync(MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, payload);
token reuse 'as is' cannot be achieved given that the tokens you get for website are scoped to your app and should be rejected if forwarded to any other resource. From the AAD perspective there are various flows that would allow you to trade in your original token for a new token meant to be used with a web API - all without requiring any new action from the user. However your scenario includes some Mobile Services specific moving parts, hence I am not sure how that would apply here. I am flagging this post for the Mobile Services guys, hopefully they'll be able to chime in.