Apigee and Okta Partner for API Security

Apigee is excited to announce a partnership with Okta, a leader in the Identity-as-a-Service space.

A critical reason customers use Apigee is to secure their APIs. And one of the most critical aspects of security is the authentication and authorization of the APIs.  

Apigee’s and Okta’s offerings complement one another to solve the AuthN/AuthZ problem for customers. Almost every customer using Apigee needs to integrate Apigee Edge with a central identity/SSO store. Enterprises traditionally have used legacy, on-premises identity providers.

But customers increasingly are choosing Apigee and Okta together as two critical platforms for digital transformation and their cloud journey.

There are two common use cases for this integration:

  • Customers want to use Apigee’s API management capabilities and use Okta for identity management
  • Customers use Okta as their OAuth/OpenID connect provider across the organization

As part of the partnership, we’ve created an out-of-the-box solution for the first scenario (learn about it here). The solution is intended as a reference implementation and is available as an open source solution.

Scenario 1: Apigee provides OAuth

In the first use case, Apigee acts as the OAuth provider while Okta provides the identity store and handles authentication of the identities.

Let’s take a quick look at what we’ve built here:

In the diagram above, Apigee provides the client_id and client_secret. Pre-work steps aren’t needed for the runtime API security; they’re performed beforehand:

  • The Apigee admin registers Apigee as a valid client with Okta; Apigee receives the public key from Okta and stores it in its KVM or vault
  • A developer self registers in the Apigee developer portal
  • The developer registers an app in the Apigee dev portal.,Apigee issues a client ID and Client secret to the app.

In the runtime flow:

  • The client makes a call to Apigee with the client ID and secret, which Apigee validates
  • Apigee redirects the client app to Okta
  • Okta collects the user credentials and authenticates and authorizes the user with support for multi-factor authentication ( if needed)
  • If the user is validated, then Okta returns an id_token back to Apigee
  • Apigee issues an access token against the id_token and stores a map of access_token to id_token in the key storage
  • When a secured API is invoked, it is invoked with the access token, which Apigee validates; depending on requirements, it either sends the whole id_token or part of it to the backend

Scenario 2: Okta acts as the OAuth provider

This is another common integration pattern, but currently we are not providing an out-of-the-box solution for this. Often, when Okta is the enterprise-wide identity platform (for web, mobile, or APIs), the customer is likely to leverage Okta as the OAuth provider.

To follow this integration pattern, it’s important to keep a few things in mind.

For an API program, a developer portal is crucial. This is where developers register themselves as well as their apps. Once the apps are registered, developers receive their API key or client_id/client secret from the dev portal.

Okta can be used as an OAuth provider, but Apigee must have knowledge of the client_ID and client_secret because:

  • It uses those IDs for throttling
  • The IDs are crucial for analytics and API debugging
  • IDs are used for app lifecycle management
We hope you've found this walk-through useful, and look forward to working with Okta to develop new integrations. To learn more about Okta’s OAuth and OpenID Connect support, visit http://developer.okta.com/docs/api/resources/oauth2.html.


API Best Practices: Security

How to ensure your APIs aren't naked

Over the last few years, we’ve witnessed hundreds of enterprises launching API initiatives. This post is the first in a series that aims to distill our learnings from all these customer engagements and share best practices on a wide variety of topics, from deployment models to API design to microservices.

Three-quarters of mobile apps fail standard security tests—and most cyber attacks target the app layer, according to Gartner.

Organizations have used web application firewalls and DDoS protection solutions to secure their web apps. In the world of mobile, cloud, and microservices, where enterprise data is accessed with APIs in a zero-trust environment, what’s needed is deep API security. At risk are hundreds of thousands of sensitive customer records or millions of dollars.

There are known threats. The Open Web Application Security Project (OWASP), an online community of application security researchers, publishes an annual list of the top 10 security threats enterprises face. But there are also potential attacks from “unknown” threats—software that constantly scans for vulnerabilities in application infrastructures.

For protection against all kinds of external threats, organizations should create proxies in front of their APIs with an API management platform and enforce a set of consistent security policies at the API proxy layer. So, let’s review typical types of cyber threats and how organizations secure their APIs.

