Call toll free:
1.877.898.2905

Video

First commercial OAuth support secures web APIs

Madsen-OAuth


Search for documents


View search tips
To search the Resource Center, type in a keyword (or leave the keyword field blank to match all document types), select a resource type, and hit the 'search' button.

Relevance
Resource type

Select all |  Reset  
 
Ping Identity > Resource Center > Secure Web APIs 

API Security

Background

Secure web services expose APIs (Application Programming Interfaces) facilitating interaction between applications. More and more, cloud providers are giving customers raw data through these secure web services rather than delivering it through the browser as a web application.

There are two broad secure web service categories. One is SOAP-based while the other is built around RESTful principles. Both have their passionate advocates and both remain relevant. Securing these web services is needed for both a full-featured authentication and an authorization framework.

Clients interact with the APIs to access the data and services behind that API. In some cases this is on behalf of the client, other times it’s on behalf of the end user. For anything other than trivial applications, authentication is required so that an authorization decision can be supported. Generally, a token, which is a data structure with security information required for authorization, is used to authenticate to a secure web service. By examining and validating the token, the web service can authenticate the user’s identity.

How it Works

With SOAP services, the token is typically a SAML assertion and carried within a WS-Security header in the SOAP message. For RESTful services, OAuth and related specifications provide the equivalent.

Before a client can send a request with its token to a web service (whether SOAP or RESTful), the client must first acquire the token. Both scalable and efficient, a Security Token Service (STS) centralizes client validation as well as the creation and issuance of multiple types of tokens.

With SOAP clients, the WS-Trust specification defines a standardized request messaging pattern where a SOAP client can request an STS token (often a SAML Assertion) for inclusion on its subsequent SOAP message. This scenario is shown below:

Web Services

Security Token Services were originally created to identity-enable Web Services.

In the world of RESTful web services, the comparable specification to WS-Trust is OAuth. OAuth defines a number of flows where an application can interact with an Authorization Server to obtain a token. This token needs to be attached to subsequent HTTP calls to the API. Some of these flows rely on a browser to deliver the token to the client (e.g., an iPhone app), while others are logically equivalent to the STS model for WS-Trust.

Benefits

Security Token Services, (whether based on WS-Trust for SOAP web services, or based on OAuth for RESTful web services) by centralizing the creation and issuance of tokens, reduce the burden of trust management. PingFederate's STS deployment is fast and hassle-free, with no format, version or infrastructure dependencies and no required upgrades.

For more information on Cloud Identity Basics, download the "Learn More" resources in the right column.

<Previous: Automated Cloud User Provisioning  Next: SAML >