Inspired by a customer conversation, and mindful that ( some of ) my Ping colleagues take great enjoyment from my taxonomizing, I describe here the different permutations by which an enterprise employee can be authenticated when using the native mobile application client of a SaaS email provider (instead of a browser interface).
Editor's note: while discussed in the context of an email application, the patterns are in general also applicable to any native application client of a SaaS API.
The different options can be characterized this way:
Which entity issued (and will subsequently validate) the password used for authenticating the employee - the enterprise or the email provider?
How that password is used, i.e. where does the employee type it in - an enterprise login page, an email provider login page, or directly into the native email application UI?
The resulting combinations have very different security characteristics, discussed below.
1. Enterprise password presented to enterprise log-in page
This is the ideal from a security point-of-view; the employee continues to use only their existing enterprise password, and presents that password only to the enterprise itself. But if the actual authentication happens at the enterprise, then the fact of that event needs to be communicated to the email provider - this requirement is satisfied by SAML SSO.
The scenario is show below:
The interaction between the email application on the phone and the email provider is shown as happening via OAuth. Strictly speaking (and especially if the email provider builds their own native app) this is not necessary.
This scenario is attractive because:
The employee has no new email-specific password to remember.
The employee presents their enterprise password only to the enterprise.
It opens the door for an authentication stronger than password-based, ie something like FIDO
Note that the SAML SSO step need happen only infrequently (based on enterprise policy) because the token(s) issued down to the native email client can have a long lifetime. One consequence of long-lived tokens is that, should the enterprise wish to cut off access to the employee's email, they must actively reach out and delete the corresponding account at the email provider - using System for Cross-Domain Identity Management (SCIM) or equivalent for de- provisioning.
2. Enterprise password presented to SaaS log-in page
Instead of relying on SAML SSO as the means of authenticating the employee to the email provider, the email provider could collect the employee's enterprise credential itself, and then validate that password with the enterprise.
This is shown below:
While the employee need not remember a new password specific to email, the email provider will know the employee's enterprise password, and could misuse it if ever inclined.
The above presumes that the IMAP exchange between the email app and the email provider is authenticated by OAuth tokens, rather than passwords (the current reality). Google led some work in 2010 defining just such a binding but it's not clear if that has progressed.
3. Enterprise password presented to email app
The above scenario had the employee present their enterprise password to the email provider in a web page (with attendant security issues). Less desirable is to have the employee present their enterprise password directly to the email application - which is then validated back at the enterprise after being handed up to the email server.
This scenario is shown below:
While this scenario leverages the existing enterprise password, it does so at the cost of having the employee share it with the email application - setting a possible precedent in the employee's mind that could be leveraged as part of a Phishing attack.
A variant of the above would have the email app store the enterprise password, and use that on the IMAP calls, rather than a token issued off the password. As for above, the email provider would validate that password at the enterprise. This scenario is to horrible to even contemplate and I'll not mention it again.
4. SaaS password presented to enterprise log-in page
Any taxonomy inevitably has some nonsensical corners and this scenario is one such - as it implies the employee be issued an email provider specific password, but present it to their enterprise for subsequent validation at the email provider. Which is crazy.
Let's move on.
5. SaaS password presented to SaaS log-in page
This scenario is shown below:
The above of course implies that the employee be issued (and must remember) a new password specific to the email provider.
SCIM supports the provisioning call by which the enterprise would manage the password at the email provider.
As before, the above presumes that IMAP has been tokenized, i.e. OAuth tokens (or equivalent) can be used in place of the email password itself.
Revocation would require the enterprise actively delete the email provider account (or equivalent, change the password) with a SCIM delete user call (or proprietary equivalent).
6. SaaS password presented to email app
If, instead of presenting the email specific password to the email provider in a log-in page, the employee presented the password directly to the email app, we end up to the scenario shown below:
As for the previous scenario, the enterprise pushes a password over to the email provider in an a priori provisioning step.
Although the employee will have a new password, it's likely that they would initially provide it to the email app and never see it again. Once exchanged for a token(s), the email application would not store the password (or hopefully wouldn't).
A variant of the above would have the email application present the password on each and every call to the email provider to retrieve mail, rather than an equivalent token.
While far from ideal, this scenario is the current reality. This is, for instance, how Ping employees access Gmail using third-party email apps (like Thunderbird on Android). Google's own Gmail app supports a model more like the first.
The above is summarized graphically as:
Where the color-coding represents (my) assessment of how optimal the authentication model is - green being good, red equals bad, and orange in the middle.