How to verify access token on a dotnet core backend service?

[amitsharma]

Hello,

For my current project, I am using client credential grant to generate access token and protect Apigee Edge proxy api endpoint. As per the requirement, dotnet core backend api should also verifying the validity of the access token issued by Apigee. I could not find any article which explains on how to achieve this. So my questions is whether this is a correct approach to validate Apigee access token at backend api?

I am also exploring the the usage of JWT policies. However we are not sure how to link a client credentials grant with JWT policies and how to verify JWT at dotnet core backend api.

Please help.

Regards

Amit

[bhatikuldeep]

Since this access token is generated by apigee, your backend would have no knowledge about it, so I dont understand why do you not want to validate this token at apigee (since this your entry point) and want to do it your backend (which does not have any knowledge about this token)?

[dchiesa1]

As per the requirement, dotnet core backend api should also verifying the validity of the access token issued by Apigee.

That doesn't make a ton of sense. That requirement ought to be re-framed, re-considered. What's the business goal behind it?

However we are not sure how to link a client credentials grant with JWT policies

Read RFC7523. Also search for that term here on community.apigee.com. There are some concrete suggestions and examples.

[amitsharma]

Thanks Dino & @Kuldeep Bhati. After reading your comment, I feel the approach I am taking is not correct. The Apigee access token wont be useful. I am exploring the GenerateJWT policy. However I am facing another issue with this.

{ "fault": { "faultstring": "Failed to Resolve Variable : policy(JWT-Generate-RS256) variable(private.privatekey)", "detail": { "errorcode": "steps.jwt.FailedToResolveVariableException" } } }

I am storing the RSA key for JWT into KVM and have followed this article to configure the policy..

https://community.apigee.com/articles/57541/how-to-retrieve-keys-for-jwt-from-kvm.html

[dchiesa1]

That means, your policy with the name "JWT-Generate-RS256", references a variable that does not exist, has not been assigned a value.

It's impossible for us to know what that is. You can determine it though.

You will need to examine the policy configuration and methodically verify that each variable you reference, has been assigned. I suggest you simplify the generation - eliminate everything you can, and get the basic bare JWT to work. Then add in various claims (subject, issuer, etc) which may be derived from variables. At some point you will re-encounter the unresolved variable problem. That will tell you which variable is unresolveable.

[amitsharma]

Hi Dino, I have resolve this issue. I have successfully validate client_id and secret combination on a client_credential grant and have generate and returned a RSA JWT token. Thanks for your help

[bryanspackman]

@Amit Sharma and @Kuldeep Bhati I'm also very interested in how the backend service can validate the token generated by Apigee. The scenario I'm interested in is if somebody has the URL to your API Target endpoint (could be an internal person), then how do you prevent them by passing apigee proxy and hitting the target service directly?

[dchiesa1]

We recommend that the backend target endpoint enforce 2-way TLS, and insist that the CN on the client certificate be a specific value. The cert provisioned to Apigee Edge (for the keystore used in the target) will bear that CN. This will insure that only Apigee Edge can call the target.

BTW, yours is an entirely new question. In the future, please ask a new question, rather than asking a related question in an answer to an existing question.

[bryanspackman]

@Dino-at-Google ♦♦ does having a microgateway on prem complicate this approach at all?

What would be required in order to accommodate the microgateway with mutual TLS?

Many thanks in advance

[dchiesa1]

The same approach should work when connecting from the microgateway to the backend service. You need to insure the microgateway and the backend service have the right keys and certs provisioned to allow this transport-layer security.

And insure that the microgateway is physically secured, because .. any party that can physically access the microgateway machine, can get its keys and can then impersonate the microgateway over TLS.

[bryanspackman]

Thanks @Dino-at-Google ♦♦ That's very helpful!

I did think my question was completely in line with what was originally asked by Amit Sharma..."As per the requirement, dotnet core backend api should also verifying the validity of the access token issued by Apigee"