Redefining the application perimeter

For browser-based applications, it's easy to deal with those employees who 'have decided to pursue other career opportunities' - the enterprise either stops issuing SSO assertions to those applications or actively de-provisions that employee at the application providers (either on-prem or SaaS). For browser-based apps then, it's relatively easy for the enterprise to Turn Off Access (TOA) to the application.

If you were to draw a circle around the 'application', you'd draw it solely around the application server because that's where the data sits.

TOA to mobile native applications is more complicated - at least if the native applications have pulled data from the server and stored it locally. If you were to draw a line around the 'application' then you would need to include the corner of the device where that application stored its data.

For local-storage native applications, TOA requires the enterprise to

1. delete any data on the device
2. prevent the native application from downloading more data (via API calls)

The first requirement implies some MDM type functionality or agent on the device (equivalent to deleting the data would be delete the keys used to encrypt the data).

The second requirement can be met by either

1. deleting from the device the security tokens that the native application had been issued to authenticate its API calls (again implying MDM type functionality) or
2. leaving the OAuth tokens on the device but revoking/canceling them at the server (so they can no longer be used on API calls) or
3. ignore the tokens and deprovision the employee account at the application provider so that, even if the application presents a valid token on an API call, the authorization will fail

Given you need some level of MDM type functionality to remove any application data, it seems logical to depend on the same to delete the tokens, ie #1 above. But that presumes the tokens are available to the MDM agent. Perhaps this depends on where the tokens are stored, eg keyStore or not??

Simply revoking the OAuth tokens, as in #2), rather than worrying about deleting them from the device is attractive because the operation can be performed solely on the server and not the device. But revocation presumes either that a) the application providers will, on receiving an API call with a token attached, call back to the enterprise to validate that token (as necessary when the tokens are simply pointers and not self-contained objects) or b) the application supports some sort of 'revocation endpoint' at which the enterprise can actively push 'kill token' messages (for which there is currently no standard).

SCIM provides a protocol by which #3 can occur. But active de-provisioning does presume that the application provider supports SCIM (or a proprietary equivalent). Even if the tokens are deleted or revoked, the enterprise will likely want to deprovision the employee account if possible to ensure they don't continue to pay for it.

Local-storage native applications, whether used on BYOD or corporate owned devices, change the application perimeter, and so change the requirements for dealing with ex's.