Federation and Single Sign-On are used across almost every organisation. It manages and maps identities across Identity Providers (IdP) and the resources, allowing employees to access various resources throughout the network by signing in once.

There are many standards which are being used for implementing these standards such as OAuth, SAML and WS-Fed. 

OAuth

OAuth is the method to perform authorization between the services without storing passwords. Let’s have a look at two of the major keys that play an important role.

Authorization key: A temporary code that the client will exchange for an access token. The code itself is obtained from the authorization server where the user gets a chance to see what the information the client is requesting, and approve or deny the request.

Access key: After a user is authorised an access key is generated for the service that the user wishes to provide access to. This access key describes what permissions the service has over the user’s information.

Elements in OAuth:

Each OAuth flow generally contains four components –

Resource Server: This is the service where the user data is stored.

Resource Owner: This is an end-user or service that owns the data on the resource server

Client: The service that wants to access your data is known as the client.

Authorization Server: The brain of OAuth, which helps facilitate the transactions.

Let’s explain OAuth with an example – Suppose you (The Resource Owner) are subscribed to an image storing site (The Client) and you want it to automatically take all your photos from your Facebook (The Resource Server) profile and store it in its server. You trigger an OAuth flow between the image site and Facebook. This would redirect you to a Facebook page where you authenticate yourself (If required) via the Authentication Server. You then set the permission that the image service can access your images but not post on your behalf on your Facebook profile.. After you set these and click accept, the Authorization server provides an Access Key to the client for usage while accessing the information. This not only secures the flow but involves no exchange of user credentials.OAuth has different flow types which can be used based on the requirements and feasibility. This example is based on the implicit grant flow.

Do note OAuth has two specifications OAuth 1.0 and 2.0 and when we say OAuth we mean OAuth 2.0. Another key point to note is that the 2.0 specification is not backwards compatible with the 1.0 specification.

OAuth 2.0

OAuth 2.0 though serves the same purpose as OAuth but the mechanism is different and has also become the most commonly used OAuth protocol. 

Below mentioned are commonly used types of grant flow that are possible in OAuth 2.0:

Authorization grant flow: In this type, the communication between the client application and the Authorization server takes place through a back channel communication, making it secure and less prone to attacks which arise from vulnerabilities in the user agent’s browser.

Implicit grant flow: This is an easier implementation of the protocol which uses the user agent’s browser throughout the communication. However, it is prone to a number of attacks involving a compromised user’s network. This is used when  the client application is hosted on a local server.

OAuth 2.0 like any other federation protocol is also just a framework to provide communication between the parties involved. It is up to the developers to build it effectively utilising all relevant parameters and the precise combinations of those, in order to make it secure.

The above diagrams represent the flow of requests and responses which contain particular parameters , some optional and some compulsory, according to the  framework. Some of the important parameters are:

• In the Authorization request (Step 2):
  • “client_id” for identification of client application
  • “redirect_uri” for destination for authorization code
  • “response_type” determining what is requested by the client application:
  • In the Authorization grant type, an authorization code is requested as the response type.
  • In the implicit type, a token is requested as a response.
  • “scope” is used to specify the subset of user data that the client application wants to access.
  • “state” stores the value associated with the Session between the user agent and the client application.
• In the Access token request (Step 5 in figure 1):
  • “client_secret ” is the secret key provided by the client application to authenticate itself to the OAuth service.
  • “grant_type” is the same as the “response_type” but is sent again as the endpoint in the OAuth is now at /token.
  • “code” is the authorization code obtained from step 4.

The OAuth 2.0 grant can be determined by analysing the GET and POST requests as well as the destination of the request (/authorise, /token). For example, the value of response_type will be different in both cases. 

Vulnerability Assessment of OAuth Server or Identity Provider(IdP): 

There can be a number of misconfigurations on the OAuth Server leading to session hijacking and data breach. Some of them are:

Leaking authorization codes to external sources and not checking for consistent redirect_uri used.

While the client application sends an authorization request to the OAuth Server (checks the validity using client_id), this request can be intercepted to get the authorization code as a response by the attacker. Once an authorization code is given, one can use it to hijack the session previously formed between the victim and the authorization server.This happens when the OAuth provider doesn’t check the redirect_uri mentioned during the Authorization request and the one used during Access Token request. The access token request can’t be manipulated as it does not happen through the user’s browser.

Prevention: The redirect_uri should either be whitelisted or checked at every stage to avoid a fake client application server and client authentication should be enabled wherever possible.

Flawed redirect_uri validation:

If the request_uri is vulnerable to directory traversal, it will get past the OAuth Server verification. The directory traversal may lead to redirects to resources that are present in the client application server (redirect_uri). If there is some vulnerability (like XSS, HTML injection or open redirect) there which can lead to the stored access tokens or authorization codes, the above discussed attacks can be performed.

Prevention: The redirect_uri should either be whitelisted and should not be prone to directory traversal or any other vulnerability to prevent this attack

Information Disclosure

Scope parameter in the initial authorization request, defines what information the client application needs to log-in the user. The value of this scope parameter has to be validated carefully, otherwise may lead to information disclosure. This can be done in both the grant type:

Authorization grant type: If the client applications are not validated properly by the OAuth service, then a fake client application can be registered and used for gaining information about the user beyond what has been authorised by the user by manipulating the scope parameter.

Implicit grant type: As the communication is done through the user’s browser, the scope parameter can be easily manipulated at any stage , given that the user browser is compromised.

Prevention:  Prevention from this attack is done by verifying the scope of the authorization and monitoring it constantly.

Misconfiguration

There is another misconfiguration possible. The normal login (login with email option) and the social login accounts should be matched and recorded simultaneously so that two users don’t end up accessing the same account. This attack is possible only when Email verification is not done while signing-up.

Email verification should be done, so that accounts can’t be created with somebody else’s email address. Existing accounts should be verified and maintained simultaneously for both the “login with email” and “social account login”.

There are many such functionalities and parameters that need to be handled carefully both on the client application side and the OAuth service side in order to avoid the attacks even if the user agent’s device or browser is compromised.

How can we help?

Any of the frameworks would just provide a medium to communicate between the parties, but to make it a secure one, is the organisation’s responsibility. With a trusted partner like SecurDI that has years of experience in this space, we can help you strategize and design the appropriate OAuth flows and the necessary implementation details, for your organizational needs using leading enterprise tools. Our seasoned professionals can help you choose the right technologies and vendors from the many standards and vendors out there, all providing the functionality of federation and SSO, for your targeted needs to ensure you are successful in your digital journey.