Authentication & Identity

Identity - Username/PasswordEverybody who has an online account with Facebook, Twitter, Spotify etc will know that usernames are hard to remember. Not only this, passwords are even harder to remember! Those who access their account on a phone will know that typing is annoying and recovering passwords can only be done through e-mail messages.Password databases are regularly hacked because someone accesses a certain account, they could have access to all of your personal information. Depending on what the account is, possibly banking details. But how can the concept of entering your usernames and passwords be designed to a better standard?Federated LoginWell firstly, the user could have a choice to login to service using an existing identity. For example, if you want to log on to Spotify, but you have forgotten your account details. You could use your Facebook details. This simplifies login, is much more secure due to lower amounts of passwords and you only need one identity for multiple services.Traditional usernames/passwords and Federated Login are often used together, as you can see from the second image below.

IdentityIf you're an existing user, you would identify then authenticate using the appropriate login dialogue. If you're typing an e-mail address, maybe you could use an account chooser instead?

However, the identification process is complicated. DevOps and IT managers shouldn't need to be security expert. This problem of complexity is improved, but there is still much work to be done.

User Login Expectation"Users expect to be able to instantly gain access to their online data and services through a smartphone, just like they would from their PC. In order to accomplish that level of access from a phone, two basic prerequisites need to be satisfied/"The user must be able to use their existing identities from mobile application. Services and data must be exposed in ways that are suitable to be securely consumed by mobile clients. The integration of mobiles is important, but computing has hugely gravitated to it.So what are the options in terms of identity? Firstly, you could simply create your own account. Your own username, password, token etc. ASP.NET Membership Provider and other libraries could be possible platforms.You could use a single existing identity system. This could be done through Google, Facebook etc. These are all cloud-based and they are developed directly against the IdP protocol, OAuth etc. There will more details about these protocols later.

Single Sign-On (SSO)Single Sign-On (SSO) allows end users to provide their credentials once and then obtain access to multiple resources. For example, if a user can log on to multiple services using only one Identity Provider (IdP), the services are usually related.This will reduce password fatigue and it reduces the need to develop multiple user authentication systems. Furthermore, SSO can be facilitated through a Federation Provider. More commonly, it is done through direct oAuth communication with the Identity Provider.In some instances however, the user has to enter their same password multiple times for each system. The important part of SSO is that you don't need multiple user IDs and credentials regardless of how many times you might have to enter it for each system.More people would want SSO to be a seamless experiences with no additional prompts for the same password. But this is not always an option.Often tied to SSO is fingerprint, smart card or similar. If you only have one password for everything, you will need to increase the protection on a single point of security.

Identify and AuthenticationThere are two widely used approaches to implement identity and authentication; SAML-based and OAuth Based.Security Assertion Markup Language (SAML) has been around for a while. It was first used in 2005 and is normally implemented through a web browser for enterprise authentication. This can also be a web browser frame in a mobile app, for example, the develop doesn't want his/her own logic or appearance). However, SAML didn't foresee the growth in mobile computing.Open Authorisation (oAuth) is relatively new and is better suited for mobile and web apps. It scales better and you don't need a browser window, you can instead authenticate through a series of HTTP redirects (developer owns the login logic and appearance).

Security Assertion Markup Language (SAML)Security Assertion Markup Language (SAML) is an XML-based open standard data format for exchanging authentication and authorisation data between parties, in particular, between an IdP and a Service Provider.It defines mechanisms to exchange authentication, authorisation and nonrepudiation information, allowing SSO capabilities for web services.Even though SAML was designed to be applicable openly, it is typically used in Enterprise scenarios: Within an enterprise Enterprise to partner Enterprise to cloud

Open Authorisation (oAuth)Open Authorisation (oAuth) is an open protocol to allow secure authorisation in a simple and standard method from web, mobile and desktop applications. It has been designed from scratch for use with applications on the internet.Furthermore, it enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner or by allowing the third-party application to obtain access on its own behalf.OAuth also enables server owners to authorise access to the server resources without sharing credentials. This means the user can grant access to private resources from one server to another without sharing their identity.It is primarily for delegated authorisation of internet resources, such as files and photos. It was also designed for Internet Scale, so for services such as Facebook, Dropbox, Google Apps and Microsoft 365.

Identity Providers (IdPs)Identity Providers (IdPs) are authorities that authenticate user identities, store their data and issue security tokens. Examples of these include Google, Microsoft, Yahoo, Facebook, Twitter and many more. Facebook and Twitter are commonly known as social Identity Providers, a subset of IdPs.Identity Providers have direct knowledge of users, they authenticate users by using their credentials, and issue claims to the calling service providers. Authentication is normally done directly via OAuth."Social login allows customers to quickly and easily register for, and login to, your website or mobile app using their existing social media accounts. By authenticating their identities with social login, consumers give your app permission-based access to the rich data housed in their social profiles, including their interests, relationships, locations and media preferences."

Federation Identity ProvidersA Federation Provider (FP) is a different kind of identity authority. Instead of authenticating users directly, the FP brokers authentication and it acts as an intermediary between a relying party (service or application) and one or more IdPs.It also offers a 'federation' of IdPs, each of whom (Facebook, Google etc.) all still store and manage their user's data and credentials. Federation Providers do not store any user data. They do, however, pass security tokens (from an IdP) back to your service or application for successfully authenticated users.These tokens are usually SAML-based and contain user data, aka claims. These claims can be user data such as first name, surname, email, DoB etc.

Passive and Active FederationPassive Federation is where authentication happens in a browser login window via a set of HTTP redirects, the browser login window is owned and controlled by the Federation Provider. You have no control over the login logic or the way it looks, as its handled by the Federation Provider and commonly the SAML protocol is used.Active Federation is associated with web services and clients that explicitly get authenticated, i.e. through a library or web request in code - commonly the OAuth protocol is used and there is no browser login. In Active Federation, you own the login control and logic and make calls direct to the Federation Provider's Security Token Service. In short, you can change the look and feel of the login window.

SSO is a Subset of Federated IdentityThere is a common misconception that SSO and Federated Identity are the same thing.Federated Identity is largely about architectural concepts, processes and procedures of identity. This includes the overall management of trust relationships, access control strategies, identity mapping mechanics, policies and common protocols.SSO is a subset of Federated Identity that deals specifically with reusing a single identity and login session to authenticate across multiple services. For example, logging in once and not having to login again with you credentials to access other applications.