We are developing a Single Page Application (SPA) using Durandal. I have a view Test.html.
This view will be consumed by another application (App2 which is not SPA) via iFrame. App2 will access Test.html directly via the application url - http://localhost/App1/#Test
My question is
Since we have two separate applications, how do I authenticate the user logged in App2 and display the view Test.html when requested by App2 via iFrame?
It really does not matter if you are embedding your app2 in an iframe or using it directly.
What matters is whether you deploy these apps under one domain or different domains.
In case of single domain you don't realy have to do anything on the frontend - just use the authentication cookie from your NOT-SPA app in your SPA app for authenticated requests.
In case of different domains, try implementing oauth implicit grant flow (probably with a server-side proxy).
Related
I want to secure my Web-App with Auth0 in React. This means a user can login on my page and use the resulting Access Token to make requests to services behind AWS API Gateway.
But Auth0 requires that all possible Callback URLs are defined in the Dashboard.
This works well as long as the Application is hosted on a domain owned by me.
In my case the React App will be distributed as a Plugin (Shopify, Woocommerce). My users will install this Plugin and use my App through their shopsystem-UI. Which means that requests from the browser are made from their domain.
How should I securely access my Services through this client which is distributed on Domains which i don't know beforehead?
As my research shows, one solution would be Dynamic Application Registration. But with this I would end up with one Auth0 Application per user and Auth0 Limits that to 100 Applications.
How should I handle my case instead?
I have a Nuxt application that interacts with NationBuilder, a 3rd party application. In order for users on my site to interact with data from their NationBuilder account, my app must allow them to authenticate over OAuth with the NationBuilder API.
The first step of this OAuth process works fine; My client sends a request to the NationBuilder API's /oauth/authorize endpoint. The browser redirects the user to NationBuilder's website where the user can login to grant my application access to their NationBuilder data. Then, NationBuilder redirects the user back to a second page on my site with query parameter in the URL containing what is called the "code". This second page on my site hits our internal API with this code, which in turn hits the Nationbuilder API's /oauth/token endpoint with the code to receive the access_token. Now we can use this access_token in any call to the Nationbuilder API.
The issue I'm running into is that when Nationbuilder first redirects the user to that second page in our Nuxt app, the reloading of my site takes a while and seems to be skipping some initialization configuration steps. I think this is the case because some of the functions that normally work when I boot up my site are not found.
I am in the process of developing the application, so I am running my site on localhost and using ngrok to create an https tunnel to satisfy the NationBuilder API. Maybe this issue is related to the tunneling?
I have a hunch I should be doing this all differently. If there is a conventional way of authenticating a Nuxt application with a 3rd party application over OAuth, please point me to an example/docs.
Cheers.
We made a CMS that allows users to connect to Google Analytics via a connector. I'm in the process of porting this connector to OAuth2 and am wondering what kind of application I need to register.
The issue is that the CMS is installed by our clients at arbitrary URL so we don't know the complete set of redirect URLs that I would need to register a Web Server application. Google's OAuth won't let me redirect to an arbitrary URL that I pass in during the authorization request?
Would registering an installed application and then using the urn:ietf:wg:oauth:2.0:oob special redirect URI be best? Seems like this allows the user copy/paste their authorization code from the browser back into our application.
Thanks in advance!
Indeed the installed application will allow users to copy and paste and not register. This is appropriate if the clients are end users of your application, and not say, configuring it as a plugin which will then provide web services to the client's users (where such users will then be prompted via the OAuth2 consent dialog). In the latter case you probably want to ask your clients to register their own web site as web application with Google and use a configuration tool for your CMS application to set the client's redirect URLs.
Why the distinction? Because in the first case the consent action is about your relationship with your clients, but in the latter case it expresses trust between your clients and their users. For instance, you don't want your CMS application to be disabled for abuse because one of your clients has misbehaved, as it'd affect all your clients. However, if you intermediated the consent you made it difficult for Google to understand the distinction.
I have a Silverlight control that's used to author some graphical content, and I am starting work to integrate it to Facebook so people can have access to their pictures. Things are working well, I am using the JavaScript API on the host page of my Silverlight control to interact with Facebook (log in/out, authenticate, etc).
The problem comes when I register my app with Facebook as a web app. This hostpage/Silverlight Control is hosted under several domains. From what I understand, I can register my web app with a domain like www.example.com, and www.example.net, and things will work for similar roots like site.example.com.
But not for www.example2.com. For my application to be able to log in to Facebook under this domain, I would need to register a separate web app with Facebook specifying this second domain, hence having a second Facebook App ID.
Am I understanding correctly? I have a lot of these domains (10+), and will have more in the future. Is there another (better way) to handle this situation?
I'm trying to figure out, how to use OAuth 2.0 to access Google APIs from my web app. The problem is, that the protocol require developer to register redirect_uri (URL of page receiving access token). But my application can be distributed to many customers and can be hosted on endless number of servers. There is no way to know redirect_uri beforehand.
Google offers another option for installed applications, but I cannot use this variant neither. Auth server returns access code in window title and this information cannot be accessed from javascript of our page (JS cannot access content of window opened using window.open(); if that content comes from different server).
To conclude:
Cannot use method for web applications, because I don't know all URLs where will our app run in the future.
Cannot use method for installed applications, because window title is not accessible from our JavaScript code.
Is there any recommendation, how to use Google's OAuth 2.0 from distributable web application running on a lots of servers? Thank you.
Are you sure you cannot access the window title? If your app is opening the window, it should be able to access it. It should be possible to do this in a similar way you would do it in a mobile app.
If all attempts fail, you could set up a proxy server (that has a known redirect URI) and hands out the Google tokens to all your clients. Or better each of the apps could have its own proxy server - the server it was downloaded from. But then if each OAuth client can only have one redirect URI, each app would have to be a separate OAuth client.