Add Custom Claims to JWT tokens.

[taaraora]

Hi, I wonder is it possible to add custom claims to JWT tokens. I want to attach user roles list to JWT token when user is authenticated.

[cainlevy]

There's currently no way for the app to inject data into AuthN's authentication process.

Can you say more about your use case? I prefer to check permissions on each request, so I don't personally have established patterns to recommend.

[taaraora]

Hi, I'm considering using Open Policy Agent as an authorization agent for microservices. When microservice receives API request I can just forward that request to OPA and it makes the authorization decision. Such an approach requires to distribute Roles information to each OPA agent also attach User roles list to each request. JWT work nicely in such case because I can just attach a list of roles to JWT token as custom claims.

[cainlevy]

related: #114

[cainlevy]

Apologies for not following up sooner. I'm not sure where to go with this yet.

My understanding of this proposal is that AuthN could save your Open Policy Agent a network request by including static roles in the identity token. Is that accurate?

When I try to generalize this solution to a broad number of use cases, I wonder:

• Will OPA sometimes need to load the user anyway for other information?
• Would the potentially saved network request be meaningful? My experience with authorization is that a decision can require bits of context about the user, the target resource, and even related resources. Pushing the decision into an external service could require loading a lot of context into that service.
• What if roles change? Effective user moderation sometimes involves revoking or suspending key privileges, and enforcement should not wait for the user's session to expire or reauthenticate.

[cainlevy]

⚠️ If anyone follows the OPA documentation and attempts to integrate a JWT as described then please don't rely on this process to establish trust. ⚠️

This is an incomplete list of flaws in the currently documented approach. Each could compromise your system:

• does not verify signature
• does not verify issuer
• does not verify intended audience
• does not check token expiration

[taaraora]

Apologies for not following up sooner. I'm not sure where to go with this yet.

My understanding of this proposal is that AuthN could save your Open Policy Agent a network request by including static roles in the identity token. Is that accurate?

When I try to generalize this solution to a broad number of use cases, I wonder:

• Will OPA sometimes need to load the user anyway for other information?
• Would the potentially saved network request be meaningful? My experience with authorization is that a decision can require bits of context about the user, the target resource, and even related resources. Pushing the decision into an external service could require loading a lot of context into that service.
• What if roles change? Effective user moderation sometimes involves revoking or suspending key privileges, and enforcement should not wait for the user's session to expire or reauthenticate.

• OPA needs to have enough data to make a decision, that is it. Of course, that requires extra logic which keeps OPA "cache" updated when a role or other decision critical data is changed.
• In my case, all token details verifications are done on API gateway, that means when token passes API Gateway it can be treated as trusted. I agree that such an approach exposes some potential internal attack surfaces.
• If decision-making data has been changed we just update OPA "cache", if token itself was revoked we should not pass such requests (in my case API gateway does it, but we can make service mesh verify that or use any other means).