What is Single Sign-On (SSO) and what do we use it for?

SSO: What it is and what do we use it for?

Single sign-on (SSO) is an authorization scheme that allows users to use a single login to access or log in to multiple independent software systems.

What is Single Sign-On?

SSO is a session and user authorization service that permits users to use one set of login credentials (username and password), to access multiple independent applications. In other words, it provides authorization between multiple services. It falls under the Federated Identity Management (FIM) approach that provides a framework where a separate SSO policy server takes care of the login procedure and sends the third-party service information about the user without exposing the user's password.

How Open Authorization (OAuth) works

Open Authorization (OAuth) is the standardized and most commonly used SSO service today or more precisely delegated authorization framework. OAuth acts as an intermediary on behalf of the end user by providing the service with an access token that authorizes specific account information to be shared with a third-party service. When a user attempts to access a third-party application, it will send a request to the SSO provider for authentication. The SSO provider then authenticates the user and sends the authentication token and user information without the password back to the third-party application, which then logs in to the user.

The OAuth framework defines four major roles that interact to achieve the delegated authorization:

• Resource Owner - Is the user or a system that owns the protected resources and can grant access to them.
• Client - Is the user or a system that requires access to the protected resources. The Client requires the appropriate Access Token to access the restricted resources owned by the Resource Owner.
• Authorization Server - This is the server that receives requests from Clients for Access Tokens, which it issues upon successful authentication and consent by the Resource Owners. It has an Authorization endpoint, for handling the authentication and consent of the user and a Token endpoint, for machine-to-machine communication.
• Resource Server - This is the server that hosts the protected resources from Resource Owner and can authorize the Client to access the requested resources. It accepts and validates the requests based on the Client's Access Token and returns the appropriate resources to the Client.

OAuth has the following general operation procedure:

1. The Client initiates the OAuth authorization procedure by sending the request to Resource Owner to access at least some of its protected resources.
2. The Resource Owner provides the Client with a grant to access the requested data.
3. The Client sends the received grant to the Authorization Server.
4. The Authorization Server authorizes and verifies the grant and sends the Access Token for accessing the protected resources back to the Client.
5. The Client sends the Access Token to the Resource Server to request the protected resources.
6. The Resource Server sends the requested data to the Client.

More specifically, we have Tokens and Scopes, where the Token defines the permission of access authorization and the Scope defines what the authorized Client can do with the access it received. The Tokens are cryptographically signed and are meaningless to any third party and contain other important information also the Scope of the Token. Scopes are defined by the Resource which conventionally has four types:

1. Read Access
2. Write Access
3. Read and Write Access
4. No Access

OAuth also defines another type of Token called Refresh Tokens and they are used to automatically obtain new Access Tokens when they expire. Refresh Tokens can be revoked and thus end the Client's access to the protected resources.

Also important is the term Grant which defines the order of operations for a Client to obtain the Access Token. And the unique ordering of the operations is called a Flow.

OAuth works over Hypertext Transfer Protocol Secure (HTTPS), which constitutes that all the communication between all the entities is done through the use of Uniform Resource Identifiers (URIs). The URIs are queries with parameters included as part of the string.

OAuth discriminates between two types of Clients, the first are Confidential, which can be trusted to securely hold the Access Token (server-to-server applications) and Public, which cannot be trusted to store the Access Token (mobile or browser applications).

The following Grants are available in the OAuth framework:

• Authorization Code Grant - The Client receives a unique code from the Authorization Server, which is then exchanged for an Access Token. The procedure is split into two steps because it enables the Authorization Server to verify the Client before actually issuing the Access Token.
• Authorization Code Grant with Public Key for Code Exchange (PKCE) Extension - The variant of Authorization Code Grant, when the Public Clients cannot be trusted to store the Access Tokes. It uses the PKCE to exchange a hash between the Client and the Server to verify that communication is not being intercepted.
• Client Credential - Is used when the Clients are requesting access for themselves and not for Resource Owners. This is normally used between machines and should only be used with Confidential Clients and must be registered in advance. The Client's request includes parameters client_id and client_secret that are verified by the Authorization Server before issuing the Access Token.
• Device Code - Is used for Clients where the keyboard input is not available or is hard to use.
• Implicit Grant - This is a simplified approach where the Access Token is returned directly to the Client. This option is not secure and deprecated, because it allows the Authorization Server to return Access Token as a parameter in the callback URI.
• Resource Owner Credentials - This Grant requires the Client to first acquire the Resource Owner's credentials which are then passed to the Authorization Server. This approach is used for Confidential Clients and its main advantage is that it does not require the redirect to the Authorization Server.
• Refresh Token - The Refresh Tokens are issued at certain periods that if the Client is authorized can be exchanged for a new Access Token.

Advantages and disadvantages of SSO

The advantages:

• Users need to remember and manage fewer usernames and passwords.
• Streamlining the process of logging in to multiple independent applications by reducing the need for reentering the usernames and passwords.
• The chance of phishing attacks is reduced.
• The network security is improved due to reduced bad users' security practices of managing multiple passwords (for example, writing passwords on pieces of paper).
• Mitigation of the risk of the third-party site access to user password, due to it not being stored or managed externally.
• Better administrative control, due to user information and passwords being stored in a single repository, where can they be easily managed (for example, once an employee leaves a company administrator can disable his access to all applications with one procedure).

The disadvantages:

• Users can become locked out of using multiple independent applications if the availability of SSO is lost.
• If unauthorized users gain access, they can gain access to multiple independent applications in just one step.
• It doesn't address the specific security levels of the application.