How can I use Edge to use a JWT as the value of the OAuth token?

[kurtkanaskie]

Given Apigee's support for JWT generation as discussed here, is it reasonable to use JWT as the value of the OAuth token rather than the opaque tokens?

I can imagine the steps:

1. Validate Client ID and Secret
2. Generate the JWT
3. Use the JWT as the value as per Using Third-Party OAuth Tokens.

Has anyone done this?

[DChiesa]

I don't understand the use case. The last step - "use it as the value" ?? What value? Do you mean "the value of an attribute within OAuthV2/GenerateAccessToken ?

If so, then I'd say no, I don't think it's reasonable to do that.

JWT support federated verification. Opaque OAuth tokens support centralized verification. There's no need to insert an independently verifiable JWT into a token store. None.

Why would you want to do that?

[kurtkanaskie]

I updated step #3. Perhaps the better question is "is there a use case to use a JWT as the value of an OAuth token?".

For example, just as Open ID Connect providers (Azure, SalesForce, etc.) use a JWT as an access token, I'm wondering if there is a use case to configure Edge to use a JWT for the value of its access token.

Using it as the value of the access token may provide faster validation using OAuth V2 - VerifyAccessToken policy than using Verify JWT policy.

Since a JWT carries information (claims, subject, aud, etc.), it could be passed to other systems to convey information or to "support federated verification".

I have seen situations where the backend system requires a JWT as a form a request validation and to convey information.

Does that help?

[DChiesa]

I think Azure, SFDC use OpenID Connect to distribute tokens, both access tokens and id tokens. The access tokens as far as I have seen, are opaque tokens. The id_tokens are JWT.

Using a JWT as a value of an access token presumably would provide faster validation, as you say. But ...why? Why not just use a regular access token?

Using the JWT to convey signed information is fine, but why use the set of signed claims as an access_token? You could do that if you wanted to. The OpenID Specification keeps those two things - access_token and id_token - separate. See here.

I have seen some customers who design their API Proxies to create a new signed JWT for every request , to pass information to backend systems. The JWT is created by the API Proxy though; just a signed set of claims. It is not an id_token obtained from an OpenID Connect flow.