OAuth2 in Apigee and Basic Authentication in Existing API

pxzxz1
New Member

Hello fellow Apigeeks

If I already have basic authentication in existing APIs, do I still need OAuth2 in Apigee?

0 4 750
4 REPLIES 4

If I already have basic authentication in existing APIs, do I still need OAuth2 in Apigee?

The answer depends on your requiremenst. Basic auth is very basic. It does not allow for things like

  • credentials for a client app (aka "client credentials" or a "consumer key"). This means your API cannot identify the client system that is connecting to it. Is this relevant to you? Only you know the answer.
  • time-limited tokens. With Basic Auth your API must validate user credentials with every call. With OAuth2, Apigee can validate a token from cache. This can mean better performance at scale. Is this important to you? Only you know the answer.
  • Scoped tokens. With Basic Auth there is no way to limit the ability of a client app to perform certain activities. OAuth2 token scopes provide that for you. Is this important to you? Only you know the answer.
  • Minimizing secrets sent on the network. With Basic Auth, the client app must always send the password (encoded) over the network. With OAuth2, there are ways to avoid sending secrets, for example relying on public/private key crypto to sign requests. Is this important to you? Only you know the answer.
  • and so on...

You have to make the judgment call.

Hello Dino

Hope you understand by existing API I meant the Target Endpoint. Basic Auth is as basic and simple as just a username and password. I implemented OAuth2 separately, but hitting error when I integrated them together.

Can I have both authentication at the same time?

You don't want both on the same API. You *Could* do it, but probably it makes sense to reconsider.

Both Basic Auth and OAuth2 direct the client to use the Authorization header to transmit credentials, but these are different credentials. So if you apply both to the same API, you will at the very least need to use different headers than the specifications recommend. This will be confusing to developers who consume (or use) the API.

Aside from the confusion related to the Authorization header, OAuth2 is intended to be much more complete than Basic Auth. It can do all that Basic Auth can do, and more. If you want user authentication, then I recommend that you use a password grant flow to issue an OAuth2 token. Inside Apigee, validate both the user credentials (passed in a form param) and the client credentials (passed in a Basic Auth header) before issuing the token. That token will then identify the authenticated user+client pair for the duration of the token lifetime.

When a client presents a call bearing that token to Apigee , Apigee can call VerifyAccessToken and can then be assured that both the user identity and the client identity are known.

That's standard good practice in OAuth2.

Hello Dino

I do understand where you are coming from on OAuth2 good practices, but I cannot remove Basic Auth credentials as it is there for a purpose.

Based on OAuth2 good practices, I verified the access token (Authorization: Bearer XXXXX) to the proxy. Moving to target server (target endpoint), I need to include another Authorization to the Header which is the Basic Auth (Authorization: Basic XXXXX).

Implement OAuth2 alone returned me Unauthorized error (in Postman). How do I parse two Authorizations in Apigee?

P.s. The user will only need to have the Bearer token, since Basic token will be hard-coded in Apigee.