Replies: 7 comments 8 replies
-
|
It seems we already have some support for this, but not sure if it fully works for all mappers/claims. |
Beta Was this translation helpful? Give feedback.
-
|
@stianst Nice proposal. Few points and questions:
Does your proposal count with this option? Question is how to control what should be displayed for particular resource? For example for roles, it may be fine to count just with realm roles and/or client roles of the particular resource server? I can imagine the last point can also provide solution to the admin console issue with big number of realms (WhoAmI) among other things. |
Beta Was this translation helpful? Give feedback.
-
|
The lightweight access token could (and probably should) still be non-opaque, as that makes it possible to read some claims directly from the token. I would also argue that from an implementation perspective it's easier to start with a non-opaque standard JWT. Configuring lightweight access tokens is not a config option on a client directly, but rather you configure what client scopes / protocol mappers are added to the access token, and which are not. As a separate thing we can add support for encrypted access tokens, and then the lightweight access tokens can be combined with encrypted access tokens. |
Beta Was this translation helpful? Give feedback.
-
|
The introspection endpoint response should not differ based on what client is invoking it. In the example you're giving actually the roles that go into the client is defined by client1, not by LT1 or LT2, and regardless which resource server invokes the introspection endpoint it should return the same result. To have different results client1 should really have different tokens for the different resource servers, or token exchange should be used. |
Beta Was this translation helpful? Give feedback.
-
Ok. IMO protocol mappers suits better to this than client scopes as they already have similar flags available (EG.
Encrypted access tokens fits well into this IMO as nor the client or resource server needs to be able to read lightweight access token directly. Client has info about user claims from ID Token. Resource server can invoke either UserInfo or Introspection endpoint to receive the additional info (user claims or stuff like roles/web-origins). But +1 to consider encrypted access tokens as a follow-up. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, so first pass should be adding option to protocol mapper for sure, but was thinking perhaps a config option on a client scope would make sense as well. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with encrypted tokens fits nicely into this, but can imagine that folks would want:
Simplest to start with 1 ;) |
Beta Was this translation helpful? Give feedback.
-
|
There's a draft PR around a similar thing here: |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
#22148 is also a draft PR. |
Beta Was this translation helpful? Give feedback.
-
|
Could you tell me, is this already available for use in production? |
Beta Was this translation helpful? Give feedback.
-
|
Seems to have been released in version 24 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
From time to time there are use-cases that require something different to fully self-contained non-opaque access tokens. These include:
These can be solved with encrypted access tokens and/or reference tokens. However, these are both relatively complex:
An alternative to the above could be lightweight access tokens. A lightweight access token is a token that contains limited claims, and the information needed to be able to generate a full access token. This allows the token to be a happy middle ground between a opaque vs non-opaque token and a encrypted vs a signed token.
The general idea on how to support lightweight access tokens is to add an options to all protocol mappers to add claims to the access token or not, then a lightweight access token can be defined by controlling what claims are available in the access token, and available in userinfo or token introspection endpoints.
Examples of how to use:
One additional thing to consider here is who can invoke the token introspection and userinfo endpoint. The userinfo endpoint is not useful in cases of sensitive information as it can be invoked by anyone with a valid access token. The token introspection endpoint should only be possible to invoked by a confidential client that is included in the token audience.
To make it easier to use we may also want to be able to control how claims are included at the client scope level rather than on individual protocol mappers, as it can be error prone and complicated to update all protocol mappers for a client scope.
Beta Was this translation helpful? Give feedback.
All reactions