In the proxies we are creating,we generally implement OAuth with client credentials as grant type.This way we are protecting the API.Also,we have one way ssl and API key verification with consumer.
In one of our backend application,already OAuth is implemented with client credentials as grant type.
So,now if we have OAuth at APIGEE and OAuth at backend as well,Consumer has to pass client credentials to APIGEE for the OAuth at proxy and APIGEE has to pass client credentials to backend for the OAuth at backend.But for some reason,our security team does not want us to store any credentials at APIGEE layer.
So,consumer has to pass two client credentials for making OAuth at APIGEE and backend.
How this design can be simplified?
Is it suggestable to skip OAuth at APIGEE layer and have as Two-way SSL and API Key validation?
Please suggest.
2 Likes
Apigee Edge is a flexible platform so you have lots of options, like the ones that you mention. In your case, the simplest option for those API calls would be to skip token validation in Apigee and pass the credentials back to the back end.
However, if you do that then you end up having your users juggle two tokens – one for the API calls that are authenticated via API, and the other for the API calls that are authenticated by your back end. That’s not a great user experience.
It might be possible (for instance, using a Java callout or Node.js) to encrypt the back end token and store it in Apigee, perhaps by attaching it to the Apigee access token. That might alleviate the security concerns and result in a more usable API. Have you considered trying to do that?
1 Like
Thanks @Greg Brail for your response.Security team concerns no token/any sensitive data storage even with encryption.
BTW,when we skip OAuth at APIGEE and have only API Key validation and Two-way TLS with consumer,the consumer has to send access token to only backend for the validation.So,here there is only one token coming into play.How are you saying two token?Please clarify.
I got the impression from your question that you had some API calls that required an access token on your back end, but others that did not, which is why you wanted to check the access token at Apigee. So in that case the user would have to juggle two tokens.
If that’s not the case then that’s not a concern.
But for some reason,our security team does not want us to store any credentials at APIGEE layer.
This does not make sense to me.
Apigee is already storing credentials. If you implement client_credentials grant_type, then Apigee is storing and managing credentials.
@RK4
2 - way SSL can be used if storage is not allowed but am finding it strange that backend service’s credentials are sent by consumer, ideally consumer should be responsible for sending their own credentials.
@Dino
Actually,we are passing client credentials from consumer to external system which validates the client credentials and generates access token.So,we are not storing credentials at APIGEE.
So,consumer passes their credentials for OAuth call at APIGEE to External system.
Then from APIGEE to backend,we need to pass credentials from APIGEE to backend.This is where question arises.Whether we can store credentials in APIGEE?Is yes,is it Baas or KeyValue Map or any other better solution?
If Security team is really concerned,then whether we can ask consumer itself to pass credentials for OAuth call with backend?
yes, I still do’t understand what you’re doing or why it would work that way.
A client passes credentials to Apigee Edge. Apigee Edge passes them to an external system to generate an access token. Apigee Edge also passes credentials (not the generated token!) to the backend.
Why is Apigee Edge involved at all? I’m sure I don’t understand. But maybe it’s not necessary for me to understand.
in any case… If I were storing all these secrets, I’d want to use a secure store, like the Apigee Edge vault.
Good luck!
You could use an encrypted KVM to store the backend client_id and client_secret as a configuration setup using the Apigee Edge client_id and client_secret as keys. Then just extract and set backend target header values.
Granted your still storing credentials in Edge, but they are encrypted and under control via management APIs.
1 Like