I have seen other questions on SO about this (here, here, and here), but I am not satisfied with any of the solutions, so I am asking it again. I am starting a web application that will utilize OAuth from multiple providers (Google, Facebook, Twitter, Yahoo) for authentication. I am struggling to find a configuration suitable to use for both a local development environment and a production environment.
The leading solutions I've found are to register multiple apps within each provider, receiving a different consumer key and secret for each:
"My App Production" - with a callback URI to http://www.myapp.com/callback
"My App Development" - with a callback URI to http://local.myapp.com/callback
Add an entry to your local hosts file to point local.myapp.com to 127.0.0.1 and some configuration for your application to use the proper consumer keys based on the environment, and you are good to go, right?
But my application is responsive and I need to test my development environment running on my PC from multiple other devices, like my iPhone and iPad, neither of which will be able to resolve the development callback URI.
Let's say I already have a DNS server on my network and am able to add the entry for local.myapp.com there instead of my local hosts file and can now access my development instance from any device on the network.
But my development team all operates on the same local network. Now local.myapp.com points to the same IP for everyone. Let's go back to setting the hosts file on each developer's computer so that they can all work independently from within their workstation. Now no one can test their development instance from their iPhone again. It hardly seems like the right answer for each developer to register an application with the provider just so they can specify a unique callback URI.
Normally when I get way down in the weeds with a complicated solution for a seemingly straightforward issue, it usually means I'm doing something fundamentally wrong. Am I missing something about OAuth, is it not intended to be used like this? I am tempted to scrap OAuth altogether and just go with OpenID (no app registration required and can specify the callback URI from within the app), but then I lose two of the big hitters in Facebook and Twitter. I don't really need any of the user's data, it's just a nice to have if it's available. Can someone talk me back into OAuth?
I can't speak for FB or Twitter, but in Google's Oauth implementation you can register several oauth callback URLs. So you simply need some logic in your app which senses that it is in test mode, and then starts the Oauth flow with the appropriate callback URL. There are downsides, eg clashes between the live and the test refresh tokens, but they are manageable.
In my app I have a singleton which manages all of this. When my app needs to start an Oauth flow it calls the singleton with the request URL and any other salient data (eg. debug flag) and the singleton returns the correct callback URL, client ID etc.
I posted the following answer about a rails app I wrote:
OAuth2 in development and production
It was a gem called figaro which did per env configs for google OAuth2.
I have yet to find a less manual approach that enables dev access to all concerned devices:
Assign each developer's machine a fixed IP through the local network's DHCP system based on their MAC address, or (less recommended) have them choose an IP and hope for the best
(optional*) Assign each developer's machine a DNS hostname in the local network based on that IP
Register an oauth entry for developer on each provider with the hostname of the developer's machine.
Each developer configures their application to use their unique oauth dev tokens.
Assuming all the devices in the network rely on the same DHCP and DNS servers you'll then be able to visit alice.dev.myapp.com or bob.dev.myapp.com from any device on the network.
Note, you'd manage the oauth configuration for each an every other environment separately, but following the same approach.
There are likely tools to automate registering a developer's machine IP and hostname to ease that part of the puzzle. Registering the oauth config on each provider per dev is the most tedious step.
UPDATE
*You can skip the DNS part if you use a xip.io url e.g. 10.0.0.123.xip.io if you know Alice is 10.0.0.123, but you'd still want that IP to be fixed as you don't want to keep updating the url for the oauth tokens in step 4.
Related
I followed the tutorial on learnforge.autodesk.io and was able to create a functioning app that accesses data from Construction Cloud and displays them using Forge viewer. The problem is, I'm not able to access Autodesk's login screen behind a firewall (which usually happens when sales team visits a client's office).
For what it's worth, I'm using ExpressJS for backend and have HTTPS enabled. The firewall at client's site also blocks access to virtual machine services like Parsec.
I don't even know exactly what the problem is (or how to troubleshoot), all I know is that this login link:
https://developer.api.autodesk.com/authentication/v1/authorize?response_type=code
&client_id=<client_id>
&redirect_uri=<callback_url>
&scope=<scope>
doesn't work behind a firewall (it works fine through mobile data hotspot though).
So is there anything I can do on my end to make it work?
If that's not possible, what must the client do in order to access my app from behind their firewall?
I'm trying to setup Kahuna for my iOS app, and haven't been able to find a clear answer - the docs says that the secret key is meant to be used with the API Key for authenticating requests, but I can't find anything that states clearly if either of these should be kept secret/out of source code. Are these safe to put in my code, or should they be kept on the server side?
Thanks
Are these safe to put in my code, or should they be kept on the server side?
Short Answer is no for keeping them on the mobile app code and yes to keep them on the server side.
Why?
Because they will be static secrets in your mobile app code, thus they are easily extracted by using any reverse engineer tool, like using the Mobile Security Framewrok(MSF) to decompile the app binary.
Alternatives?
Well you can try code obfuscation, to generate the secrets dynamical in the mobile app or to store the secrets in the iOS keychain, but once more they can be reverse engineered at run-time, once more by using the MSF tool.
Possible Solution?
The best approach is to use a Mobile App Attestation service to protect the connection between the mobile app and the API server, that will guarantee at run-time that your App is not being man in the middle attacked, being tampered with, that is not running in a rooted or jail broken device and that is the same original one uploaded into the app store. This is done in the background without impacting the user experience by using an SDK integrated in your App and a service running in the cloud.
With this guarantees in place we don't need any-more to store secrets in the mobile app for Authentication, Authenticity and Integrity purposes, thus any access to third part services within the App can now be delegated to the API server that will be able to do a better job of protecting all the necessary secrets to access the third part services, like storing them in a vault.
You can find a Mobile App Attestation service in Approov(I work here) that provides SDKs for several platforms, including iOS. The integration will also need a small check in the API server code to verify the JWT token. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
I've taken over development of a Google Analytics API dashboard for a content management platform, and upgraded the code to use OAuth2 as the older oauth was disabled recently. The authentication flow and subsequent API calls are all working fine on my localhost for development.
The problem is when trying the code from a different domain. Google wants the redirect_uri to be whitelisted through the developer console, and if it isn't there, it throws Error: redirect_uri_mismatch
As this is a self-hosted (+ open source) package, people will be able of installing on their own servers, there is no way I'll be able of adding all possible redirect_uri values to the app key in the developer console.
After a bunch of Googling and trying to understand the docs, I get the impression there are 2 possible solutions.
Instruct users to go to the Google Developer console, and to create an app key of their own, before also going through the OAuth2 flow within the distributed app to provide the code access to the data in Google Analytics.
Use a redirect_uri value of urn:ietf:wg:oauth:2.0:oob with an Installed App key, instructing people to copy/paste the code back into the self-hosted app after authentication.
Neither of these are really appealing as it adds a bunch of complexity for the user (though option 2 sounds mostly doable). Are there other options, or am I simply overlooking something simple?
You actually don't have any choice in this matter. You must go with nr 1. When you state this is a dashboard and web application it leads me to believe this is some kind of scripting language. This means that the client id and client secret will be displayed to your users / customers. This is against googles terms of service.
Changes to the Google APIs Terms of Service Asking developers to
make reasonable efforts to keep their private keys private and not
embed them in open source projects.
You may not release your client id and client secret to your users they are going to have to create there own. Which nicely solvers your redirect URI problem they have to make there own.
Further reading Can I really not ship open source with Client ID?
I created an app to be used in a page tab. I have it hosted on my server which has a SSL protocol associated. However, the https url hasn't the usual naming (you can see it below):
https://secure395.websitewelcome.com/~rexdot/discoverylocker/
Is there any reason FB doesn't accept this? I'm sure this is the https url, it was given from my server support. And I'm also sure the app is there and fully working.
Thanks!
according to hostgator only solution is to pay for your own SSL. I've used other hosting services with reseller accounts and never had this issue before. In fact, the apps were running fine on those shared SSL certs from other companies.
So, one big reason why hostgator is not the way to go... their shared SSL is for websitewelcome.com which has been flagged as spam.
I have an iPhone app which needs to securely connect back to our hosted environment. It is doing this using SSH, and then uses port forwarding to connect to localhost:port which is really a service running on the host.
Currently the way I have the proof of concept working is by including the certificates (private and public) in the app, and then connecting by SSH to the host.
This means that passwords do not need to be distributed, however is this good practise? Should the private key be included with the app?
If not, how should I do this without distributing passwords, and what should I include?
Distributing the password or distributing the private key are exactly the same thing and both are generally no-nos.
You haven't given us enough info on what you're actually trying to do, but it sounds to me like you're take a very convoluted approach to what is most likely a solved problem. If your iPhone app needs to communicate with the server, then you should, at the very least, have each iPhone app generate its own private/public key combo and add their public key to your authorized users on the server out-of-band, as that way you can selectively revoke access for individual users.