When I remove OAuthV2 and AM policy, I am still able to get access token and use it and access backend service.
That’s expected I guess.
The question here is, do we need the OAuthV2 when we are using external token ?
What is the advantage of using OAuthV2 ?
Apigee can act as a token dispensary, and a token validator. Most companies that use Apigee have a portfolio of services , some of which might be custom-built, some of which might be off-the-shelf (SaaS). Some are older, and effectively not modifiable, and some are modern and can get updates on a daily or weekly basis. But the set of all of these services have a variety of different security requirements and mechanisms. Service A might be a modern system that just checks a client X509 certificate via TLS. Service B might accept an API key. Service C might be a SaaS that requires an OAuth token distributed by a different provider. Service D might require a self-signed JWT. So there’s a variety of security approaches and credential types. Apigee can be helpful in producing a standard security interface for the disparate upstream services. So that a client that wants to connect with A, B, C, and D, need not support all the different security mechanisms for each of those services. Instead, you can configure Apigee to act as security mediator. The client simply sends in credentials that Apigee understands, and Apigee can send the right service-specific credentials to the various upstream services.
OAuthV2 is an authentication and authorization framework that standardizes how clients can authenticate to service providers. The basic idea is a client goes through a process to obtain a “token”, and then the client can present that token to a service provider (API endpoint), ty0pically via the Authorization header in an HTTP request. The service provider can validate the token, and then make a decision as to whether to allow the request. The benefit of OAuth V2 is that it standardizes the way clients and service providers interact, from a security perspective. It makes it easy for everyone to use the same model. We all know what we’re talking about when we say “OAuth”.
You might be asking about the OAuthV2 policy in Apigee. That is a different question. The OAuthV2 policy has multiple purposes in Apigee, the main ones are:
- generating a token
- verifying a token
- refreshing a token
What you configured in your proxy was an OAuthV2 policy to generate a token. That’s probably always going to work. But it doesn’t provide any validation, it doesn’t add anything to the security protection of your upstream system.
It’s as if you walked into a metro station, presented a token that grants you the right to ride, and the metro station created a new token for you, of a different type. That’s what it seems like you’re doing with your Apigee config. You have an externally-generated token, you configured your Apigee proxy to generate a new token, and then connect to the upstream system. You didn’t configure your Apigee proxy to verify either the external token or the Apigee-generated token.
To do that you need to use Operation = VerifyAccesstoken
Let’s step back. The process for OAuth in general is usually
- the client requests a token of the token dispensary. The token dispensary validates the credentials, and then returns a token. The token has an expiry, and maybe some other attributes attached to it. A scope, if you like. Or any other attributes. The client just gets the opaque token.
- The client then sends a request to a service provider, along with that token in the Authorization header.. The service provider needs to validate the token, then make a decision about whether to allow the request.
There are some variations in step 1 - specifically around what form the inbound credentials take, and how the token dispensary validates the inbound credentials. There are different “grant types” for these variations. But the successful output of step 1 is aways “a token”. It’s reusable for a certain period of time.
The thing you have to consider is, the token dispensary is not necessarily the same as the service provider. So, in Step 2, when the service provider validates the token, it may need to contact the token dispensary, in order to find out if the token is good, if it is expired, and so on. The use of a signed token, like a JWT, avoids the need for the service provider to connect with the token dispensary, for every request. If the system uses a signed token, the service provider can simply verify the signature on the token, and then trust the contents of the token. This is what people mean when they say that “JWT are self-validatable”. I don’t love that terminology because I think it isn’t very helpful. But it means the JWT contains real information, signed with a digital key. and, any holder of the signed JWT can open it, validate the signature, and then make authorization decisions based on the claims presented in it. This eliminates the hop from service provider to token dispensary, at runtime. But it does require the service provider to do a bunch of calculation (signature validation) for every request.
Apigee can exchange tokens. Apigee can accept an inbound token from a different token dispensary, and then generate an Apigee-native token. The client can then present that Apige-native token as an access token on subsequent requests for service. When Apigee validates an Apigee-native token it will be very fast, it will not involve signature verification or remote communication. Verifying an Apigee native token takes much less than 1 ms at scale. And so this may be preferable if yo uwant performance.
The bottom line is, you need an OAuthV2 with Operation=VerifyAccessToken in order to use Apigee as a token validator. And that will work with an Apigee-generated token. You can get that token by creating a /token endpoint that exchanges an external token for an Apigee-native one.
Google around to find examples of all of this.