Multiple Perspectives on Security

Security Journal

Subscribe to Security Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Security Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Security Journal Authors: Elizabeth White, Ravi Rajamiyer, Liz McMillan, Peter Silva, SmartBear Blog

Related Topics: Cloud Computing, Security Journal, IT Strategy, Secure Cloud Computing, F5 Networks, Internet of Things Journal, API Security

Cloud Computing: Blog Feed Post

Protecting API Access with BIG-IP using OAuth

As more organizations use APIs in their systems, they’ve become targets for the not-so-good-doers so API Security is something you need to take seriously. Most APIs today use the HTTP protocol so organizations should protect them as they would ordinary web properties.

Starting in v13, BIG-IP APM is able to act as an OAuth Client, OAuth Resource Server and OAuth Authorization Server. In this example, we will show how to use BIG-IP APM to act as an OAuth Resource Server protecting the API.

In our environment, we’ve published an API (api.f5se.com) and we’re trying to get a list of departments in the HR database. The API is not natively protected and we want APM to enable OAuth protection to this API.

api1

First, let’s try an unauthenticated request.

api2

You can see we get the 401 Unauthorized response which is coming from the BIG-IP. In this instance we’re only sending 3 headers, Connection (close), Content Length (0) and WWW Authenticate (Bearer), indicating to the client that it wants Bearer Token authentication.

api3

So we’ll get that authorization and a new access token.

api4

Here the Getpostman.com (Postman toolchain for API developers) is preconfigured to get a new access token from the OAuth authorization server, which is a BIG-IP.

api5

We will request the OAuth token and will need to authenticate to the BIG-IP.

api6

After that, we get an authorization request. In this case, BIG-IP is acting as an Authorization server and is indicating to the resource owner (us) that there is a HR API application that wants to use certain information (about us) that the authorization server is going to provide.

api7

In this case, it is telling us that the resource server wants to get scope api-email.

We’ll click Authorize and now we have our auth token and is saved in the Postman client.

api8

Within the token properties we see that it expires in 300 seconds, it is a Bearer token and the scope is api-email and we get a refresh token as well.

api9

Now we can add this token to the header and try to make a request again. And this time, we get a much better response.

api91

We get a 200 OK, along with the headers of the application server. We’ll click on the Body tab within Postman, we’ll see the XML that the API has returned in response to the query for the list of departments that are available. There were no cookies being returned by the server if you were wondering about that tab. In the Headers tab we see the Authorization header that was being sent and the content of the Bearer token.

A simple way to easily protect your APIs leveraging OAuth 2.0 Resource Server capabilities in BIG-IP.

Special thanks to Michael Koyfman for the basis of the content and check out his full demo here.

ps

Related:


Read the original blog entry...

More Stories By Peter Silva

Peter is an F5 evangelist for security, IoT, mobile and core. His background in theatre brings the slightly theatrical and fairly technical together to cover training, writing, speaking, along with overall product evangelism for F5. He's also produced over 350 videos and recorded over 50 audio whitepapers. After working in Professional Theatre for 10 years, Peter decided to change careers. Starting out with a small VAR selling Netopia routers and the Instant Internet box, he soon became one of the first six Internet Specialists for AT&T managing customers on the original ATT WorldNet network.

Now having his Telco background he moved to Verio to focus on access, IP security along with web hosting. After losing a deal to Exodus Communications (now Savvis) for technical reasons, the customer still wanted Peter as their local SE contact so Exodus made him an offer he couldn’t refuse. As only the third person hired in the Midwest, he helped Exodus grow from an executive suite to two enormous datacenters in the Chicago land area working with such customers as Ticketmaster, Rolling Stone, uBid, Orbitz, Best Buy and others.

Writer, speaker and Video Host, he's also been in such plays as The Glass Menagerie, All’s Well That Ends Well, Cinderella and others.