9 OpenID and OAuth
OpenID is an open standard and decentralized authentication protocol, works in a way similar to SSO authentication system. It allows users to be authenticated by co-operating sites, known as Relying Parties (RP), using a third-party service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log into multiple unrelated websites without having to have a separate identity and password for each. Users create accounts by selecting an OpenID identity provider, and then use those accounts to sign onto any website that accepts OpenID authentication. Many websites including Microsoft, Google, AOL, and Amazon have integrated OpenID consumer support.
The OpenID standard provides a framework for the communication that must take place between the identity provider and the RP. An extension to the standard facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the RP. The OpenID protocol does not rely on a central authority to authenticate a user’s identity. Moreover, neither services nor the OpenID standard may mandate any specific means by which to authenticate users. It can support commonly used password mechanisms as well as smart cards or biometrics.
An end-user is the entity that wants to assert a particular identity. A RP is a web site or application that wants to verify the end-user’s identifier. An OpenID provider (OP) is a service that specializes in registering OpenID URLs or XRIs. OpenID enables an end-user to communicate with a relying party. This communication is done through the exchange of an identifier or OpenID, which is the URL or XRI chosen by the end-user to name the end-user’s identity. An identity provider provides the OpenID authentication.
An end-user typically registers with an OpenID provider (e.g. openid.example.org). Then the end-user interacts with a RP that provides an option to specify an OpenID for the purposes of authentication. There are two modes in which the RP may communicate with the OpenID provider. The “checkid_immediate” mode does not require the OpenID provider to interact with the end-user. All communication is relayed through the end-user’s user-agent without explicitly notifying the end-user. The second “checkid_setup” mode requires that the end-user authenticate directly with the OpenID provider via the end-user’s user-agent used to access the RP. The method of authentication may vary, but typically, an OpenID provider prompts the end-user for a password or some cryptographic token, and then asks whether the end-user trusts the RP to receive the necessary identity details. If the end-user declines the OpenID provider’s request to trust the RP, the authentication is rejected. If the end-user accepts the OpenID provider’s request to trust the RP, then the user-agent is redirected back to the RP along with the end-user’s credentials. If the RP and OpenID provider have established a shared secret, then the RP can validate the identity of the OpenID provider by comparing its copy of the shared secret against the one received along with the end-user’s credentials. After the OpenID has been verified, authentication is considered successful and the end-user is considered logged into the RP. The RP typically then stores the end-user’s OpenID along with the end-user’s other session information.
The OpenID has security weaknesses and may prove vulnerable to phishing attacks. For example, a malicious relying party may forward the end-user to a bogus identity provider authentication page asking that end-user to input their credentials. On completion of this, the malicious party could then have access to the end-user’s account with the identity provider, and then use that end-user’s OpenID to log into other services. In an attempt to combat possible phishing attacks some OpenID providers mandate that the end-user needs to be authenticated with them prior to an attempt to authenticate with the RP.
OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. This mechanism is used by companies such as Amazon, Google, Facebook, Microsoft and Twitter to permit the users to share information about their accounts with third party applications or websites. The standard OAuth 2.0 Authorization Framework is defined in RFC 6749 .
The client requests an access to protected resource on the server by using the resource owner’s credentials. To facilitate access to restricted resources, the resource owner is required to share its credentials with the third party. This creates several problems and limitations. The credential is a password in clear text needed to be stored in third-party applications and to be supported by the server creating a security vulnerability. Resource owners can neither restrict nor revoke access to third-party. OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to protected resources is issued a different set of credentials, called access token – a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server. OAuth 2.0 is the industry-standard protocol for authorization described in RFC 6749 .
OAuth is an authorization protocol, rather than an authentication protocol. Using OAuth on its own as an authentication method may be referred to as pseudo-authentication.
The communication flow in both processes is similar:
1. The user requests a website login from the application.
2. The website formulates a request for the identity provider, encodes it, and sends it to the user as part of a redirect URL.
3. The user’s browser requests the redirect URL for the identity provider, including the application’s request. The identity provider authenticates the user by requesting users’ credentials. After successful authentication, it processes the application’s request, formulates a response, and sends that back to the user along with a redirect URL back to the application.
4. The user’s browser requests the redirect URL that goes back to the application, including the identity provider’s response. The application decodes the identity provider’s response, and carries on accordingly.
The crucial difference is that in the OpenID authentication use case, the response from the identity provider is an assertion of identity; while in the OAuth authorization use case, the response from the identity provider is an access token that may grant the application ongoing access to some of the identity provider’s APIs, on the user’s behalf. The access token acts as a kind of “valet key” that the application can include with its requests to the identity provider, which prove that it has permission from the user to access those APIs. Because the identity provider typically, but not always, authenticates the user as part of the process of granting an OAuth access token, it’s tempting to view a successful OAuth access token request as an authentication method itself.
However, because OAuth was not designed with this use case in mind, making this assumption can lead to major security flaws.
Similar to OpenID, the most devastating OAuth security failure is phishing vulnerability. An attacker website can visually seem as a genuine website to steal credentials from unsuspecting users.
10 Authentication for Cloud Computing
Cloud computing and storage provides users with capabilities to store and process their data in third-party data centers. It provides on-demand availability of services such as software, platform, and infrastructure through Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS). This involves using of shared infrastructure and rapid movement of servers and workload within the infrastructure.
Because of the structure of Cloud computing, both the security issues faced at cloud service provider and security issues faced by cloud customers need to be taken into account.
As cloud service providers often store more than one customer’s data on the same server, it is possible that one user’s private data can be viewed by other users. The extensive use of virtualization in implementing cloud infrastructure brings unique security concerns for the customers of a public cloud service. The underlying components of cloud infrastructure may not be designed to offer strong isolation properties for a multi-tenant architecture. A virtualization hypervisor mediates access between guest operating systems and the physical compute resources. However, any flaw in hypervisors enable guest operating systems to gain inappropriate levels of control leading to compromise. The cloud service provider should ensure proper data isolation, logical storage segregation and that the virtualization must be properly configured, managed and secured. Strong compartmentalization should be employed to ensure that individual customers do not impact the operations of other tenants running on the same cloud provider.
When an organization opts to use cloud storage, potentially sensitive customer data is at risk from insider attacks. The cloud service provider promotes his service by simplifying registration process and offering free limited trial periods. By abusing the relative anonymity behind these registration and usage models, spammers, malicious code authors, and other criminals have been able to break into PaaS and IaaS services.
The cloud users must take measures to safeguard their application and use strong passwords and authentication measures. Strong authentication of cloud users makes it less likely that unauthorized users can access cloud systems, and more likely that cloud users are positively identified. Cloud Computing providers expose a set Application Programming Interface (APIs) that the customers can use to provision, manage, orchestrate and interact with cloud services. The security and availability of general cloud services is dependent upon the security of these basic APIs. These interfaces must be designed to protect against both accidental and malicious attempts to circumvent policy.
It is generally recommended that information security controls be selected and implemented according and in proportion to the risks, typically by assessing the threats, vulnerabilities and impacts. Cloud Access Security Broker (CASB) is a software that sits between cloud users and cloud applications to provide visibility into cloud application usage, data protection and governance to monitor all activity and enforce security policies. It is either on-premises or cloud based software that sits between cloud service users and cloud applications, and monitors all activity and enforces security policies.
A survey of authentication methods used in cloud environment is given in . One type of authentication based on cryptographic techniques need a trusted third party using tickets or certificates based on Kerberos or PKI system. The user profile type makes use of either biometrics-based or behavior-based system. Biometrics include finger prints, retinal scan and face recognition methods. Behavioral methods involves handwriting and keystroke based authentication. The biometric data is linked to the confidential information of the users and stored in an encrypted fashion. Making use of a searchable encryption technique, biometric identification is performed in encrypted domain to make sure that the cloud provider or potential attackers do not gain access to any sensitive data or even the contents of the individual queries. Typically, every enterprise will have its own identity management system infrastructure. Cloud providers can integrate the customer’s identity management system into their own infrastructure, using federation or SSO technology or a biometric-based identification system.