Page246

OAuth

OAuth provides an authorization framework allowing a standardized means of communicating and delegating authorization to applications without requiring users to divulge their credentials. Note that the focus and purpose of OAuth is facilitating authorization, not authentication. A primary use case of OAuth involves a user enabling a client application to act on the user’s behalf, without exposing the user’s credentials to the client application. OAuth facilitates this through the use of access tokens, which the client application uses to prove that the user has approved the client application acting on behalf of the user.

OAuth 2.0 was released not long after the debut of OAuth 1.0 and addressed security deficiencies in the original specification.

OIDC (OpenID Connect)

OIDC (OpenID Connect) builds upon the OAuth 2.0 authorization framework and extends the functionality to facilitate authentication and provides an alternative to SAML for FIM or SSO implementations. As noted previously, OAuth is designed for authorization rather than authentication. For developers, the process flow for OIDC largely mirrors that of the commonly used OAuth 2.0 framework, but now it can also communicate identity and authentication details rather than just simply authorization. Whereas SAML communicates XML-formatted assertions, OIDC communicates claims via the ID Token, which is formatted using the RFC standard JWTs (JSON Web Tokens) structure.

Identity as a Service (IDaaS)

With identity being a required pre-condition to effectively manage confidentiality, integrity, and availability, obviously identity plays a key role in security. Identity as a Service (IDaaS), or cloud identity, allows organizations to leverage cloud services for identity management. The idea of leveraging public cloud services for identity management can be disconcerting. However, as with all matters of security, there are elements of cloud identity that can increase or decrease risk.

One of the most significant justifications for leveraging IDaaS stems from organizations’ continued adoption and integration of cloud-hosted applications and other public-facing third-party applications. Many of the IDaaS vendors can directly integrate with these services to allow for more streamlined identity management and single sign-on. Organizations already struggle with internal identity management and, particularly troubling, account/access revocation. These challenges are compounded when organizations must also account for publicly accessible critical applications that are leveraged by the workforce. Other commonly realized security benefits from integration with cloud identity providers include: easier deployment and integration of two-factor or multifactor authentication, self-service account management and password resets, better support for integrating mobile devices, and centralized audit capabilities.

The rather obvious security question with IDaaS concerns the potentially increased exposure to an organization’s critical identity and authentication information. With traditional on-premises identity management solutions, the enterprise exerts control over securing the platform itself. With cloud identity, if the identity provider suffers a breach, then client organizations could well be devastated as a result.

Microsoft Accounts, formerly Live ID, are an example of cloud identity increasingly found within many enterprises.

Exam Warning
On the exam, be careful not to confuse IaaS (Infrastructure as a Service, discussed in Chapter 4, Domain 3: Security Architecture and Engineering) for IDaaS (Identity as a Service).