MFA Series Post 2: Possession Proof Factors
Welcome back. This is a continuation of my posts about multi-factor authentication (MFA). Last time we talked about some basic terminology around MFA. The next step is to dive a little deeper into one type of authentication factors very often used for multi-factor authentication - something-you-have factors. To make this consumable, I’ll just clarify some more terminology in this first post, and then talk more about the various factors in subsequent posts.
When you use a something-you-have factor you are showing that you have it in your possession - a possession proof. You may as a result hear these described as “possession proof factors.” You will also hear them referred to by the implementation. In this article we will discuss several types of possession proof factors and describe the relative strengths and weaknesses of each.
First, let’s clarify a little more terminology.
- Token - When used by itself, unless I say otherwise, I mean a physical hardware device. These can look like one of those credit card calculators that kids these days have never seen, like a USB flash drive, or like a cheap piece of plastic with a low resolution LCD display.
- User or Customer - This means the person who is trying to log into some account using some kind of identity and one or more authentication claims.
- Client - This is the computer or the software the user is using to log in with.
- Identity provider (IdP) - This is the service that validates the authentication claims. If you have ever logged in with Facebook, Twitter, Google, Microsoft, or more recently, Apple, you have used an identity provider.
- Relying party (RP) - The relying party is a party that relies on another service, the RP, to perform the authentication. It trusts that the IdP has done this correctly. The RP needs to perform authorization based on the identity vended by the IdP. Typically, the RP is a service provider of some sort.
- Service provider (SP) - This is the service that provides some service the user wants to use, email, shopping, whatever. The SP may be an RP using a different IdP, or it may be its own IdP, in which case the user has an account with the SP directly. Some are both. For instance. woot.com and Godaddy.com both have their own accounts in their own identity pools, but you could also log in using an IdP (Amazon in both cases, and Facebook and Google in the case of GoDaddy).
- Broker - In some systems you have a party that just acts as a middle-man (yes, like a man-in-the-middle). We can call them brokers. A broker, for instance, could collect authentication claims for a variety of IdPs and sort out which one should be used for a particular transaction. The broker does not actually validate the claims. They just collect and send them on to where they should be validated.
- Server - This is an imprecise term that I will occasionally use as a short-hand for a combination of IdP, SP, and/or RP. I.e. it either implies that both functions reside in the same service, or that I don’t care because it doesn’t matter for the point I’m trying to make.
In future posts we will look at a variety of possession proof factors and their relative advantages and disadvantages.