The gradual integration of applications and services external to an organization’s domain motivated both the creation and adoption of federated identity services whose evolution continues to this day. Single sign-on (SSO), a forerunner to identity federation, was an effective solution which could manage a single set of user credentials for resources which existed within a single domain. However, the growth of high quality third party applications pushed organizations to rely on tools outside the domains they controlled and beyond the scope of SSO. Federated identities offered organizations the opportunity to preserve the benefits of SSO while extending the reach of a user’s credentials to include external resources which reduces costs and when implemented correctly, can increase security.

Three protocols employed in the majority of federated identity deployments will be examined, OpenID Connect, SAML v2.0, and OAuth 2.

OpenID Connect

OpenID Connect was launched in February of 2014 and is the current iteration of the open standard which allows users to employ a single set of credentials, managed by a preferred 3rd party OpenID Connect identity provider (IDP) such as Google, Microsoft, and PayPal, to authenticate with numerous online services. OpenID Connect has been built on top of the OAuth 2.0 protocol and employs REST/JSON for messaging. For developers, OpenID allows developers to authenticate users without creating and maintaining a local authentication system. Instead, developers can rely on the expertise of an organization committed to the secure implementation of an identity protocol capable of ensuring identities they manage are authentic and to the best of their abilities, authentic. The OpenID Connect protocol, launched in February of 2014, can be used across numerous platforms including mobile in addition to a varied array of clients such as JavaScript to produce confirmable identity assertions. (Source: http://openid.net/connect/faq/)

The OpenID Connect specification defines three roles:

  • The end user or the entity that is looking to verify its identity
  • The relying party (RP), which is the entity looking to verify the identity of the end user
  • The OpenID Connect provider (OP), which is the entity that registers the OpenID URL and can verify the end user’s identity

Final-OpenIDConnectUseCase

 

Security Considerations

1. Mix-Up Attacks, July 16, 2016

OpenID describes mix-up attacks as follows,

“Broadly, the attacks consist of using dynamic client registration, or the compromise of an OpenID Provider (OP), to trick the Relying Party (RP) into sending an authorization code to the attacker’s Token Endpoint. Once a code is stolen, an attack that involves cutting and pasting values and state in authorization requests and responses can be used to confuse the relying party into binding an authorization to the wrong user.

Many deployments of OpenID Connect (and OAuth) in which the configuration is static, and the OPs are trusted, are at greatly reduced risk of these attacks. Despite that, these suggestions are best current practices that we recommend to all deployments to improve security, with a particular emphasis on more dynamic environments.”

2. Covert Redirect, May 2014

An end-user’s authorization server could be employed in a phishing attack by an attacker who abuses the end-user’s authorization server redirect URI parameter, instead using it as an open redirector.

SAML v2.0

Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging authentication and authorization data between parties. SAML was launched in 2001 and is managed by the OASIS Security Services Technical Committee.

The SAML specification defines three roles,

  • The principal, which is typically the user looking to verify his or her identity
  • The identity provider (idP), which is the entity that is capable of verifying the identity of the end user
  • The service provider (SP), which is the entity looking to use the identity provider to verify the identity of the end user

Final-SAMLV2UseCase

 

Security Considerations

1. XML Signature wrapping (XSW), November 2011

A group of researchers presented a paper in 2011 where they used an XML Signature Wrapping vulnerability to impersonate any user.

2. HTTP Referrer Attack, August 2012

A HTTP Referrer attack occurs when a message moving between the service provider and identity provider is intercepted and its referrer is modified prompting the service provider to return the authentication response to the attacker who can then use it to authenticate with the service provider later on. Ensuring the transport layer uses SSL/TLS can mitigate the HTTP referrer attack.

3. Signature Exclusion Attack, August 2012

A signature exclusion attack relies on an application designed to accept a message whose signature element has been removed. Ensuring the authenticity and integrity of a message by designing an application which requires a signature will mitigate this attack.

OAuth 2.0

OAuth 2.0 is an open standard launched in 2006 focusing exclusively on authorization, differentiating itself from OpenID and SAML which were created for the purposes of authentication.

The OAuth 2.0 specifications define the following roles,

  • The end user or the entity that owns the resource in question
  • The resource server (OAuth Provider), which is the entity hosting the resource
  • The client (OAuth Consumer), which is the entity that is looking to consume the resource after getting authorization from the client

Final-OAuthUseCase

 

Security Considerations

1. Account Takeover Vulnerability, November 2016

In November of 2016 three researchers presented a paper at Black Hat Europe describing what was the most common OAuth 2.0 vulnerability as follows:

“The root cause of this vulnerability is a common, but misplaced trust in the authenticating information received by the 3rd party app’s backend server from its own client-side mobile app, which in turn, relies on potentially tampered information obtained from the client-side mobile app of the IdP,” the security researchers explain…..”

The researchers went on to suggest a number of precautions which could help mitigate the vulnerability including “clearer and more security-focused usage guidelines for their OAuth 2.0 based SSO APIs”. They also recommended that mobile apps which require backend servers only trust direct communications with the identity provider which would issue a private identifier per mobile app in addition to conducting more thorough mobile application security testing.

The OAuth 2.0 protocol relies on the underlying transport layer to provide confidentiality and integrity by employing technologies like SSL/TLS. Since OAuth 2.0 does not support signature, encryption, channel binding, or client verification, care must be taken in its implementation.

2. Client account hijacking through abusing session fixation on the provider

Only affects the “social login” scenarios.

  • Authentication data provided by the authorization server should not be trusted.
  • Use CSRF protection for the account linking and always request explicit consent from the end-user.

3. Account hijacking by leaking authorization code.

  • Authorization code may leak to external parties through the HTTP Referer header if there are third party components in the redirect URI page.
  • Use only small set of valid redirect URIs and do not allow embedding any third party components on those pages.

4. Leaked client credentials threat

Even though not much can be done with the leaked client credentials (make calls to access token endpoint), they should be stored in a secure manner in the server side.
If client credentials leak, they should be reset.
Tricks to bypass Redirect_uri validation
Only use explicit set of redirect URIs.

5. Replay attack

It may not be guaranteed that authorization code is one-time use. Therefore it might be feasible to build mechanism to prevent replaying authorization co

At a glance

Differentiating OpenID Connect, OAuth 2.0, and SAML

Current versionOpenID Connect (2014)OAuth 2.0SAML 2.0

OpenID Connect OAuth SAML
Dates from 2005 2006 2001
Main purpose Single sign-on for consumers
+
Identity/Auth Services
API authorization between applications Single sign-on for enterprise users
Protocols XRDS, HTTP, JSON JSON, HTTP SAM, XML, HTTP, SOAP

 

Other protocols

There are a growing number of federated identity options, here are a few examples.

Higgins

Higgins is an open source protocol that allows users to control which identity information is released to a third party. Higgins is focused on developing three areas, the first being active clients which utilize browsers across platforms including mobile. Secondly, for the Higgins 2.0 launch a personal data store (PDS) is being developed which will give its users to control the data they share. Lastly, developing a IMI and SAML compatible Identity Provider enabling IMI and OpenID compatibility.

U-Prove

U-Prove is a token based credential established in 2012 whose core specifications were released under Microsoft’s Open Specification Promise. U-Prove tokens can contain any kind of attribute, similar to public key infrastructure (PKI), yet differs in two significant ways. First, the token’s public key and signature cryptographic “wrapping” is done in a way where the attributes “contain no correlation handles making it impossible to track U-Prove tokens even in a situation where insiders might collude”. Secondly, U-Prove users have the ability to disclose only the minimum information required such as their range being within a range and not their actual age.

MicroID

MicroID is a decentralized identity layer for the web and microformats that allow anyone to claim verifiable ownership of their websites in addition to content hosted anywhere by using an identifier composed of a hashed communication and identity.

Conclusion

With the continued proliferation of hybrid systems, protocols, and countless devices federated identities have firmly entrenched themselves in our daily lives. However, the convenience promised by technologies like OAuth 2.0, SAML 2.0, and OpenID Connect necessitate that the attack surface they generate be carefully scrutinized not only during deployment but on an ongoing basis ensuring the service they provide does not become as convenient for attackers as they are for users.

References

White Paper - Proving Adherence to Software Security Best Practices

White Paper - Proving Adherence to Software Security Best Practices

Industry standards and the best practices for developing secure software. Please provide your email and name to receive your copy.

Success! Your copy is on the way.

eight-myths

The 8 New Deadly Myths of Application Security

If you want to get clear on the best strategy for software security in your organization, you must first get clear on the problems. Many organizations identify the problems as cryptography, insecure SSL practices, or authentication issues.

This is why organizations get trapped within incorrect mindsets to find themselves struggling to prove proper adherence to software security best practicesor worse, in a middle of a data breach.

Enter your name and email below to understand the myths and start an application security program that works.

You have Successfully Subscribed!