Injection threats

These are common. Attackers trick an application to divulge sensitive information by including malicious commands as part of data input. For example, by sending strings like " OR 1==1 -- " as a data input, hackers could bypass user authentication in the application like the code snippet below:

select user_id FROM customer_data WHERE username = ‘ ’ OR 1 = 1

-- customer_passwd = ‘abcd’;

To prevent this kind of attack (and related JSON and XML bomb threats), organizations use built-in policies like regular expression protection (Regex) and XML/JSON threat protection policies available in API platforms. These API input validation policies harden your APIs and applications against injection threats.

Broken authentication and session management attacks

These attacks steal session IDs or tokens from your app user’s device and enable hackers to take over a user account. To mitigate such attacks, enterprises use out-of-the-box two-way TLS and OAuth2 policies to implement standard OAuth2 and enforce two-factor authentication.

Cross-site scripting (XSS)

Cross-site scripting involves a hacker executing malicious code on behalf of an innocent user by hoodwinking the user to click on compromised URLs.

Instead of http://usbank.com/account?item=543, for example, the hacker could get an innocent user to execute something like


Executing this script, the mobile client using the API could allow an attacker to steal the user’s authorization token or cookie. This vulnerability exists in many web apps and mobile apps that use webviews. Hackers can use the innocent user’s token or cookie to log in into your systems and steal sensitive data.  

To prevent XSS threats, you can enforce strict API input validation with out-of-the-box regular expression protection (Regex) policies in the API proxy layer.

Insecure direct object reference and missing function-level access control

With each of these attack vectors, the hacker modifies an existing API request pattern to either access objects they shouldn’t or request access at a different level (user versus admin) in your apps.

For example, realizing the API is of the form https://api.awesomeretailer.com/user/account/1234, hackers could attempt a series of API calls by changing the account number (for example, https://api.awesomeretailer.com/user/account/5432 ) to access other accounts. Or they could try to gain access using https://api.awesomeretailer.com/admin/account/5432

With OAuth2 and the right scopes set for APIs, organizations can easily reduce the attack surface and mitigate risk without refactoring existing applications.

Sensitive data exposure

When web and mobile applications store sensitive data like credit card information and passwords insecurely, problems arise. By building secure API proxies for your sensitive APIs, you create a secure facade in front of your applications. Using a PCI- and HIPAA-compliant API platform, organizations create secure proxies and also ensure API keys are stored in encrypted mode.

Cross-site request forgery (CSRF)

In these attacks, hackers exploit the trust that an application has in a user’s identity after the user initially logs into the app (a banking app, for example). The hacker would have sent this innocent user an HTML email with a tag like

<img src=”https://www.urbank.com/move?amount=5000&destination=”favhacker”>

If this “image” is loaded automatically, the user’s client would make a transfer request with the exact IP address and session cookies or token; it would appear as if the innocent user has made the call. From the app perspective, it would look like a legitimate request, and it would send $5,000 to the hacker’s account.

This kind of attack is mitigated by adding special CSRF tokens or by reducing the attack window with expiring tokens and using two-way TLS to avoid token leakage. Organizations have implemented it with a set of secure API proxies for all their sensitive APIs.

Beyond the above known OWASP threats, organizations also need to protect themselves from volumetric attacks like denial of service (DoS) attacks. Enterprises use spike arrest and rate-limiting policies at the API proxy layer to mitigate risk from such volumetric attacks.

Adaptive threats

Besides the various known threats, increasingly we need to tackle “unknown” threats, where automated software programs called “bots” can constantly scan for security vulnerabilities in your app infrastructure.

Unlike web apps, APIs are programmable, making it easier for attackers to target APIs using bots. Bot traffic can probe for weaknesses in APIs, abuse guest accounts with brute force attacks, use customer API keys to access private APIs, abuse loyalty programs, or scrape pricing data for competitors via APIs. Bad bots like these comprise 10% to 15% of internet traffic today.

