Application Provider Explained
Application Provider (AP) is a broad term so I’ll start with a simple example. In the example I have a web site where I will authenticate users during login.
The most common way to authenticate users would be using usernames/password credentials. In this system I would store the credentials in a local database. These systems are frequently cracked and don’t provide much additional security.
Alternatively, I could trust third-party services like Google or Facebook to authenticate the user. But.. what if the user isn’t registered to these services or the services are shut down? What if I need strong authentication or identity assurance?
Therefore, I choose to use Mobile Signature Service (MSS). I’m an AP in MSS terminology when I’m using MSS to authenticate users.
The authentication will have three phases:
- A user enters her mobile number to login in my site.
- The site sends an authentication requests to an MSSP (MSS Provider).
- The MSSP will relay the authentication request to user’s mobile phone.
Once the user accepts the authentication with her mobile phone, the site gets an authentication response from the MSSP. On successful authentication the user will be logged into the site!
The site needs an AP account registered to the MSSP. The AP account’s credentials are used when sending authentication requests.
Check out the Methics demo to see how an AP works hands-on!
Any party that requests authentication from an MSSP is considered an AP. Typically an AP is an HTTP server, like a web site.
AP could be, well, anything that might authenticate users.
- A lock that lets certain people pass it.
- A watch that makes sure that only the owner can see the time.
- A nuclear silo that lets the president to launch missiles.
The broad definition is good because it covers all possible usages for MSS. On the downside, the broadness makes it very difficult to explain.
Often times, web sites use authentication portals. Instead of directly adding support for MSS, a site adds support for a portal. The portal supports MSS and many other authentication services. In this case the portal is an AP but the site isn’t.
So why would an AP choose MSS authentication over username/password, Google and Facebook authentication? (Of course, using all of them is possible, too.)
Everyone has a SIM card in their phone. The authentication request is sent to an applet on a SIM card. This makes the number of users that can be authenticated with MSS extremely large.
MSSPs are connected to other MSSPs, forming a decentralized network! This way AP’s authentication requests are able to reach all mobile numbers that belong to connected operators. Also, even if one MSSP stops working, the others will still work with the same API.
MSS supports a wide variety of security options allowing, for instance, strong authentication and identity assurance.