My mobile app on both Android and iOS uses Cordova’s InAppBrowser plugin to allow users’ to authenticate using Google OAuth2. As I understand, Google will be removing that capability in a few months in order to support making it easier for users to sign in using existing session from the system browser.
The issue we have is that our app's sign in process actually needs to not use any existing session credentials. Our app is an employee time clock that may be used on a shared mobile device (e.g., kiosk). Normally employees clock IN and OUT of work using an employee pin, but an administrator may sign into a special administrator mode to do things like set up a new time clock or access privileged functions. We rely on the administrator having to enter fresh credentials each time. We don’t want any existing session to remain around as the device is not considered safe for that. I hope that make sense.
It looks like Google's sign-in SDK for both Android and iOS have a way to disconnect users, which I assume means the session will be locally removed. However, Google sign-in is not central enough to our business that we want to have to integrate and take on the burden of maintaining two native SDK's for it.
Is there any way that Google can whitelist our OAuth key to continue to use the existing in-app auth as our use-case does not fit into Google’s primary objective for this change?
Related
I'm new to android enterprise development world, and I have some misconception of how different pieces in the android enterprise ecosystem relate to one another. Let me explain.
The solution that I'm trying to achieve is being able to lock the device into kiosk mode both remotely, and also based on some business logic do it even when the user is offline. I started investigating EMM and particularly Android Management API to solve the problem. I was able to lock the device remotely into kiosk mode using the API. The steps that I take is following
Factory reset the android device
Reach the screen where user needs to enter their credentials
Instead of real credentials I enter afw#setup
Device enters into work profile mode and android device policy is being installed
I create an enrollment token in the management API (the steps for that are described in the quick start guide
I generate a QR code and scan it using the factory reset device as soon as I'm prompted
The device will be linked to the enterprise, and I'm successfully being able to control it and put the device into kiosk mode by creating special kiosk mode policy and patching the device to comply to that policy using a combination of patch policy (to create a policy) and patch device APIs.
The next step was finding out a way to lock the device into kiosk mode even when user is offline. I assume that it's going to happen by creating an android enterprise custom DPC (device policy controller) application. I assumed that by reading the following documentation, where one of the 3 ways of provisioning "single purpose" devices is creating a custom DPC application. Here's another quote from different url
As an EMM, you develop a DPC app that can be used by your customers in conjunction with your EMM console and server. Your customer deploys the DPC to the user devices that they manage. The DPC acts as the bridge between your EMM console (and server) and the device. An admin uses the EMM console to perform a range of tasks, including configuring device settings and apps.
And here's where all of my confusions arise.
First question that naturally arises - was the author of the previous quote referring to EMM management API when talking about EMM console and server?
Further, there are more questions that I couldn't find an answer to
In the guide for creating a custom DPC there are no mentions about what role EMM API will play in custom DPC, and consequently there's no place I could find that describes how exactly the custom DPC is a bridge between the EMM console (presumably EMM API) and the device?
Then, let's assume I've developed a custom DPC application and uploaded it to google play alpha channel. The documentation states that during the setup process instead of entering afw#setup I should enter afw#DPC_NAME, and I have no idea how to generate that name? Is it the bundle ID of the DPC app? Or perhaps it's being set somewhere in google settings? For instance, google has developed the TestDPC application to test enterprise solutions, and I was able to go through the steps I described above and enter afw#testdpc and successfully scanned the QR code in the git readme file and I saw that TestDPC was installed and device was launched into work profile mode. So, I assume somehow I need to register my own "testdpc" and enter afw#my_dpc instead.
Basically I have different pieces working stand alone and I want to form a broader picture in my mind to understand how to stitch those pieces together.
Thanks for your answers
UPDATE 1:
Today I found a way of turning custom DPC into device owner without going through NFC or other provisioning process. This is particularly useful for development purposes. Follow this link for instructions.This is both huge time saver, and also, in my case, we still are waiting for google's approval, but finally we can start testing some stuff without the need of custom provisioning process.
There are two distinct ways of managing Android devices:
The new way: the Android Management API. It is the way recommended by Google and it's significantly simpler than the old way, you don't need to call other APIs or to create a custom DPC. If your use case is not addressed by this API you can send feedback to Google so they can add the missing features.
The old way (no longer available for new deployments as of 2019-12-20): using custom DPC. For that you need to:
create a custom DPC,
register your custom DPC with Google by joining the EMM Community (this is how you get the afw#DPC_NAME),
use the Google Play EMM API to install apps.
In the documentation you - the developer using these APIs - are referred as "the EMM". "EMM server" refers to the server that you own and that calls these API, and "EMM console" refers to the UI console that you expose to your IT admins, if any.
https://developer.android.com/work/dpc/build-dpc
Caution: Android Enterprise is no longer accepting new registrations
for custom device policy controllers (DPCs). Learn more.
Hi #Fred,
I found this above information from the mentioned path.
I have some questions regarding the above conversation.
If we use Android management API to develop EMM, we don't need to implement Custom DPC app?
Whether we can register a account in EMM community with Custom DPC app?
Is it possible to use a custom DPC app with Android management API?
I have been recently looking into the google home hardware and would like to build an assistant app that communicates between the google home hardware and an app on the users device, so far what I have been able to find is that an assistant app can be built that works with a webhook to a backend but not directly to an app on the device which is what I want, is this possible or has this capability not been added as of yet?
Such a feature does not exist, nor is it really likely to exist in the future in the way you describe. Google Home is just one device that supports the Google Assistant, and many of these others have other setup and linking abilities and requirements.
You don't indicate what your use case is, but it sounds like you might want to investigate Account Linking which will let your Action key data (such as commands) against your user's account id. You can then use something like Firebase Database or Firebase Cloud Messaging to update data or trigger an event in your app.
Im developing an android application for the first time (no prior experience whit coding....). Mainly the app is going to be used at work as a tool for service technicians. The app is almost ready for field testing, but there is one thing i need the app to do before that. I need the app to force the user to log in every time its opened. This is because some of the info on the app is confidential, and only people that currently works for the company is allowed to have this info. Whit firebase i can then block the users that leave the company, or users that are not verified. Currently the users sign in whit google and they stay signed in until they clear the app data or delete it.
I have looked far and wide for the answer to this, but i have only come across different use of timers.
If anyone has a better solution to this "safety" issue, im open to anything.
If you are using Google Sign-In for authentication, there is no out of the box support for forcing your user to authenticate with Google every time they use your app.
This makes sense, because the user is still authed with Google on your phone. A login system only authenticates the user; it doesn't inherently protect data stored on the device. As long as Google has a valid access token, the user won't have to type a username and password again (and simply clicking "login with Google" again doesn't really provide extra protection here).
If your primary concern is blocking access to users who have left the company, you should be covered if you are using Google Apps for your company. If you disable the user's account, their access tokens should become invalid. Google Apps admins can also manually revoke access to specific apps for specific users.
If you don't use Google Apps (e.g. your users are using #gmail.com accounts or accounts from a domain outside fo your control), you might want to consider implementing a list of users allowed to access the application, and verify the current user has access by checking that list via an API call on launch.
If the goal is really protecting the confidential information in the application, you might want to take an approach similar to Android Pay in which you require your user to set and enter a PIN number to access the application. As an added benefit, you can then use that PIN to encrypt any confidential data you are storing locally.
I will suggest you take a look into shared preferences and every time when the user is back into the app you send them to the login activity.
I have an app I've built for a client that uses a custom AccountAuthenticator. It works wonderfully and it does what the client wants.
However, that is only the first app in what will be a collection of apps that will be using the same authentication manager, and this is where I'm not sure how to proceed.
I have no way of knowing which apps will be installed by any given user, or the order they may be installed. I do not what to require the user to provide their credentials for each app; that defeats the purpose of having an authentication manager.
From some initial testing it seems that just including the same code in each app will not work.
Should I do something like what is needed to use any of the google play services? Write a function that tests for the presence of an app that just does authentication stuff, and then send the user off to the market to install the app that does the authentication? Or download the apk from our own servers?
Or is there some other way that would avoid having to push the user out of the app?
I'm trying to implement the same environment than you, several applications using same account, my final approach is (I don't say it's the best way):
Have a "background" authenticator application, all normal apps will check if this app is installed, otherwise launch google play to download it.
This authenticator application will create the account using AccountManager (tutorial here) and it will not have any launcher activity, will only be launch from another applications to create the account.
Having this authenticator application, the implementation of the other ones seems easy (seen here)
We are planning to build an Android app which interacts with a web service. To save the users from the pain of the registration process we were thinking if we could just use the paired Google account of the device as the login key. After all, you cannot download the app from the market without having a Google account.
The requirement guidelines are (not hard requirements)
1) if the user accesses the service outside Android e.g. in web browser we can use the same login
2) if the user swaps the device, removes the app, etc. the data can be retrieved again when the user reinstalls the app
3) the user would not need to type username/password/password again combo when starting the app for the first time
What platform services Android offers for this? What kind of process it is to have an app paired with a Google Account? Any gotchas, like 2 week timeouts which Facebook prefers to do.
What's the relevant documentation and any tutorials?
Thanks!
1) The AccountManager (gdocs) allows to add and "use" (google) accounts on the device (Those that are listed in the settings). Go to 34:00 in the google io talk Android Pro Tips there small introduction. Actually all tips in this session are great.
2) With a SharedPreferencesBackupHelper the settings of your app will be backed up online and automatically restored after a device switch. The preferences are tied to a google account. This service is useful for small amounts of data - some preferences. The data is as secure as the google account or the device and I think it's not encrypted.
3) see 1)