A sophisticated API platform continuously monitors your web and API traffic. It identifies bots by using API access behavior patterns, rather than IP addresses. As a result, bots can be tracked even when they change location.

Advanced API platforms uses sophisticated machine learning algorithms on data aggregated across multiple customers. As it analyzes billions of API calls, it can distinguish legitimate human traffic more effectively than possible from a single source of data.

Once it identifies API call pattern that has a “bot like” signature, it flags it. You can then specify the action to take for each such identified “bot signature.” The API platform would then automatically take appropriate actions like blocking, throttling, or honeypotting.

It is pretty easy to stand up a set of APIs for use for your mobile apps teams or partners, but it takes a lot more to make sure you are not exposing a set of naked APIs.

For protection against all kinds of threats, organizations create proxies in front of their APIs and enforce a set of consistent security policies at the API proxy layer with API management platforms.


How to Make Your Apigee Edge-Okta Integration Seamless

Okta is a popular identity and access management solution that shares several customers with Apigee. Often, customers whose API calls flow through Apigee and rely on Apigee as the OAuth provider for all of their apps also want to use Okta for end-user authentication. How can they make this a seamless process that adheres to standards as much as possible?

In this short yet comprehensive demonstration, we walk through integrating Apigee and Okta and discuss topics including OAuth and resource-owner or password-grant flows.

All API traffic (the runtime API and the authentication/token API) is proxied through Apigee Edge. Apigee delegates the end-user authentication to Okta and generates an access token that can be used to access any API that is protected using OAuth policies.

Apigee supports custom attributes that can be associated with an access token very easily. This is helpful when you have to reference some values/IDs returned by the identity provider and, more importantly, when you have to pass them along to the back-end APIs at runtime. Apigee Edge makes it simple with out-of-the-box policies.

Apigee also supports external access tokens (those not generated within Apigee—in this case, from Okta). You’ll see two variations of the password grant: access token minted and persisted within Apigee; and access token minted in Okta (In the demo we use the session ID token returned from Okta as the access token) but persisted and recognized within Apigee as if it was generated there.

There are several benefits to using this delegated model approach, including:

  • It’s standards-based (OAuth 2.0)
  • It enables security enforcement at the edge
  • It enables responsive and secure APIs
  • It provides end-to-end visibility into authentication traffic in addition to your run-time traffic
  • It creates a seamless experience for app developers

We hope you found this useful. If you have any questions or want to discuss this, please visit community.apigee.com.

Why Enterprise Security Needs APIs

From time to time, we will have guest authors weigh in on specific topics here. While I’m  interested in all topics, and have opinions on almost all things related to APIs and data :), sometimes it’s better to let the experts have a say. So here is a first guest post. This topic is especially important because by now people realize that digital transformation requires APIs.  And we know that APIs require security. But does security need APIs? I discussed this in a previous post; here's the first in a series of  posts that elaborates on the topic.

Enterprise security incidents surged by 38% last year and malicious attacks on enterprise data continue to have significant impact, incurring a cost of over $500 billion today to an estimated $2 trillion by 2019. Enterprises are adopting APIs and API facades to secure access to valuable enterprise data from both internal and external users and apps.

Although many new apps use REST APIs, many enterprises still employ web applications that make direct calls to backend systems. To date, enterprises have used a layered security model to thwart external threats at the app layer. By mandating the use of APIs to access critical enterprise data, enterprises can create effective security control points and gain several security advantages.

Smaller attack surface

Today, when there’s a security breach in an application, all the backend systems that provide data to the app can be exposed. By ensuring the apps only use APIs to access data on backend systems, you can automatically restrict access to a smaller set of resources and data by passing the requests through an API gateway. This minimizes the attack surface should a breach occur.

Smaller attack window

Web apps that use simple usernames and passwords are challenged to securely store these credentials. Rotating them frequently is also difficult and therefore rarely implemented. In the event of a compromise, the enterprise is severely exposed as there is no time dimension to the credentials (they don’t generally expire).

By using APIs and OAuth, you limit the opportunity for attackers by using continuously rotating credentials that expire frequently.

Defense in depth

