I have a scenario in which my IDP and authorization server is Okta. All the developer client's apps are going to be registered in Okta. They should get the JWT token from Okta based on the OAuth flow they select which can then be used to make a request to the proxy. We will use the verifyJWT policy to verify the token.
1) Is it still mandatory to create an app in Apigee to get all the proxies working?
Not mandatory. But there are implications!
Typically the Okta system will issue an ID token and an access token to the requesting client. When the client presents the access token to an API call that is being managed (proxied) by Apigee , the Apigee API proxy can validate the Okta access token to determine if it is valid (not expired) and signed by Okta. You can do this with VerifyJWT, pointing the PublicKey configuration to the JWKS endpoint for the Okta tenant.
But what would the result be? After VerifyJWT, your Apigee API proxy can be assured that the inbound client request bears a valid token issued by Okta. And that's it. The Apigee proxy wouldn't know anything else about the inbound call.
One of the central metaphors in Apigee is the API Product - this is the unit of API exposure. This is the entity in Apigee that enables API authorization, in other words a way for the API proxy to answer the question "Should I allow this client to make the API call it is requesting?" To enforce that check in Apigee, you use either VerifyAPIKey or OAuth2/VerifyAccessToken. The former request an API key (aka client ID) that is known by Apigee. The latter requires a token that was issued by Apigee.
In your case, you have neither. The token was issued by Okta. The client id (embedded in the token) was issued by Okta. Apigee has no way to relate that to a product. UNLESS, you import the Okta-generated client id into Apigee, and then enable that client on a specific API product. In that case you can call VerifyJWT (as I described above) then follow that with VerifyAPIKey, using the client ID extracted from the payload in the Okta-generated JWT. That would then get you API-product authorization checks in your proxy.
There are other options of course. One is to present a /token endpoint in Apigee that accepts an inbound JWT signed by Okta and responds with an Apigee-native token, in the pattern described by RFC 8693. We can call this pattern "token exchange". During the token exchange, the client presents the Okta-generated token and receives an APigee generated token. Before generating the token, the Apigee API proxy must verify the inbound JWT and the client ID. Then the token-granting proxy can use Oauth2/GenerateAccessToken to send back a new Apigee-generated token to the client. Thereafter, the client can send in API requests to Apigee with the Apigee-generated token, and the API proxy needs to use just OAuth2/VerifyAccessToken.
Both of these approaches require synchronizing the client IDs across Okta and Apigee.
2) I am hoping I can still make my product definitions in Apigee? and can use this product list through management APIs to assign products to Okta apps.
You can, if you synchronize the client ID's across Okta and Apigee. You need to take care that every client created within Okta is also present in Apigee, for this to work. And then also, insure that when a client is removed from Okta, it is also removed from Apigee.
LinkedIn
Twitter
