Share JWT between an app and a browser on multiple subdomains - authentication

Here is what I'm trying to achieve:
Right now, the Desktop App, Auth server and API are working correctly, I can get my JWT and use it to call the API.
Both web apps are already in use, subdomain1.domain.com use NGINX auth_request, cookie and sessions on an old auth server to get access.
Web app in subdomain2.domain.com use session, and connect to the API with an app token.
And, all these servers are part of the same domain.
So, is it possible to share the JWT from my Desktop app with browsers? We generally use Chrome.
The desktop app use Python 3, and most of the user will be using Windows.
If I can't, and I'm pretty too stupid to do this working, my other concern is, can my browser use that JWT on all web app once it connected get it from auth server? All servers shares the same main domain.
Our web server can be using Apache2, Nginx, Nodejs or Flask (python), which is kind of annoying when trying to make things like that works.
I could use cookie for .domain.com, and store the jwt inside, am I right?
If yes, is this really the best idea?
The idea behind it is:
User log in the app or browser
JWT is generated
JWT is shared between app and browser (not sure about this one)
JWT is used on all subdomain by the browser
What is your advice on this?

I think you can use a cookie in that case with no regrets. Just configure it correctly that every domains you need to have an access to this token.

Related

Bluemix Single Sign on for a mobile app

I'm adding a login page for my mobile app, so that it integrates with Bluemix Single Sign On. I'm at the step to configure the Node.js app following the Bluemix Doc at Configuring a Node.js app. The example here about callback is for a web app. In the mobile app context, I don't have a redirect URL. So this code for example:
app.get('/auth/sso/callback',function(req,res,next) {...}
On the mobile client side, do I do a GET to /login?
I already have a login implemented using Mobile Client Access service. Is it something I can build up upon? For example,
app.post('/apps/:tenantId/:realmName/handleChallengeAnswer', function(req, res {...}
Can I call the Single Sign On API in here?
Thanks a lot for your help!
Jen
Is your mobile application based on nodejs? If so and you use a webview on your mobile application you could leave to the webview component to manage your authentication flow like working with a browser.
You instead have to manage authentication if your application is integrating with Rest APIs, in this case you could use SSO but your application has to manage cookies like a browser.
Bluemix Single Sign On so far has only been tested on web applications. I have no knowledge on whether Single Sign On would work smoothly on mobile applications.
Also, the Bluemix Single Sign On follows the OIDC protocol. So the redirect URL is a mandatory parameter when using the service, unfortunately.
Regarding building upon your login implementation, to my knowledge, it is not possible to include your implemented login in place of what is provided with the Single Sign On service. But you can choose to add the login implementation in addition to the login needed when using Single Sign On.
Hope that addresses your questions.

SoundCloud: Authentication when the web server is local

I've created an app that uses Javascript and php. The php is hosted on an apache server which is located in my house and is not accessible from outside. To start the 'app' I just point my browser at
http://server-ip-address/my-app
The problem I'm having is with SoundCloud Authentication.
If I'm using a browser on the same machine as the apache server then I can authenticate using a redirect URL of
http://localhost/my-app/callback.html
and setting this in the app settings on soundcloud.com and the initialise function in the SDK.
The problem is, what if I'm not running the browser on the same machine as the apache server? The app is a remote control for a music player, hence the server will generally be running on a headless PC and the app will be accessed from another device. There seems to be no way to get Authentication to work in both these scenarios since the URI I send in the initialise function has to match the one on the soundcloud app settings and I have no way of knowing what server-ip-address will be for everyone who might use the app.
Unless you do have a way of locating that server (with static IP or some dynamic DNS service) you won't be able to authenticate – SoundCloud has to pass the oauth_token somewhere.

What kind of application do I register for a web application that can run at an arbitrary URL?

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.

Enabling an application to use a Google AppScript Webservice as a proxy to a Gmail account

I've been trying to integrate my application (ruby) with a Google AppScript (published as a Web Application with access level as 'only me') on behalf of a Google Apps account for quite some time, but I can't get a handle of it. Maybe I'm missing a key concept here or that sort of authentication/authorization isn't available when making requests in the background.
The script works fine when I'm logged in to gmail and access the script endpoint. I can also successfully connect to it using a sinatra application authenticated with openid.
I've already tried to use google-api-ruby-client, but I can't get the authorization scope right (service name). I've also tried clientlogin in gdata-ruby-util, to use Gmail login/password and get an authorization error message when trying to fetch from the script url.
Is it doable? Can anyone point me in the right direction?
Unfortunately, Contentservice in Apps Script (which I think you are using to create your webservice) doesn't provide any authentication mechanism. If you are accessing it from a server side script, you can use a token string which is known by your webservice app and your server to provide a level of security to your publicly accessible webservice.
Here are some similar discussion
How to use Google Apps Script ContentService as a REST server
Google App Script: ContentService web app usage

OAuth 2.0 for distributable web applications

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.