Skip to Content

Where is the Enterprise Authentication in iOS

After Apple added Twitter authentication in iOS 5, iOS 6 will do the same for Facebook.

Bildschirmfoto 2012-06-19 um 13.57.26.png

While some may think this is just another Silicon Valley partnership thingie, I actually think it’s a big deal, even in an enterprise context. And it’s not about pressing LIKE on an app. Read on.

We recently had to discuss several password leaks from sites like LinkedIn, eHarmony and last.fm.I think everyone is perfectly clear that it’s not a good idea to either use weak passwords or re-use the same password over and over again.

But still, if you’re really really honest to yourself you’ll have to admit that you’re doing it. And probably not only once. One of the worst offenders is often the enterprise environment, where you’ll have countless passwords to manage, sometimes (always?) with incoherent password policies. The different requirements, coupled with weird change frequencies, may drive you to re-use passwords, often simple ones, to make life bearable. And insecure.

This is where the Twitter an Facebook integration come in. Both sites support an authentication method called “OAUTH” which allows you to sign into another site (which needs to implement support for OAUTH – see documentation from Twitter and Facebook) with your Twitter or Facebook credentials. Google also supports OAUTH for lots of sites.

Here’s a rough description of how it works:

  1. You arrive at a new site that offers OAUTH authentication
  2. You select your identity provider (Twitter, Facebook, Google)
  3. You’re being redirected to this site where you login and allow the identity provider to pass on your credentials to the new site
  4. The new site now has some form of credentials (like user ID or screen name) and the verification that those belong to you.

Why’s that a good thing? Let me count the ways:

  1. No need to give all your data to yet another new site. They just use what you have maintained at Twitter or Facebook (name, user ID, Avatar)
  2. NO NEED TO GIVE THEM YOUR PASSWORD! They just receive an authentication token, they’ll NEVER see your email adress or password!
  3. You control the authentication through your OAUTH provider. Check https://twitter.com/settings/applications for Twitter or https://www.facebook.com/settings?tab=applications for Facebook to check which applications already use your OAUTH credentials (it’s good practice to go through these lists every other week to see if everything in there still needs access…)
  4. You can always revoke the access token.

So, why is this a good thing in iOS specifically? Coming back to my opening paragraph, it’s quite easy to enter a long complex password _once_ in the Twitter and Facebook settings in iOS, then every iOS app supporting OAUTH should be able to ask for your permission without you having to re-enter a password. This makes it A LOT easier to sustain good passwords. If every new app requires you to manually type in a password you’ll be tempted to resort to something you can easily remember, which is kinda counter-productive.

And the enterprise implications? Sorry, we’re not there yet. One reason is that your employer will probably not allow you to loginn to your ERP system using your Facebook login. But what if a more enterprisey OAUTH provider allowed you to do that? With the growing number of mobile applications that might be an important mechanism to secure authentication for mobile enterprise services.

What is your experience with mobile apps and passwords? Are you already using the integrated OAUTH mechanisms? What if you could login to SCN with your Twitter ID? (just thinking…)

/
Bildschirmfoto 2012-06-19 um 13.57.26.png
6 Comments
You must be Logged on to comment or reply to a post.
  • Hi Frank,

    Excellent explanation of oAuth.

    And by enterpisey oAuth, you mean Single Sign On and SAML?

    The risk is of course that, if hackers manage to steal passwords from twitter, they can access all the other applications which rely on twitter oAuth.

    Granted, if you use the same password over and over, the risk of someone stealing it becomes bigger, because it’s stored on multiple servers. But at least, then they don’t have a list of applications that use the same pass.

    Difficult trade-off.

    I use twitter/google authentication myself whenever it’s enabled. I just hope they never lose passwords like LinkedIn did. Fortunately, I have a strong password. To that extent even that Windows gave me a warning that older versions might not cope with it.

    • Thanks Tom!

      It’s all a matter of risk mitigation. The most secure option would be hardware tokens everywhere, but in absence of that we’re stuck with passwords.

      In the event of a breach (which should be easy enough to prevent for a service…) the risk is with the weak passwords which are re-used. Thus, the best short term mitigation is to make people use stronger passwords, and not re-use them. To achieve this this would be a great help.

      For mobile apps OAUTH providers could even enhance the process by making use of hardware tokens in mobile devices, such as adding hardware identifiers to the password as an additional level of protection.

      In an enterprise context an OAUTH provider could add a certificate or something similar to the user credentials to make the data trustworthy to third parties. A trusted OAUTH provider could add cross-company identification.

      It’s just a matter of someone stepping up to the task.

  • Didn’t the old SCN operate as an OAUTH provider? I’m sure I’ve used it that way in the past. I can’t find any evidence of this now, and certainly the new one doesn’t seem to provide that functionality. Am I dreaming?

    I wonder if Enterprises would actually allow this, given an enterprisey oauth provider. And I wonder if anybody would want to be such a provider. Just think of the implications if something went wrong. Would any organisation want to take on that risk?

    The Windows 8 pre-releases I’ve used have wanted to use my Windows Live ID instead of creating a separate local account. Perhaps this is the start of your oauth utopia 🙂

    • Maybe Darren Hague can say something to OAUTH in SCN?

      You’re right, Apple also asks you to login with your AppleID.

      Maybe you can allow users to set up links to their internal ID from an OAUTH provider, or you can act as an OAUTH provider yourself. In any case, it’s probably better than having users use weak passwords on mobile devices.

      Not sure it’s Utopia, this is being used in lots of places already. Some of which require quite a high degree of trust.

      • SCN can operate as an OpenID provider, not OAuth. Bear in mind that OAuth is about delegating control as much as it is about authentication.

        Think about your passport as an analogy: using SAML or OpenID, you are “showing your passport” to a remote site which trusts your provider, and will then let you in.

        With OAuth, you are *giving your passport* to the remote site, allowing them to act on your behalf when dealing with your provider. Admittedly you can restrict which permissions you give them, but OAuth is still a stronger concept than mere authentication – it delegates authorization too.

        That said, OAuth is something we are considering for implementation in the SAP ID Service (our central authentication provider for SCN, SAP.com and cloud services) precisely so that mobile devices and other non-web clients can benefit from our enterprise-grade authentication service.

        • OpenID! It was OpenID, not OAUTH. Of course it was. Doh!

          And I do like the idea of SAP SSO supporting OAUTH, especially if there’s a way of using it with other services.