Enhancing Light Weight Token by skabano · Pull Request #22148 · keycloak/keycloak

skabano · 2023-08-01T09:58:32Z

Light Weight Token has been implemented in the following specifications.

About the value set by the TokenManager initToken in the access token
Create a new LightWeightAccessTokenMapper protocol mapper and removed the value.
The deleted value is set in AccessTokenIntrospectionProvider so that it can be retrieved by Introspection endpoint.
About the value set by the Protocol mapper to the access token
Removed the value from the access token by turning OFF the Add to access token for each protocol mapper.
Furthermore, by implementing the following more flexibility for Introspection endpoint, by turning ON the Add to token Introspection,
it is possible to obtain the value in Introspection endpoint.

More flexibility for Introspection endpoint
#21183

tnorimat · 2023-08-02T01:08:44Z

The discussion can be found in #9713 .
Its related discussion is Supporting reference access/refresh tokens.

cgeorgilakis · 2023-08-04T08:39:14Z

We believe that token introspection should return all access token information enhanced by mappers with token introspection equal to true.
So :

In ui allow to make Add to token introspection true only if Add to access token is false.
Token introspection endpoint will keep access token claims and enhance with claims with Add to token introspection true.

cgeorgilakis · 2023-08-04T09:43:59Z

I propose to add tests with most protocol mappers with Add to access token false and Add to token introspection false and true. Claims must be showed in token introspection only if Add to token introspection is true.

Moreover, add special case with Add to access token false and Add to token introspection true for Attribute Mapper for special access token cases ( offline access token, token from client credentials , token form OAuth token exchange).

cgeorgilakis · 2023-08-04T09:15:45Z

What is the scope of this mapper? Does it needed?
I believe that if implemented, logic to get access token from singleUseStore must be implemented to all OAuth -OIDC flows that access token is a query parameter. Fe UserInfo, refresh flow.
What happen in singleUseStore during Keycloak restart? This is important for offline access tokens.

Although we want support for lightway access token and enhance token introspection, we believe that there is no need to extra space for saving access token. Access token could have only needed information for Userinfo - token introspection, scope and other required claims based on OAuth specification.
This could support with appropritate protocol mappers ( Add to access token false and Add to token introspection true).

+1
I am also not very convinced if LightWeightAccessTokenMapper is needed.

Access token could have only needed information for Userinfo - token introspection, scope and other required claims based on OAuth specification.

+1 to that, however access token does not even need to have all required claims based on OAuth specification as OAuth/OIDC does not prescribe that access token must be JWT. Access token can be opaque token, not even JWT. So IMO it can be possible to even omit some JWT-required claims from access token, but it should be carefully considered which ones to support all the endpoints as you mentioned.

I agree.
I am reffering to JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens documentation. However, this discussion is out of scope of this PR.

@cgeorgilakis @mposolda I think that the intention of introducing LightWeightAccessTokenMapper is to hide such claims from an access token that a protocol mapper cannot control.

Also it seems that you are worry about putting a lot of information onto SingleUseObjectProvider.

IMO, the following claims are only available when Keycloak receives a token request from a client and generate an access token:

scope, nonce, jti, iat, exp, client_id, azp, session_state, iss(realm name), cnf (OAuth MTLS, DPoP)

Therefore, if we want not to put such claims onto an access token but want to put them onto a token introspection response, we need to keep them by some mechanism like SingleUseObjectProvider.

One option of a lightweight access token is that we must put all such claims to an access token. Another option is that we only put some of such claims to an access token and others are kept by using SingleUseObjectProvider by this LightWeightAccessTokenMapper . WDYT?

I see the idea behind the mapper but I don't think we need it at all. It makes more sense to do the opposite: provide specific mappers for those claims and then configure them accordingly.

For me, most of the claims being removed by this method are a key to accessing protected resources on a resource server. We can't be opinionated on which claims should go into the access token as it is use-case-specific. For some, you might need the subject in a lightweight token when accessing protected resources, or even the client to which the token was issued.

