4 authentication use cases: Which protocol to use?

Whether you host your authentication system internally or externally, you need to select an authentication protocol carefully. The correct protocol for your use case will allow the overall system to operate securely with minimal effort and enable future expansion and compatibility with standards. In addition, if you want to make your users’ identities available to external services, it is important to consider how easy it is for these services to consume that data while keeping the process secure.

Authentication means identifying a user in some way that allows you to authorize access to resources. The protocols discussed here cover SAML 2.0, OpenID Connect (OIDC) and OAuth2. Note that OAuth2 is not an authentication protocol, but because of the popularity of its use in cases such as enabling users to sign in with a social provider such as Facebook or Amazon, it is included here.

Identity, authentication and authorization protocols

These three protocols overlap frequently in functionality:

• Identity protocols supply information about a user — such as a persistent identifier, phone or email address — that may be used for long-term identification of that user to your system and hence for authenticating the user and authorizing access to resources. SAML and OIDC are the best-known examples.
• Authentication protocols do not necessarily carry a personal identifier. For example, the Kerberos system is based on the exchange of transient anonymous keys that, in themselves, include no identification data.
• Authorization protocols, such as OAuth2 and UMA provide a means to acquire access-protected resources without requiring the resource owner to share credentials. Interactive user consent is an important aspect of these protocols. The OAuth2 protocol is often used, casually, for identity and authentication using user data, such as an identifier, returned in the OAuth2 process.

Because of their flexibility, identity protocols are increasingly used in government, enterprise and consumer areas, covering web, mobile app and desktop applications as a best-practice approach to authentication. All these protocols may be used for single sign-on (SSO) applications, bearing in mind the caveat with OAuth2.

Decentralized identities (DID)

Mention needs to be made about DID (or self–sovereign identities). This is the term for identity systems that rely on identity attributes a user stores on a mobile device and that use distributed ledger technology to verify possession of those attributes. Currently, proposals for integration of these systems with established, standard identity protocols, is ongoing, the status quo being complex custom protocols (e.g., uPort). As a result, the use of DID cannot be recommended for general identity or authentication use at this time. However, orchestration APIs, as offered from the likes of Avoco Secure, can potentially overcome this hurdle by translating to a standard protocol.

Use case examples with suggested protocols

1. IoT device and associated app

In this use case, an app uses a digital identity to control access to the app and cloud resources associated with the app — for example, an IoT device like Amazon Alexa. Alexa is used to create and account and then share data from a data store.

Protocol choices: OIDC / OAuth2 This is a simple case of authorization to access resources, so OAuth2 would be suitable, especially given its relatively simple use with smart devices, such as those without keyboards or screens.

2. A consumer identity provider (IdP)

An example of this use case would be an online bank or government service that needs to supply identity data to relying parties (RPs). The IdP holds sensitive data with the user’s attributes having been verified through know-your-customer (KYC) processes. It provides identities assured to standard levels. Only approved RPs will be able to access the IdP.

Protocol choices: SAML, OIDC Where strong security is a requirement, SAML is generally a good choice. All aspects of the exchange between the RP and IdP can be digitally signed and verified by both parties. This provides high assurance that each party is communicating with the correct counterpart and not an imposter. In addition, the assertion from the IdP may be encrypted, so that HTTPS is not the only protection against attackers accessing users’ data. To add further security, signing and encryption keys may be rotated regularly.

To take OIDC to the same level of security requires extra cryptographic keys, as in Open Banking extensions, and this can be relatively onerous to set up and maintain. However, OIDC benefits from the use of JSON and the simpler use by mobile apps, compared to SAML.

3. A health data sharing portal

In this use case, the portal needs to support multi-way data sharing of highly sensitive health data.

Protocol choices: OIDC, UMA Here, the preference will be for OIDC, as it is likely that a variety of devices, some not browser-based, might be involved, which normally rules out SAML. The built-in consent associated with OIDC enhances the privacy aspects of the data sharing. In addition, the use of signing and encryption may be used to strengthen the security aspects to a degree that adequately meets the requirements of handling such data.

4. A system supports multiple services providers within a wider ecosystem of identity services

An example of this use case would be a consortium of insurance services. The system must offer users a way to connect to the services using existing identity accounts. The user may also need to add extra data as required.

Protocol choices: OIDC, OAuth2 and SAML This example requires that the user can choose an IdP, with the aim of making it simpler for users who already have accounts on various IdPs. For example, some users might have government-issued identity; others may only have a PayPal or Amazon account.

Offering users a choice of different account types makes it easy for them to access each insurance service without first going through an online registration and verification process. The corollary is that each RP might have to support multiple protocols, as well as deal with the problem that an identity from one provider might not supply all the claims or attributes required. The solution here is to use an identity orchestration broker or proxy service that can translate to the protocol required by the RP and also deal with gathering all required attributes.