Just like our houses, cars, public transport, in fact almost everything in life apart from the air that we breathe (for the time being), we need to control access to computer systems and services. Access controls consist of two vital steps: authentication and authorisation.

Authentication – who are you?

Authentication is the process of confirming that you are who you say you are. In simple trustworthy world, such as when you log onto your Mac, you provide that identity in the form of your user name, and a single piece of evidence to prove it: your password. This is single-factor authentication using something that you (and you alone) know.

When you wake your iPhone 6 from sleep, you may do so using Touch ID or its four digit passcode to prove that you are the iPhone’s user. The passcode is again single-factor authentication using knowledge, but the Touch ID fingerprint is biometric data inherent to you (an inherence factor), thus a stronger form of authentication.

In both these cases, that of your Mac and your iPhone, you are physically in contact with the device at the time, so there is also the ownership factor which makes local authentication more secure.

Buying a costly item in a store using your credit or debit card, you are expected to plug your card, an ownership factor, into the reader and then enter your PIN, a knowledge factor: this provides two-factor authentication.

You should also have encountered two-factor authentication when you add a new device to the list of those from which you access the iTunes Store, for example. Because of previous problems over claims of Apple IDs being stolen, Apple now requires some types of access to undergo this more rigorous process.

Normally you will enter your Apple ID and password on the new device, then be sent a four digit passcode to your designated iPhone (or similar), which you have to enter to complete the authentication process. This uses a knowledge factor (your Apple ID password) and the passcode on your phone (proving that you have that device, an ownership factor).

Authorisation – what can you do?

Once you have authenticated, the other part of accessing any service or system is verification that you are permitted to do what you are trying to do, or authorisation. Your Mac will recognise you as that named user, and enforce the permissions for that user on what you do. If that does not include admin rights, you will be unable, for instance, to make changes to some of the locked-down system folders, unless you authenticate as an admin user.

When you are trying to make a store purchase with your card, the store’s reader communicates with your card provider’s service to determine whether you are able to proceed with that transaction, or your card is blocked because of potentially fraudulent activity, or has exceeded your limit.

Kerberos – just the ticket for networks

The processes above quickly become tiresome and open to abuse when you have to access several different services, for instance for file sharing, mail, and internal web systems, on a network. If you have a different password for each, you will be unable to remember all the passwords, and will have to write them down or store them somewhere else, perhaps in a note on your iPhone. That would present a serious security risk.

One alternative, which can be used over networks whose security is not guaranteed, is Kerberos, which has been supported in OS X Server in the past. Current versions ship with Heimdal Kerberos rather than the standard MIT implementation provided in earlier releases; details of how to set it up and administer it are here.

Kerberos requires an Authentication Server. When you log onto it through a client system, there is a series of exchanges between that client and the server, which (when successful) provides the client with a Ticket-Granting Ticket and a Session Key. Those are then used whenever you need to access a service which is overseen by Kerberos, saving you from having to log into each service individually. If you want to read full details of the messages exchanged during these interactions, they are given in Wikipedia.

Although this normally works well, it relies completely on the Kerberos Authentication Server running; if that goes down, then you cannot access any of the services controlled by Kerberos. It is also dependent on accurate timestamps, so all the clocks over the network need to be kept in close sync, or attempts to authenticate or access controlled services may fail. It is also not generally suitable for Internet-based services.

OpenID and Facebook Connect – agreeing who you are

One of the first problems with authentication and authorisation over the Internet is that there are so many users, and so many services, that when you visit a site which needs some sort of authentication, it cannot know who it is trying to authenticate.

Assuming that you (wisely) do not allow guest users, the only users who can log onto your Mac are those in its list of users. Although some Internet services, like the iTunes Store, can force every user to create an account, and perform simple checks (such as email confirmation) before an account becomes active, many sites cannot, or would prefer not to.

OpenID is a co-operative system which allows you to consolidate your online identities. Among the many services which use OpenID are Google, Yahoo!, flickr, MySpace, WordPress; Facebook Connect is an alternative system which is also popular. You will probably have already, perhaps unwittingly, used either or both of these systems: when you tried to connect to a site which required a username and password, it invited you to log onto your Google, Facebook, or other account, and then let you in on that basis.

These systems work by placing trust between the authentication mechanisms of different Internet services. That trust is not mandatory: just because you have an account with an OpenID (or other) provider does not mean that every other system which accepts OpenID must accept your authentication with that provider. In practice most sites are happy to accept large providers such as Google and Facebook, and most users find the system very convenient. Gory details of the protocol which supports OpenID are given here.

OAuth – authorisation without direct authentication

Many Internet transactions now involve three parties, not just a client (you, the user) and a server (the service you are using). This might be because you are using a third party software service or product to interact with an Internet service on which you have an account: this could be a third-party time management app which accesses your Google Calendar data, or it could be an app which helps you manage your tweets and Twitter account. Another example might be where an online trader uses a third-party payment service.

In each of these cases, it would be bad news for everyone concerned if the third-party product had to take your username and password to connect to your account on the remote service. This would expose everyone to maximum risk, and would lead to far more serious security breaches.

OAuth originated in Twitter, in response to its problem of allowing third-parties to develop apps which could access users’ Twitter accounts. Twitter still uses the original 1.0 version of OAuth (actually a fixed 1.0a at present), although most others such as Facebook and Google now use OAuth 2.0. Again the full technical details are provided in Wikipedia, but what you see is remarkably little.

The service, which the third-party app is trying to access, gives an access token to the third-party app, which allows it to interact on your behalf with the service, but only in certain ways. The third-party app or Internet service does not gain access to or handle your account password, and once again this can be used to gain authorisation to third-party websites via your Google, Facebook, or Twitter account. This is often known as the ‘three-legged flow’ or ‘OAuth dance’.

OAuth is intended to be secure for use over insecure HTTP connections, but a common criticism of OAuth 2.0 in particular is that it appears almost inherently insecure, and implementations have numerous security flaws. Thankfully exploits of significance have yet to appear.

The future is mobile?

Apple Pay is one of a new generation of two-factor authentication systems which appears robust enough to deploy into the retail jungle. In terms of authentication, it relies on the ownership factor of your iPhone or Watch, and the inherence factor of your Touch ID (or a code which enables the Watch). Authorisation for each transaction takes place with the card provider to generate a security token for the transaction, without the retailer or Apple knowing customer payment information.

It will be interesting to see how this works in practice, and whether it encourages further development of protocols for the Internet.