The challenge I see with JWT token is the Client ID and other claims are signed with the token and sent back to the client. While the consumer cannot modify the token to add a different client Id, I am wondering if we can keep it abstract.
By my way of thinking the JWT is already abstract. The claims are visible to anyone that possesses the token, but the meaning of those claims is defined by the token verifier. For example, imagine a "scope" claim in the JWT payload. The meaning or semantics of any value in that claim would be determined by the server.
I like Access Tokens as they store the claims in server. I am wondering if there is a way to make access tokens common across all Apigee Organizations in Hybrid setup. That is, if Apigee GW1 generates an Access token and shared with the client, can another Apigee GW (GW2 - different Organization) accept the token and authorize user to access API, as long as Client ID is valid in this Org as well?
I think I understand what you're saying. It seems like an over-constrained problem. Here's what I mean. There are two types of access tokens we are discussing here, I think: opaque and JWT. Both are access tokens, both can have expiry, a client id, custom claims (like scope), issue time, issuer, and so on. The difference: the opaque token is really just a random string of characters that acts as a reference to information that is held by the token issuer, in its token database. The JWT holds the information itself.
- For the opaque token: No party except the token issuer can verify or validate the token (determine its validity). Basically the client app must send the token in, with a request-for-service, and the token issuer does a lookup of the token and determines if its good. Similarly, no party except the token issuer can understand the claims on the token.
- For the JWT: the token is open, and federatable. Any holder can look at the token, decode it, and understand all those claims. Any party can verify the token, given access to the public key that was used to sign the token.
In Apigee, a single organization can have many many distributed gateways, and they all share the same token database. So an opaque token issued by "GW1" can be later verified by "GW2", as long as both of these gateways are running in the same organization. Your scenario is different: GW1 and GW2 are in different organizations, which means they have distinct token databases, which means a token known by, and issued by, one organization, will not be known by or verifiable in, a second organization.
It sounds like you want the benefits of the federated token, but without the "visibility" that is implicit with the JWT format. What can you do?
One option is to... intercede an API facade between the client and the IdP, so that when the IDP generates a JWT, the API facade can intercept it, and ... *do something with it*... before sending back a different JWT access token to the original client. One simplistic option would be to ENCRYPT the original signed JWT and embed that as a claim into a new signed JWT. And then send back the second JWT to the client. This would obscure any claims in the original JWT.
The client could then present this new JWT to any gateway in any Apigee organization. Assuming the gateway has access to the PRIVATE or SECRET key that can decrypt the original signed JWT, then the Apigee gateway would be able to see all the claims in the original JWT, and would be able to grant authorization based on those claims.
Another option. Again use a facade, and have the Apigee facade issue an opaque token, store the original signed JWT as a hidden attribute, and embed the opaque token into a new signed JWT, along with a claim for "issuer", send that to client. Then the client can present that signed token to any Apigee gateway. The Apigee gateway can crack open the JWT, find the issuer, and connect to the issuer directly, to validate the token that is embedded in the JWT. This is similar to the first idea, except, it replaces the encryption with a synchronous connection to a gateway in the originating organization.
There are other options too, I'm sure.
LinkedIn
Twitter