By using API management, enterprise security teams can deploy an effective, layered security framework. You can enforce a set of security policies across all your enterprise APIs (spike arrest and injection threat protection, for example) and, if required, enforce additional security policies, such as OAuth2, on select APIs.

Think of an API management platform as the internet-exposed layer of your applications environment that provides a defensive capability in front of your backend systems. 


With APIs and API management, you have the flexibility to downgrade or upgrade your API versions seamlessly as part of remediation efforts against security breaches. You can also roll out new API versions to select audiences before wider rollout to minimize security risks.

Virtual patching

An API management platform enables virtual patching and quick remediation against an identified vulnerability in a downstream system without having to change the source code of the system. By applying new security policies to limit potentially malicious input in the API gateway, you can significantly mitigate the impact of zero-day exploits and unpatched systems.

Security metrics

Most enterprises have limited visibility into the vulnerabilities of apps accessing your enterprise data. With APIs and API management, you automatically gain granular visibility into which backend systems are accessed insecurely.

API analytics provide traffic visibility that enables an enterprise to discern between bot traffic and legitimate traffic, transport layer security (TLS) versus non-TLS traffic, and authenticated versus unauthenticated requests. Security metrics like these enable you to fix vulnerabilities and improve overall application security.

By mandating the use of APIs to access any critical enterprise data, you create effective security control points and your enterprise assets become more secure. Enterprises that are going digital and are concerned about their assets should consider an API-first approach to their digital transformations.

Coming up, we’ll take a more in-depth look into the benefits of using APIs to secure enterprise data.

Black Friday: Protect Your APIs from Cyber Threats

Webcast replay

Bad bots can scrape your inventory and pricing information, and steal consumer credentials. Bots can also put stress on backend services and impact your SLA to customers and partners, especially around events like Black Friday.

To protect your APIs, you need a new, data-driven approach to identify and stop bad bots automatically.

In this webcast replay, Apigee's Subra Kumaraswamy and David Andrzejek discuss:

  • the nature of bot attacks and typical use cases
  • how to intelligently detect bad bots whilee leetting good bots in
  • how to implement technologies in your security stack to protect against bad bots



Security in the Digital Age: Deep-Dive Webcast

What are the biggest cyber threats facing financial and healthcare entities today and in the near future? How can organizations embrace innovation and agile development culture while balancing the time to market goals with risk management?

Join Jason Kobus, director of API banking at Silicon Valley Bank, and Apigee's head of security Subra Kumaraswamy in this webcast replay as they discuss how an effective API program, combined with a secure API management platform, can:

  • provide visibility for all security threats targeting their backend services

  • control access to sensitive data, end-to-end

  • enable developers to build secure apps with secure APIs

  • facilitate secure access with partners and developers


Rethinking Governance in an API-First World (webcast & podcast)

Organizations need a fresh prespesctive on API governance to realize the true benefits of an "API-first" approach and the efficiencies that an API management platform can bring. 

In this webcast replay, Apigee's Subra Kumaraswamy and Chris von See explore new approaches to API governance, including:

  • best practices to help organizations scale their API programs
  • how governance can enable security and compliance
  • how to execute API governance throughout design, implementation, and runtime operations


How to Achieve Agile API Security (webcast & podcast)

Opening up your APIs in an effort to create engaging experiences might feel like it comes at a cost to security. But the balance can be struck with the right API architecture that builds in security at every stage.

In this webcast, Subra Kumaraswamy discusses the proper security architecture and security patterns for app and API access control. The webcast also covers:

  • how to approach security in your API program
  • the three pillars of API security—threat protection, data security, and identity
  • best practices for integrating identity services into API management
  • how to meet compliance requirements for API products.


OAuth 2.0 Support in Apigee Android and iOS SDKs

OAuth 2.0 is an essential part of securing many APIs and in turn is important for many mobile applications. With the latest release of Apigee’s iOS and Android SDKs, we’ve added the ability to authenticate an API from generic OAuth 2.0 endpoints.  

There are four different grant types that can be used when authenticating a given API. Each of these grant types can easily be used in both of our mobile SDKs.

