Securing the perimeter – SAML vs OAuth2

At a time when security breaches result in increasingly severe penalties, it is important that application developers and owners understand identity management and the value it provides when building applications. 

Wisdom is not a product of schooling but of the lifelong attempt to acquire it.—Albert Einstein

• Identity management, authentication, and authorization approaches have evolved over time.
• Early approaches often involved application-specific identities and credentials.
• Centralization of identity data with directory services enabled a single identity and credential, but this had to be entered by a user into each application (in the absence of other complementary technology).
• Single sign-on servers provided session management so users could log in once and access multiple applications, within the same domain, with one authentication.
• SAML 2.0 and WS-Fed provided single sign-on and federated identity across domains.
• OAuth 2.0 provides a solution for authorizing applications to call APIs.
• OIDC provides a layer on top of OAuth 2.0 for authenticating users and returning information to applications in a standard format about the authenticated user.

SAML 2.0

The explosion of new SaaS applications created challenges for managing identities.With SAML 2.0, SaaS applications could redirect corporate users back to a corporate authentication service, known as an identity provider (IdP), for authentication. The Security Assertion Markup Language (SAML) is a standard authentication (and occasionally authorization) protocol which is most often used by web application single sign-on (SSO) providers to relay credentials between an identity provider (IdP) which contains the credentials to verify a user and a service provider (SP) which is the resource that requires authentication. SAML uses extensible markup language (XML) metadata documents as its tokens for an assertion of a user’s identity. The process of SAML authentication and authorization (AuthN and AuthZ) is as follows.

• SAML is an XML-based framework for exchanging security information between business partners.
• SAML provided two features which became widely used: cross-domain single sign-on and identity federation.
• A SAML service provider delegates user authentication to an identity provider.
• A SAML identity provider authenticates a user and returns the results of a user authentication event in an XML message called an authentication response.
• An authentication response contains an authentication assertion with claims about the authentication event and authenticated user.
• Identity federation establishes a common identifier for a user between an identity provider and a service provider.
• Business customers of applications often want to use their corporate identity providers to authenticate their users to applications.
• New applications should consider using an authentication broker service or SAML library to simplify the task of supporting SAML.

OAUTH 2.0

With Web 2.0 and the rise of social media, many consumer-facing web sites were created that allowed users to upload content such as pictures.A solution was needed that would allow a user to authorize an application at one web site to retrieve their content from another web site’s API, without the user having to expose their credentials to the first site.The OAuth protocol provided a solution for this use case.

• OAuth 2.0 enables applications to request authorization and obtain an access token to call APIs.
• With OAuth 2.0, a user has control over API authorizations for applications.
• Scopes are used to control the access an application has when calling an API.
• The original OAuth 2.0 specification defined four grant types.
• The authorization code grant type with PKCE can be used by traditional web applications, public applications, as well as native applications.
• The OAuth 2.0 implicit grant type is not recommended to obtain an access token with the default response mode as it exposes the access token to potential compromise.
• The OAuth 2.0 resource owner password grant type is best restricted to legacy user migration cases as it exposes user credentials to an application.
• The client credentials grant type is for API calls where the application owns the requested resource.
• A refresh token is used to obtain a new access token when the old access token expires.