OAuth is a security protocol aimed at solving the problem of risk of sharing credentials with native applications while gaining access to web resources. OAuth has evolved to support every use case perceivable but in doing so had become a rather complicated spec for developers to use and build.

This FAQ aims to answer questions to help developers better understand OAuth and Apigee’s capabilities.

What is OAuth?

OAuth is an open standard for authorization. OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.

How does OAuth compare with Kerberos?

(OAuth is like the ticket granting service (TGS) in Kerberos. What about the other parts? Can OAuth be organized into domains? Can TGS be delegated, in addition to primary services? Are the threat models the same? Are the protection models the same?)

OAuth can be organized by realm. OAuth Core doesn't specify the semantics for a realm, but OAuth Discovery does. OAuth Discovery also describes how to delegate ticket granting. Most delegated ticket granting assumes a shared backend between the SP/TGS and the SP/SS, unlike Kerberos. Someone may have whipped up a nifty access token scheme that would let you use a prearranged secret instead, ala Kerberos.
The threat and protection models are totally different.

How is OpenId different from OAuth?

OpenId: Sharing a single identity with numerous consumers.
OAuth:   Share Data without sharing Identity

Different types of OAuth and differences between them?

See Apigee's blog post: Top Differences between OAuth 1.0 and OAuth 2.0 for API Calls

OAuth best practices?

See the eBook OAuth: The Big Picture

This e-book will help you understand how OAuth fits with APIs and the emerging world of open platforms, its advantages and challenges, what role it can play for your products, and without having to know the fine details of the protocol.

Why should I use OAuth 2.0?

OAuth 2.0 is more secure than the typical username/password paradigm. Credentials are not stored on the device. Keys are used as the mechanism to authenticate.

From the developers perspective, why use OAuth 2.0?

Advantages of OAuth 2.0 from a developer's point of view include:

  • Getting access to a user’s social graph.
  • Posting to user's Facebook wall or Twitter stream.
  • Store data in users' online file system of choice e.g. Google Docs or Dropbox account.
  • Integrating business applications to drive smarter decisions.

What is the benefit of using OAuth 2.0 from the end user's perspective?

From the end user's point of view, OAuth 2.0 provides:

  • Increased trust
  • Decreased user sensitivity to phishing
  • No more expanded access and risk
  • No limited reliability
  • Easy service revocation
  • Passwords isn't required anymore
  • Easier to implement stronger authentication

What are the different versions/standards of OAuth that Apigee supports?

OAuth 1.0
OAuth 1.0a
OAuth 2.0

We have SOAP APIs - Is OAuth suggested?

No. OAuth is not suggested in scenarios in which you have only SOAP APIs.

We recommended in this scenario you leverage Apigee to do mediation from your back-end SOAP APIs to RESTful APIs and then implement OAuth.

What OAuth 2.0 draft versions can Apigee support?

Apigee can support any draft version.

What are the different roles involved in OAuth and what role does Apigee play?

  • Resource server (API provider)
  • Resource owner (user of an application)
  • Client
  • Authorization server (Apigee)

What are popular OAuth flows supported by Apigee?

  • Client Credentials
  • User Agent
  • Web server
  • Username-password flow

When should I use Client Credentials Flow?

When acting on behalf of the app itself rather than on behalf of any individual user, which means there is no individual end user involved.
The client credentials grant type is usually only used in scenarios where apps are trusted clients, such as those developed and distributed by API providers themselves or by partners.

I am a Service Provider (API Provider) and my use case is B2B for my Partners where no individual end user is involved. Which OAuth flow is suggested?

We recommend using the Client Credential Flow when no individual end user is involved.

I am a Service Provider (API Provider) and my use case is a B2C, in which there is an individual end user (mobile user) involved. We store the mobile user credentials. 
Which OAuth is suggested?

User Agent/Implicit OAuth flow is suggested in this scenario.

In which scenarios is Web Server flow suggested?

  • The OAuth client is a web application server.
  • Long-lived access is required.
  • The OAuth client is running in the browser (using JavaScript, Flash, etc.).
  • The browser is strongly trusted and there is limited concern that the access token will leak to un-trusted users or applications.

In which scenarios is the username-password flow suggested?

  • Should be used only for trusted partners.
  • Client applications collect user credentials and has to be exercised with real caution.
  • Can be used in scenarios when the users belong to trusted partner’s domain.

Is there any integration point required between Service Providers (API Providers) and Apigee in the case of a B2B scenario for which there is no individual end user?

No. There is no Integration Point required between Service Provider and Apigee when its client credentials flow.
It is only required in the case of User Agent flow.

Is Auth Code and Access Token Semantics handled by Apigee or Resource Server (API Provider)?

Both Auth code and access token semantics are handled by Apigee. You just need to send the corresponding parameters to generate auth code/ access token.

Why do I need client and secret?

You need a client ID/API key and secret to obtain an access token through which in turn you can access the resources.

Where can I get a client ID and secret to obtain an access token?

As part of Apigee Developer Channel Services, Apigee offers a drupal-based developer portal where you can register your app to obtain the client ID and secret.

In case of a User Agent flow in a B2C scenario how does the integration happens between Apigee and the Service provider (API Provider)?


  1. Apigee will authenticate Consumer app(Partner app/third party app) using the client id/API Key.
  2. Once Apigee successfully authenticates the app , Apigee will redirect to the login page URL provided by the Service Provider (API Provider).
  3. Once the login app (Provided by Service Provider/API Provider) authenticates the end user successfully, the Service Provider can notify Apigee to verify that the end user is authenticated and has authorized app.
  4. Apigee then issues an access token to the Consumer App.

What are the steps involved in a typical web server scenario between Apigee and a Service Provider/API Provider?

  1. In a typical Web server scenario, Apigee will issue authorization code and the secret to the application.
  2. Using the authorization code and secret obtained earlier the application can exchange to obtain the access token.

Can I provide a file URL to Apigee for app_call back/redirect_uri?

You need to provide an HTTP URL instead of a file URL for app_call back/redirect_uri

How do I make API calls once I have an OAuth access token?

You can make the API calls by including the proper OAuth 2.0 “Authorization” header:
For example using curl the API call looks like:

Curl -H “Authorization:Bearer OqX8UUlT98XAKsBbTYHpEt5tkiCV”

How can I get the values a user added in username and password fields of the login app? Are these values in header information - Authorization header?

Passwords aren't stored as clear text, so it isn't possible to retrieve them—that's a standard best practice we follow in order to protect everyone.

What are the integration points between Apigee and a Service Provider?

Apigee redirects to a Service Provider's Login App. So, the URL of the Login App has to be shared with Apigee.
Once end user Authentication is done, the Login App can notify Apigee via an API call.

Should the Service Provider manage the end user credentials?

The Service Provider does the End User Authentication; Apigee does the App Authentication.

What if the Service Provider does not have a User store? Can Apigee provide one?

Yes. Service providers can leverage  Apigee App Services to maintain a User Repository.

Can Apigee host login App?

Yes. That will be an additional Service.

Can the expiry interval of the Access Token be configured?


We already have an Authentication scheme in-house. Can Apigee help handshake with OAuth?

Yes. Apigee can perform credential mediation between any Authentication scheme to OAuth.

Additional Resources:


Protocols as defined by RFC 5849:

Details of OAuth and the evolving specification

OAuth Google groups

Help or comments?

  • Something's not working: See Apigee Support
  • Something's wrong with the docs: Click Send Feedback in the lower right.
    (Incorrect? Unclear? Broken link? Typo?)