Related: 
- [a-5.17-Authentication-information](../Standards/ISO27x/OST/27002/EN/a-5.17-Authentication-information.md)
- [Single Sign On (SSO)](Single%20Sign%20On%20(SSO).md)

## Types of Single Sign On (SSO) Authentication

### **Enterprise Single Sign On (E-SSO)**

Enterprise SSOs are implemented in **enterprise application integration** (EAI) environments. Therefore, with a single set of sign-in credentials, users are allowed to access all integrated applications within an enterprise, whether they exist **on premise** or **on the** [**cloud**](https://www.chakray.com/top-5-cloud-programming-languages/). 

### **Web single sign-on (Web-SSO)**

This solution is ideal for applications that can be accessed through the web, such as websites or web services. Its goal is to verify a user’s identity on multiple applications at once without the person having to identify themselves repeatedly. It relies on an external or third-party authentication system.  

A proxy SSO server running the authentication system handles access data and performs the confirmation of user identity. Then, it transfers the result to the computer running the web service or website that requested it. The SSO server and web service communicate via tokens in a way that is mostly invisible to the user. When the user is attempting to sign on to the website or web service, the authentication system generates a **global token** and sends the value to the user. Consequently, the user can enter the global token into the website, which in turn corroborates the value with the authentication system to ensure the user’s identity before granting them access. If the user is already signed in to the authentication system, the SSO server transmits their credentials along with a **local token** to the website, signifying a successful login. 

### **Federated identity**

Federated Identity Management (FIM) or federated SSO broadens the scope of standard SSO technologies by uniting multiple organisations under one authentication system. While traditional SSO allows access to several systems within one enterprise, FIM allows access to several systems within **many different enterprises**. However, both methods authenticate the user through one identity. 

### **Open ID**

A decentralised approach to SSO technologies, Open ID functions on the concept of a **relying party** (RP) and an **identity provider** (IDP). The RP is the website or service that wishes to authenticate the user, whilst the IDP performs the authorisation by recording the user’s chosen identity (which is portrayed through a URL identifier called an OpenID). The multipoint interactions between the user, RP, and IDP occur through a user-agent like a browser. 

### **OAuth**

OAuth is not one particular technology, but rather a standard that is available for all to implement. It functions on the principle of **Access Tokens** and can help realise SSO. A client or user interacts with an **Authorisation Server** to receive an access token that would help them validate their identity with a **Resource Server**. Resource servers are in charge of delegating a resource to an authorised client.  

### **Kerberos-based SSO**

This protocol allows users (the client) to utilise a **t****icket-granting ticket** or **Ticket to Get Tickets** (TGT) after the verification of their credentials. A TGT is swapped for a **service ticket** from the **ticket-granting service** (TGS). Service tickets permit the user access to protected services over the network (for example, a mail server). 

### **Smart-card Authentication**

Instead of implementing software to authenticate the same set of credentials such as in conventional SSO processes, hardware devices like the smart-card can be used to achieve similar results. 

### **Security Assertion Markup Language** 

SAML is an open standard based on XML that can empower SSO implementations. It consists of two parts, namely the SAML identity provider (IdP) and the [SAML](https://www.chakray.com/wso2-identity-server-integration-spring-boot-security-saml/) service provider (SP). Initially, the principal or the user requests to connect to the SP. In turn, the SP asks the IdP for an **authentication assertion**. Once this is issued, the SP delivers the service needed by the user or decides to opt out of it.