I often develop in a local React SPA and want to use an IAP protected backend API. The backend API is only IAP protected in dev, in production everything is open.
Currently the only solution I can think of involves a mostly transparent nginx proxy running locally that takes a users credentials and constantly does programmatic IAP Auth and attaches the appropriate cookies/headers to all requests. So a kind of Identity aware 'proxy proxy'.
I don't want to add IAP code to the react app, because IAP is only for development. I'm surprised no one has made anything like this yet though (I couldn't see anything on GitHub), does the approach sound valid?
Related
We develop .net core based web server app with web browser client. This app will be installed on our client's dedicated servers. Our app will include, among others, contacts and calendars and we want to allow users sharing data between our and cloud agendas (via Azure graph-api, Goods api) .
We registered our app in Azure (for now, we assume it will be very similiar for Google) and got some codes (client, secret etc.). Now, we are not sure, what's corrent auth/usage flow.
Client side - a new browser window will be displayd to the end user, asking for grand types and login, but then the server should ask for an access token, as it will interoperate then. As I understand - this is done by using "redirection_uri" going to the server address.
The main problem here is that when registering our app in cloud environment, limited redirection address list is defined and checked later with "redirect_uri" parameter. Our application will be installed on customers' servers and we don't want to force them to register their own applications in the cloud's administrations as they even will not have their own cloud subscriptions.
Edit 2020-11-18:
I'll try to describe again what is our task we want to find solution for:
We develop web app with browser based clients
We sell this app to other organizations and they will install it on their own servers and will have their own customers (final customers) using this app
These organizations don't have to have O365 subscriptions
We, as developers, want our internal app calendars and contacts (among others) to be connected to final customers' Azure/Google calendard and contacts.
It means, that the synchronization itself will be between organization's instance of our app and their customer's Azure/Google calendars/contacts.
I'm sure this must be quite common problem but I have't found any reliable answer.
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.
So my current task at the company I'm interning with is to create a mobile version (iOS) of a web app written using Flask, HTML & CSS that currently exists and is being hosted on AWS's EC2. Assume I'm a complete noob at AWS and only just learned that EC2 is a cloud computing service.
Essentially, I just want to be able to reflect what's currently on EC2 over to a mobile app in a secure fashion. I guess I'm just trying to avoid rebuilding something in Swift that's already been done. For those familiar with WebView in Xcode, I tried to use that to reflect the web page, but it didn't work (I assume because our web app on EC2 requires login credentials when you open it in a browser?).
I thought that maybe using AWS's SDK for iOS would net me some luck, so I installed cocoapods and setup a pod, but don't know how or which of these AWS services will help me achieve what I'm trying to do (from reading the documentation, it seems like their purpose is for building an app, not necessarily just projecting a webpage with data already in it).
For some more information, some key features that I think would be useful for our clients that would be using the app are:
The ability to persist data on the app when their device is offline
Some sort of temporary logins for the users. This app wouldn't be distributed through the app store; it would probably just have to be locally downloaded onto certain clients' devices
Lastly, I saw this post come up before creating this one: Does REST API for mobile apps hosted on https protocol web app will be slow? and I noticed that the asker of this question said "Lets say I have built a mobile app running on Android and iOS platform and REST API's for these apps lie under https based web application." This possibly sounds like something that could be helpful, and if anyone could explain what s/he meant by REST API's and what they are, I would be very grateful.
Any advice on how to proceed from here, using anything, would be much appreciated. Thanks!
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 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.