iOS SDK: Get an access token

To get an access token using the iOS SDKs ApigeeDataClient class, call one of the methods described below. Each method is asynchronous and works on background threads. When the method has completed, the ApigeeOAuth2CompletionHandler block containing the access token data is executed.

/*! OAuth2 grant_type 'password' */

/*! OAuth2 grant_type 'client_credentials' */

/*! OAuth2 grant_type 'code' or 'token' */

Once you’ve received the access token data, you can manage the storage and retrieval with easy-to-use methods that employ keychain built-in to the core iOS SDK framework for storage.

/*! Stores the given OAuth2 access token and refresh token into the keychain under the given name. */

/*! Retrieves the OAuth2 access token and refresh token from the keychain with the given name. */

/*! Removes the OAuth2 access token and refresh token from the keychain with the given name. */

Android SDK: Get an access token

The client_credentials and password grant types each have methods for both asynchronous and synchronous authentication. In the Android SDK ApigeeDataClient class, you can gather the access token data simply by calling these methods:

/*! OAuth2 grant_type 'client_credentials' asynchronous */
   public void oauth2AccessTokenAsync(final String accessTokenURL, final String clientId, final String clientSecret, OAuth2ResponseCallback callback)

/*! OAuth2 grant_type 'client_credentials' synchronous */
   public TokenResponse oauth2AccessToken(String accessTokenURL, String clientId, String clientSecret)

/*! OAuth2 grant_type 'password' asynchronous */
   public void oauth2AccessTokenAsync(final String accessTokenURL, final String username, final String password, final String clientId, OAuth2ResponseCallback callack)

/*! OAuth2 grant_type 'password' synchronous */
   public TokenResponse oauth2AccessToken(String accessTokenURL, String username, String password, String clientId)

The other two grant types, code and token, use a three-legged approach and require a webview in order to authenticate. The Android SDK has convenient methods to generate activities that display a webview within your application, authenticate the user, and retrieve the access token data.  

/*! OAuth2 grant_type 'code' intent */
   public Intent oauth2AccessTokenAuthorizationCodeIntent(Context context,String authorizationCodeURL, String accessTokenURL, String redirectURL, String clientId, String clientSecret)

/*! OAuth2 grant_type 'token' intent */
   public Intent oauth2AccessTokenImplicitIntent(Context context,String authorizationCodeURL, String accessTokenURL, String redirectURL, String clientId, String clientSecret)

