That's an interesting challenge, Mike. There are standards for machine authentication, but they assume that the machine in question is secure and can protect a secret. So when you said Android device, I immediately assume mobile device where the secrets can be got at. i.e. On an app pushed to an Android device.

If your devices are PoS and can be considered secure, then take a look at the OpenID Connect Client Credentials flow. That authenticates the machine/device, not the user. Okta supports it.

Depending on the number of machines, and the lifecycle of those machines, you would need to the configuration effort in Okta but I can easily see that automated with a process tied to you bringing a POS online or deploying to a warehouse or outlet.

The trouble we had with OAuth2 client_credentials flow was that it authorizses a client application, not an actual device. That application will be installed on all of the POS machines. Since all instances of that client application would share a client_id and client_secret, we would not be able to tell which POS device was being authorized. Since we need to support multiple merchants, we need to understand which POS belongs to which merchant. All devices and all merchantes will all have the same application installed.

The solution we have so far is to create a service account user (person in Okta) for each POS device. The username and password for this "user" will be stored as securely as possible on the Android device. We then use OAuth2 resource_owner_password flow to authorize the POS device. I do not like this solution because:

• There is no "user" really so this is a hack at best (though a common one in the industry).
• There is no real way to verify that someone didn't copy the username and password and are using them from a device that should not be allowed.

I am hoping one of these might be an option:

• Have Okta somehow verify the device. For example, if there was an Okta agent that could read and sign the Andriod Device ID we could then verify it was legitimate based on the public key. Then if anyone tries to use the username and password, but cannot provide the signed Android Device ID we would reject the request. Maybe we could use MDM for this, but the users on the device should not be able to see or modify anything about the service account "user".
• Okta supports some kind of IoT authentication. IoT would have a similar problem to this since IoT devices do not have a user context.

Any further thoughts or ideas?

Do you control the app in question ? I was thinking that you would have a deployment step that assigned the clientid/secret at build/deployment time per device. That was associated with a unique OIDC app in Okta for machine to machine giving you the device identification you're after.

MDM might be a route. As might looking at Okta behaviours ( adaptive MFA ) which would provide more controls over the service account signin policy.

https://help.okta.com/en-us/Content/Topics/Security/behavior-detection/configure-behavior-detection.htm

But still an interesting challenge. Not something Okta is setup for. I'll have a think about whether Auth0 ( Okta CIC ) might give you any other options.