use jwt token + api key for authentication

Hello,

We are planning to use only jwt token for authentication on apigee gateway, but we find somes recommendations from Apigee experience engineer, to use both jwt+api key. so what's the recommendation for authentication on Apigee, using only jwt token without api key, if it's enough how we can keep the trace the products and apps usage on data analytic or we should use both jwt token and api key for all cases?

thanks

Solved Solved
0 1 783
1 ACCEPTED SOLUTION

Yes/no/both

I think of JWT as a JSON blob, encoded and then signed.  Within the JSON, there are "claims", just fields in the json hash.  These can identify things like:

  • the issuer of the JWT (who created it)
  • the subject of the JWT (who it is about) 
  • the intended audience (who is expected to look at it)  
  • the issue time
  • the expiry time
  • and literally ANYTHING else the issuer cares to put into the JSON .

Apigee has a builtin policy/step that can verify a signed JWT - it is called VerifyJWT.  Let's suppose you configure VerifyJWT with a source of a public key, maybe it's a JWKS endpoint.  After VerifyJWT successfully executes, you know that the owner of the public key signed the JWT.  And if you trust the owner of the public key, then you can trust the claims in the signed payload.  You can be assured that the issuer really was the issuer, and the claimed subject really is the subject. And so on. 

What does that get you in an Apigee API proxy?  Not much!  It just tells you that a remote issuer, issued a JWT, and it's not expired. 

As you are aware - and as you pointed out -  API Product authorization in Apigee,  and the analytics related to same... all depend on the client ID or client credential.  You need to perform either VerifyAPIKey or VerifyAccessToken in order to get that API Product goodness.  If you use only VerifyJWT, you don't get that. 

What people do is call FIRST VerifyJWT, and THEN VerifyAPIKey, to get that desired outcome. 

But does the client need to send the client_id separately?  Probably not.  Ideally the client_id is simply contained within the claims of the JWT.  So the client sends only the JWT.  VerifyJWT validates that, and extracts the client_id claim. Then VerifyAPIKey to validate the client_id. 

So you do both, but the client sends only one thing; the JWT. 

The trick to making this work is to synchronize the client_id in Apigee with the client_id that is embedded within the JWT, issued by the external issuer. That's easy to do - Apigee allows you to specify a client id when registering an app.  So you can just get the "3rd party provided" client id, and then tell Apigee to trust it.  

 

 

 

View solution in original post

1 REPLY 1

Yes/no/both

I think of JWT as a JSON blob, encoded and then signed.  Within the JSON, there are "claims", just fields in the json hash.  These can identify things like:

  • the issuer of the JWT (who created it)
  • the subject of the JWT (who it is about) 
  • the intended audience (who is expected to look at it)  
  • the issue time
  • the expiry time
  • and literally ANYTHING else the issuer cares to put into the JSON .

Apigee has a builtin policy/step that can verify a signed JWT - it is called VerifyJWT.  Let's suppose you configure VerifyJWT with a source of a public key, maybe it's a JWKS endpoint.  After VerifyJWT successfully executes, you know that the owner of the public key signed the JWT.  And if you trust the owner of the public key, then you can trust the claims in the signed payload.  You can be assured that the issuer really was the issuer, and the claimed subject really is the subject. And so on. 

What does that get you in an Apigee API proxy?  Not much!  It just tells you that a remote issuer, issued a JWT, and it's not expired. 

As you are aware - and as you pointed out -  API Product authorization in Apigee,  and the analytics related to same... all depend on the client ID or client credential.  You need to perform either VerifyAPIKey or VerifyAccessToken in order to get that API Product goodness.  If you use only VerifyJWT, you don't get that. 

What people do is call FIRST VerifyJWT, and THEN VerifyAPIKey, to get that desired outcome. 

But does the client need to send the client_id separately?  Probably not.  Ideally the client_id is simply contained within the claims of the JWT.  So the client sends only the JWT.  VerifyJWT validates that, and extracts the client_id claim. Then VerifyAPIKey to validate the client_id. 

So you do both, but the client sends only one thing; the JWT. 

The trick to making this work is to synchronize the client_id in Apigee with the client_id that is embedded within the JWT, issued by the external issuer. That's easy to do - Apigee allows you to specify a client id when registering an app.  So you can just get the "3rd party provided" client id, and then tell Apigee to trust it.