Calling these methods returns an activity which can then be started. Once the authorization is complete, you can retrieve the access token data from the returned intent object’s extras. Accessing the access token data is demonstrated below.

   protected void onActivityResult(int requestCode, int resultCode, Intent data) {
       if (requestCode == Constants.kImplicitRequestCode) {
           if (resultCode == RESULT_OK) {
               String token = data.getStringExtra(OAuth2WebViewActivity.OAuth2AccessTokenExtraKey);
               if( token != null ) {
                   this.tokenResponse = new TokenResponse();
                   this.tokenResponse.setExpiresInSeconds(data.getLongExtra(OAuth2WebViewActivity.OAuth2RefreshTokenExtraKey, 0l));

Once you’ve received the access token you can manage the storage and retrieval with some simple methods. The Android SDK uses the built-in FileDataStoreFactory for storage.

/*! Stores the given OAuth2 access token and refresh token into the FileDataStore under the given name. */
   public Boolean storeOAuth2TokenData(String storageId, TokenResponse tokenResponse)

/*! Retrieves the OAuth2 access token and refresh token from the FileDataStore with the given name. */
   public TokenResponse getOAuth2TokenDataFromStore(String storageId)

/*! Removes the OAuth2 access token and refresh token from the FileDataStore with the given name. */
   public void deleteStoredOAuth2TokenData(String storageId)

Implementing OAuth 2.0 in your Android or iOS mobile applications can be frustrating and take a lot of time and code. Using Apigee’s SDKs helps ease those frustrations and saves app developers time and effort.  

To see the iOS code in action you can check out this video. You can also explore our OAuth 2.0 sample application, which is included within both the iOS and Android SDKs.

OAuth: Why it is Still a Good Solution to Secure Your API

The question of whether OAuth is an effective mechanism for securing back-end resources comes up from time to time. Recently, an API developer asked whether OAuth is the right solution to secure an API that he plans to make available for mobile app development - Why bother with OAuth when it's so easy to defeat?

This API developers concern centered around the risk of app developers using the API in nefarious ways - a concern that the app developer has full access to the information typed in by the user on the web form when an embedded web browser is provided in the app, or that the app developer could easily take a user to their own "spoofed up login page" that looks like the API provider's login page when a full web browser app is used.

All great questions to ask as you consider opening up your API. My take is as follows:

Reducing Risk

If you are working on an API that will be used by third party developers, then there is no magic bullet that will prevent developers from using your API in bad ways. However I think that OAuth 2.0 helps you reduce the risk.

In fact, I would argue that if you have a web page that lets people log in to your service using a username and password, then the risks that you describe - chiefly, the possibility that a nefarious developer will put up a fake "login page" for your service - are present whether you have an API or not and whether you use OAuth or not.

Rather, I think that there are some risks that OAuth helps you minimize.

For instance, if you simply set up your API using HTTP Basic security, or if you use OAuth 2.0 with the username / password grant type - which allows a developer to send a username and password to your API in one call, and get back a token - then the developer, in all cases, has access to the clear text password without any special hacking. Sure, the developer could be evil and do something bad with it, but more likely the developer will make a mistake or not think and write the password in clear text to her own database, or leave it sitting around on the device unencrypted after the app is uninstalled, or print it out in a debug log that gets stored in the cloud and indexed by Google, and on and on.

On the other hand, the authorization code grant type in OAuth 2.0 requires that you open a web browser window that directs the user to a special authentication page, and the password is entered directly on that form. I am not enough of an iOS developer to know how as a client-side developer you can access those cleartext forms rendered by another site from inside an iOS app, but if you can then that's too bad. I still imagine that an attack like that requires more work than accidentally writing the clear-text password to a log, however.

Either way, once the user is authenticated, then on the mobile device you can store the OAuth token locally, and not the password. The OAuth token is random, long, has a limited lifetime, and can be revoked without affecting the underlying user credentials. So, it's safer to store the token, and not the original password, on the device between app launches, which also reduces risk.

Revoking Rights

Credential negotiation with all apps eventually comes down to trust. The moment an app goes rogue, a provider can invalidate all of the authorizations that had been granted to that app. Regardless of how you do authentication, the importance of assigning each app a unique set of credentials, which is a fundamental part of both OAuth 1.0 and 2.0, is obvious.

For instance, imagine that a developer DOES use your open, public API to forge a login page and harvest user credentials. If you have good logging and analytics on your API, or user feedback, you will find out eventually, in which case you can immediately revoke the app's credentials.

The provider can also force a password reset for all users of a rogue app, because they know which users had previously granted authorization.

Or, if your API is only open to your own developers, then OAuth requires that an app include its own credentials before making any token requests. It's a lot harder for an evil developer to build an app that spoofs your authentication protocol if they can't get credentials to ask for an OAuth token in the first place.

If the native browser flow is triggered, the best-case is that the end user is already logged in to the service so that no password has to be entered. (Embedded browsers usually get in the way here.)

OAuth 2 gives the app the ability to ask only for scopes it needs and to increase them later, if necessary. That way developers can ask for what they need when they need it.


Like everything in security, it's a matter of reducing risk because you can never totally eliminate it, and I think that OAuth 2.0 helps a lot in this area. OAuth can seem cumbersome and complicated for developers too, but with your end-users’ experience and security top-of-mind, I think OAuth is worth the effort.

And what is the alternative? If you use plain HTTP Basic authentication then the app developer still has access to the clear-text password, and unless you combine it with a separate set of application credentials, you can't disable access to a separate app. If you design some other mechanism that:

  1. Validates app credentials
  2. Validates username and password
  3. Returns a "token"

Then you end up with your own version of OAuth.