We should keep in mind that a lightweight token is just about making sure you have minimal claims to avoid introspecting tokens. The more claims you remove, the more your access token becomes a reference token instead, for which you are forced to introspect the token in order to resolve additional information at the resource server when processing bearer tokens.

I am reffering to JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens documentation.

You have a good point here and we should probably choose the basic claims a lightweight token should have based on this spec. It already provides the minimal set (similar to ID Token) of claims and that spec was based on feedback from different vendors and use cases.

cgeorgilakis · 2023-08-04T09:36:08Z

This code only needed if lightWeightAccessTokenMapper is enabled. Please move it in line 121 ( if (tokenData != null) { ).

In common cases lightway access token would be enabled using Add to token introspection field.
This information is containing to access token. So this code is dublicated.

One question is, if we need the LightweightAccessTokenMapper at all or if we can remove it from this PR as mentioned in the other threads? I am not 100% sure about it... If not needed, then we can remove this code altogether from this PR.

We do not want this mapper. @mposolda you should decide about having it.

mposolda · 2023-08-08T09:45:15Z

Sign in to view

Good catch.

It is possible it may be needed to extract some methods from UserInfoEndpoint (or other classes) to deal with transient user sessions to some generic util class?

I agree. We can make UserInfoEndpoint.findValidSession public or move it to util class

UserInfoEndpoint.findValidSession has been Utilized (UserSessionUtil) so that it can also be referenced by the AccessTokenIntrospectionProvider.

UserInfoEndpoint.findValidSession has been Utilized (UserSessionUtil) so that it can also be referenced by the AccessTokenIntrospectionProvider.

Now it is correct. I only believe that we should catch method errors and together with user being null return null in this method.
So token introspection will return false - not exception.

mposolda

I've added few comments inline. Some more comments here:

I am not 100% sure if we need LightweightAccessTokenMapper class? I guess that using this functionality and storing tokens in the "singleUseStore" has additional price-to-pay and also additional places where it would need to be handled as mentioned by @cgeorgilakis. So far, I vote for removing it from this PR and also removing related code from AccessTokenIntrospectionProvider. But I am curious for more opinions here...
We need to handle backwards compatibility. In previous version, all claims from access token were added to introspection response. So:
- It will be good if Include in Introspection endpoint switch is ON by default for all protocol mappers where Include in access token is ON by default.
- Will be good to handle protocol mappers in all built-in client scopes (added by OIDC protocol factory) and pre-configured scopes
- I guess that method public static ProtocolMapperModel createClaimMapper(String name, String userAttribute, String tokenClaimName, String claimType, boolean accessToken, boolean idToken, boolean userinfo, String mapperId)
  can be good to update, so it has also boolean parameter boolean introspectionEndpoint as parameter
  and the other methods can call this with same value like they use for accessToken?
- Also I guess that method OIDCAttributeMapperHelper.includeInIntrospection can be updated to handle backwards compatibility in similar way like we use in OIDCAttributeMapperHelper.includeInUserInfo()? I guess something like:

    public static boolean includeInIntrospection(ProtocolMapperModel mappingModel) {
        String includeInIntrospection = mappingModel.getConfig().get(INCLUDE_IN_INTROSPECTION);

        // Backwards compatibility
        if (includeInIntrospection == null && includeInAccessToken(mappingModel)) {
            return true;
        }
        
        return "true".equals(includeInIntrospection);
    }

It can be very nice if admin console shows this switch ON by default in case that value is not present

mposolda · 2023-08-08T09:41:13Z

+1
I am also not very convinced if LightWeightAccessTokenMapper is needed.

Access token could have only needed information for Userinfo - token introspection, scope and other required claims based on OAuth specification.

+1 to that, however access token does not even need to have all required claims based on OAuth specification as OAuth/OIDC does not prescribe that access token must be JWT. Access token can be opaque token, not even JWT. So IMO it can be possible to even omit some JWT-required claims from access token, but it should be carefully considered which ones to support all the endpoints as you mentioned.

mposolda · 2023-08-08T09:45:15Z

Good catch.

It is possible it may be needed to extract some methods from UserInfoEndpoint (or other classes) to deal with transient user sessions to some generic util class?

mposolda · 2023-08-08T09:55:43Z

One question is, if we need the LightweightAccessTokenMapper at all or if we can remove it from this PR as mentioned in the other threads? I am not 100% sure about it... If not needed, then we can remove this code altogether from this PR.

mposolda · 2023-08-08T15:44:58Z

I propose to add tests with most protocol mappers with Add to access token false and Add to token introspection false and true. Claims must be showed in token introspection only if Add to token introspection is true.

Moreover, add special case with Add to access token false and Add to token introspection true for Attribute Mapper for special access token cases ( offline access token, token from client credentials , token form OAuth token exchange).

+1

mposolda · 2023-08-08T15:51:43Z

We believe that token introspection should return all access token information enhanced by mappers with token introspection equal to true. So :
* In ui allow to make _Add to token introspection_  true only if  _Add to access token_ is false.

* Token introspection endpoint will keep access token claims and enhance with claims with _Add to token introspection_ true.

@cgeorgilakis I think that switch Add to introspection should be shown even if Add to access token is ON. It will be good to always show Add to introspection IMO, so it is clear what claims would be included in introspection response. At the same time, I agree that we need to handle backwards compatibility with previous version, which I've mentioned in the other comment.

One additional point: I guess that some clients in the realm may want lightweight access tokens, when some other clients may not. But due the fact that Add to access token is defined on protocol mappers inside client scopes, it may be then required that clients with lightweight tokens would need to use different client scopes. Due to this, I was thinking about "Client policy executor", which will hide everything from access token even if Add to access token is ON in protocol mappers. See here for the details: #19649 (comment) (In the Client Policy Executor section). On the other hand, I am not 100% convinced if this client policy executor is a hack or not, as it makes things a bit more complex...

But anyway, I vote for Add to introspection to be shown always.

mposolda · 2023-08-08T15:52:30Z

@tnorimat Could you please review as well, unless you did already?

tnorimat · 2023-08-09T07:50:21Z

@mposolda Yes, I will review the PR.

cgeorgilakis · 2023-08-22T09:19:59Z

We believe that token introspection should return all access token information enhanced by mappers with token introspection equal to true. So :
* In ui allow to make _Add to token introspection_  true only if  _Add to access token_ is false.

* Token introspection endpoint will keep access token claims and enhance with claims with _Add to token introspection_ true.
@cgeorgilakis I think that switch Add to introspection should be shown even if Add to access token is ON. It will be good to always show Add to introspection IMO, so it is clear what claims would be included in introspection response. At the same time, I agree that we need to handle backwards compatibility with previous version, which I've mentioned in the other comment.

One additional point: I guess that some clients in the realm may want lightweight access tokens, when some other clients may not. But due the fact that Add to access token is defined on protocol mappers inside client scopes, it may be then required that clients with lightweight tokens would need to use different client scopes. Due to this, I was thinking about "Client policy executor", which will hide everything from access token even if Add to access token is ON in protocol mappers. See here for the details: #19649 (comment) (In the Client Policy Executor section). On the other hand, I am not 100% convinced if this client policy executor is a hack or not, as it makes things a bit more complex...

But anyway, I vote for Add to introspection to be shown always.

I prefer to use different custom scopes for the cases described.
However, you could add this client executor as separate PR.

skabano · 2023-09-06T01:59:32Z

I propose to add tests with most protocol mappers with Add to access token false and Add to token introspection false and true. Claims must be showed in token introspection only if Add to token introspection is true.

Moreover, add special case with Add to access token false and Add to token introspection true for Attribute Mapper for special access token cases ( offline access token, token from client credentials , token form OAuth token exchange).

Added a test case for the above viewpoint to LightWeightAccessTokenMapperTest.

skabano · 2023-09-06T02:11:55Z

I've added few comments inline. Some more comments here:

I am not 100% sure if we need LightweightAccessTokenMapper class? I guess that using this functionality and storing tokens in the "singleUseStore" has additional price-to-pay and also additional places where it would need to be handled as mentioned by @cgeorgilakis. So far, I vote for removing it from this PR and also removing related code from AccessTokenIntrospectionProvider. But I am curious for more opinions here...

We need to handle backwards compatibility. In previous version, all claims from access token were added to introspection response. So:

It will be good if Include in Introspection endpoint switch is ON by default for all protocol mappers where Include in access token is ON by default.

Will be good to handle protocol mappers in all built-in client scopes (added by OIDC protocol factory) and pre-configured scopes

I guess that method public static ProtocolMapperModel createClaimMapper(String name, String userAttribute, String tokenClaimName, String claimType, boolean accessToken, boolean idToken, boolean userinfo, String mapperId)
can be good to update, so it has also boolean parameter boolean introspectionEndpoint as parameter
and the other methods can call this with same value like they use for accessToken?

Also I guess that method OIDCAttributeMapperHelper.includeInIntrospection can be updated to handle backwards compatibility in similar way like we use in OIDCAttributeMapperHelper.includeInUserInfo()? I guess something like:
    public static boolean includeInIntrospection(ProtocolMapperModel mappingModel) {
        String includeInIntrospection = mappingModel.getConfig().get(INCLUDE_IN_INTROSPECTION);

        // Backwards compatibility
        if (includeInIntrospection == null && includeInAccessToken(mappingModel)) {
            return true;
        }
        
        return "true".equals(includeInIntrospection);
    }
It can be very nice if admin console shows this switch ON by default in case that value is not present

A boolean introspection was added to the createClaimMapper and create methods of the protocol mapper, and the introspection setting value was set to be the same as the accessToken.

In order to maintain OIDCAttributeMapperHelper's includeIntrospection backwards compatibility, if nothing is set, the value of includeInAccessToken is returned.

skabano · 2023-09-06T02:18:50Z

In the case of client credential flow, the session becomes TRANSIENT and the sid is set to null in the processing of the tokenEndpoint after the protocol mapper, so I tried not to set it to SingleUseStore here.　Also, since sub is required to get a TRANSIENT session with findValidSession of the introspection endpoint, it is now set to SingleUseStore.

tnorimat · 2023-09-06T03:35:07Z

@cgeorgilakis @mposolda The points you've mentioned are treated. Could you check the revised PR?

cgeorgilakis · 2023-09-06T14:04:01Z

I believe that it is good not showing such changes in PR

cgeorgilakis · 2023-09-07T06:46:52Z

This is the verifyAccessToken method except the return statement.
I propose create a new method used here and in verifyAccessToken method.
If verification failed now Keycloak return false. With your code an exception will be thrown.
I believe that we should keep same behaviour and return here null.

cgeorgilakis · 2023-09-07T09:06:16Z

@cgeorgilakis @mposolda The points you've mentioned are treated. Could you check the revised PR?

I believe that PR has been improved a lot. Thanks @skabano for the tests.
I believe that the needed improvements are :

Return false (not exception) for failed verification/ problem with user session - as Keycloak does now. User must know if token is valid not the exception. For sure TOKEN_INTROSPECTION_ERROR needs improvemnt for knowing the cause of false. Maybe a new PR after accepting it.
Do not add not needed changes in imports.

See my comments for details.
What do you believe @tnorimat @mposolda ?

skabano · 2023-09-08T09:11:06Z

I believe that the needed improvements are :

Return false (not exception) for failed verification/ problem with user session - as Keycloak does now. User must know if token is valid not the exception. For sure TOKEN_INTROSPECTION_ERROR needs improvemnt for knowing the cause of false. Maybe a new PR after accepting it.

Do not add not needed changes in imports.

I've fixed the above point.

cgeorgilakis · 2023-09-08T09:33:08Z

I believe that the needed improvements are :

Return false (not exception) for failed verification/ problem with user session - as Keycloak does now. User must know if token is valid not the exception. For sure TOKEN_INTROSPECTION_ERROR needs improvemnt for knowing the cause of false. Maybe a new PR after accepting it.

Do not add not needed changes in imports.

I've fixed the above point.

Thanks.
Moreover related to possible introspection problems:

See my comment in order to return false json for VerificationException .
User endpoint check also for null User in not null UserSession. I do not know if it could be happen.

skabano · 2023-09-11T06:13:51Z

@cgeorgilakis
Let me confirm your opinion.

See my comment in order to return false json for VerificationException .

The findValidSession method throws the error if an error occurs. So, create a method (verifyAccessToken) to check in advance before calling findValidSession method. If token is not valid, transformAccessToken returns null. Is this correct?

User endpoint check also for null User in not null UserSession. I do not know if it could be happen.

Are you saying that the User endpoint should make similar changes to TokenIntrospection?
If that is the case, the behavior will change and backward compatibility cannot be maintained, so I think it is better not to do it.

cgeorgilakis · 2023-09-11T07:44:52Z

@cgeorgilakis Let me confirm your opinion.

See my comment in order to return false json for VerificationException .

The findValidSession method throws the error if an error occurs. So, create a method (verifyAccessToken) to check in advance before calling findValidSession method. If token is not valid, transformAccessToken returns null. Is this correct?

verifyAccessToken method exists in AccessTokenIntrospectionProvider class and lines 107 -118 is similar to your code in new lines122-124. Create a private method to be used in your method and verifyAccessToken method.
Return immediatly null and not throws VerificationException. accessToken in new line 77 will be null. So {"active":false} will be returned. This is the current response in Keycloak for VerificationException.
Maybe you could find a better code solution. For sure result must be same as current Keycloak behaviour.

User endpoint check also for null User in not null UserSession. I do not know if it could be happen.

Are you saying that the User endpoint should make similar changes to TokenIntrospection? If that is the case, the behavior will change and backward compatibility cannot be maintained, so I think it is better not to do it.

I am reffering to line 235 of UserInfoEndpoint class. I wonder if we need also this check in token introspection. @mposolda what do you believe for this?

skabano · 2023-09-11T09:36:39Z

verifyAccessToken method exists in AccessTokenIntrospectionProvider class and lines 107 -118 is similar to your code in new lines122-124. Create a private method to be used in your method and verifyAccessToken method. Return immediatly null and not throws VerificationException. accessToken in new line 77 will be null. So {"active":false} will be returned. This is the current response in Keycloak for VerificationException. Maybe you could find a better code solution. For sure result must be same as current Keycloak behaviour.

I am reffering to line 235 of UserInfoEndpoint class. I wonder if we need also this check in token introspection. @mposolda what do you believe for this?

@cgeorgilakis

Thank you. My understanding was wrong.
Correction completed.

cgeorgilakis · 2023-09-11T09:44:05Z

So, the PR is ok for me.

ghost

Unreported flaky test detected, please review

ghost · 2023-10-09T10:42:44Z

Unreported flaky test detected

If the below flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.ui.account2.SessionTest#welcomeScreenSsoTimeoutTest

Keycloak CI - Account Console IT (chrome)

org.openqa.selenium.NoSuchElementException: 
no such element: Unable to locate element: {"method":"css selector","selector":"#username"}
  (Session info: headless chrome=117.0.5938.132)
For documentation on this error, please visit: http://seleniumhq.org/exceptions/no_such_element.html
Build info: version: '3.14.0', revision: 'aacccce0', time: '2018-08-02T20:19:58.91Z'
...

Report flaky test

Closes keycloak#21183

ghost

Unreported flaky test detected, please review

ghost · 2023-10-12T14:31:52Z

Unreported flaky test detected

If the below flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.x509.X509BrowserCRLTest#loginSuccessWithCRLSignedWithIntermediateCA3FromTruststore

Keycloak CI - FIPS IT (non-strict)

java.lang.RuntimeException: Could not create statement
	at org.jboss.arquillian.junit.Arquillian.methodBlock(Arquillian.java:313)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
...

Report flaky test

mposolda

@skabano Thanks for the updates! Hope you are very close to have this in - especially since tests are ok.

Replied to your comment and added one more comment.

mposolda · 2023-10-13T09:34:43Z

@@ -0,0 +1,691 @@
+{


Is it possible to remove this file from your PR and make sure that the Lightweight token test is based on the default file from testsuite/integration-arquillian/tests/base/src/test/resources/testrealm.json ? It looks that there are almost no changes between your file and the basic testsuite file. If any modifications are needed in the test, it is possible to either add them to the LightWeightAccessTokenTest.addTestRealms method (you already did some modifications here) or use admin client and update before/after particular test methods.

Sorry I missed this in previous reviews (if it was present). Having many various testrealm-*.json files means bigger work in the future when some testsuite maintenance is needed, so it is good to avoid adding more such files unless really needed.

I removed mapper-test/testrealm.json and added it to addTestRealms.

mposolda · 2023-10-13T09:40:20Z

+1 to your proposal and to the PR https://github.com/Hitachi/keycloak/pull/431/files .

One question: Did you manually check if migration work as expected? It can be good to verify. The steps are:

Start some older Keycloak (maybe 22.0.4) configured against some DB (for instance MySQL)

Stop the Keycloak 22.0.4 server

Start the Keycloak server built with your PR configured against same DB as was used in step 1

Make sure that access token obtained contains "web origins" and "audience" as expected. It can be verified for instance in the admin console by showing any random client (EG. account-console) and then going to tab Client Scopes and subtab evaluate of that client.

Closes keycloak#21183

skabano · 2023-10-17T08:15:02Z

@mposolda
#22148 (comment)
Thank you for your comment.
I ran a migration test to make sure the access token contains "allowed-origins" and "aud".
Merged PR https://github.com/Hitachi/keycloak/pull/431/files.

mposolda · 2023-10-17T11:14:15Z

@skabano Thanks a lot and congratulations to your 1st great contribution! It was quite a long journey and quite a few challenges, but appreciate your patience.

@cgeorgilakis @tnorimat @pedroigor Thanks everyone for participate in the discussion on this PR

Closes keycloak#22148

cgeorgilakis reviewed Aug 2, 2023

View reviewed changes

Comment thread common/src/main/java/org/keycloak/common/Profile.java Outdated

skabano force-pushed the light-weight-token branch from 5b813f9 to fec60ab Compare August 3, 2023 02:02

cgeorgilakis suggested changes Aug 4, 2023

View reviewed changes

mposolda reviewed Aug 8, 2023

View reviewed changes

mposolda self-assigned this Aug 8, 2023

mposolda requested a review from tnorimat August 8, 2023 15:52

skabano commented Sep 6, 2023

View reviewed changes

cgeorgilakis reviewed Sep 6, 2023

View reviewed changes

cgeorgilakis reviewed Sep 7, 2023

View reviewed changes

skabano force-pushed the light-weight-token branch from c106ffb to ea9fd82 Compare September 8, 2023 09:01

skabano force-pushed the light-weight-token branch from ea9fd82 to 8fc7754 Compare September 8, 2023 09:41

skabano force-pushed the light-weight-token branch from 8fc7754 to eec911a Compare September 11, 2023 09:31

This was referenced Oct 6, 2023

Flaky test: org.keycloak.testsuite.model.infinispan.CacheExpirationTest#testCacheExpiration #23769

Closed

Flaky test: org.keycloak.testsuite.ui.account2.DeviceActivityTest#signOutTest #20915

Closed

ghost reviewed Oct 9, 2023

View reviewed changes

skabano force-pushed the light-weight-token branch from 6b0761d to 89ca1e9 Compare October 10, 2023 01:31

skabano force-pushed the light-weight-token branch from 89ca1e9 to d139f2d Compare October 10, 2023 04:59

skabano added a commit to Hitachi/keycloak that referenced this pull request Oct 10, 2023

Enhancing Light Weight Token(keycloak#22148)

106bee9

Closes keycloak#21183

skabano force-pushed the light-weight-token branch from d139f2d to 106bee9 Compare October 10, 2023 08:50

ghost mentioned this pull request Oct 12, 2023

Flaky test: org.keycloak.testsuite.federation.ldap.LDAPProvidersFullNameMapperTest#testUpdatingAttributesWorksEvenWithEmptyAttributes #23804

Closed

ghost reviewed Oct 12, 2023

View reviewed changes

mposolda reviewed Oct 13, 2023

View reviewed changes

Enhancing Light Weight Token(keycloak#22148)

d30ec82

Closes keycloak#21183

skabano force-pushed the light-weight-token branch from c602789 to d30ec82 Compare October 17, 2023 08:00

mposolda approved these changes Oct 17, 2023

View reviewed changes

mposolda merged commit 6112b25 into keycloak:main Oct 17, 2023

skabano deleted the light-weight-token branch October 18, 2023 01:03

mhajas mentioned this pull request Oct 18, 2023

Document or avoid breaking change in UserSessionModel #24096

Closed

2 tasks

cgeorgilakis pushed a commit to eosc-kc/keycloak that referenced this pull request Oct 25, 2023

Enhancing Light Weight Token

f87e685

Closes keycloak#22148

cgeorgilakis pushed a commit to eosc-kc/keycloak that referenced this pull request Oct 31, 2023

Enhancing Light Weight Token

2355462

Closes keycloak#22148

patrickjennings mentioned this pull request Nov 13, 2023

Mapper Option "Add to access token" Toggled Off Despite Claim Added to Token #24718

Closed

1 task

EvgeniGordeev mentioned this pull request Nov 30, 2023

Access token received in token-exchange direct naked impersonation does not work with userinfo endpoint #17668

Open

2 tasks

Conversation

skabano commented Aug 1, 2023

Uh oh!

tnorimat commented Aug 2, 2023

Uh oh!

Uh oh!

cgeorgilakis commented Aug 4, 2023

Uh oh!

cgeorgilakis commented Aug 4, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mposolda Aug 8, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pedroigor Sep 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as resolved.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cgeorgilakis Sep 7, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mposolda left a comment

Choose a reason for hiding this comment

Uh oh!

mposolda Aug 8, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mposolda commented Aug 8, 2023

Uh oh!

mposolda commented Aug 8, 2023

Uh oh!

mposolda commented Aug 8, 2023

Uh oh!

tnorimat commented Aug 9, 2023

Uh oh!

cgeorgilakis commented Aug 22, 2023

Uh oh!

skabano commented Sep 6, 2023

Uh oh!

skabano commented Sep 6, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnorimat commented Sep 6, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cgeorgilakis Sep 7, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mposolda Aug 8, 2023 •

edited

Loading

pedroigor Sep 15, 2023 •

edited

Loading

cgeorgilakis Sep 7, 2023 •

edited

Loading

mposolda Aug 8, 2023 •

edited

Loading

cgeorgilakis Sep 7, 2023 •

edited

Loading

cgeorgilakis commented Sep 8, 2023 •

edited

Loading

skabano commented Oct 17, 2023 •

edited

Loading