Hi guys, we’re experiencing issues about JWT access_token size and we were planning to remove the “roles” claim as a default, so to remove the claim from the access_token. Once we do that, the KC adapter / policy enforcer returns a 403. So at this point, does the access_token must have the roles inside it? Or it’s another problem which is giving us the 403? Thank you! Matteo -- Like <https://www.facebook.com/cuebiq/> I Follow <https://twitter.com/Cuebiq>I Connect <https://www.linkedin.com/company/cuebiq> This email is reserved exclusively for sending and receiving messages inherent working activities, and is not intended nor authorized for personal use. Therefore, any outgoing messages or incoming response messages will be treated as company messages and will be subject to the corporate IT policy and may possibly to be read by persons other than by the subscriber of the box. Confidential information may be contained in this message. If you are not the address indicated in this message, please do not copy or deliver this message to anyone. In such case, you should notify the sender immediately and delete the original message. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Hi Pedro, thank you for your reply. No, i wasn't the one who requested the feature, anyway i'm still interested into it. Our use case includes several microservices (which represents modules of our PaaS) which performs authorization checks against realm based roles. Every microservices has each own client containing its authorization checks.

Besides the PR (which is really really interesting and i hope it will be included in further releases), what are your recommendations to reduce the access token size? I'm asking this because in some browsers there are limits (4KB) about cookies & headers length. I can imagine those solutions: - Keep the token "light" and perform a token exchange into our gateway once we receive the token from the single page application, in order to retrieve a new token with all the realms roles associated to the user

- Use some particular mode of the adapter which will do the necessary to retrieve the roles (but i can't find something like that in the docs)

- Use RPT? Once the gateway receives the access token, perform the RPT request to retrieve a token with all the permissions for the particular client

- Something else unknown to us? :)

Have you ever faced this kind of problem?

Thank you again, Matteo On Mon, Nov 11, 2019 at 1:20 PM Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > We had a PR [1] for addressing this use case but it was closed due to not > enough quorum to support the changes. > > While we should keep policy enforcement based on the state carried by > tokens, I see as an improvement to also allow users, on a per-use case > basis, to fetch roles directly from the realm instead, even if they are not > available in the token. > > I can't remember now, but I'm wondering if was you that first requested > this so I ended up working on these changes? > > Regards. > Pedro Igor > > [1] https://github.com/keycloak/keycloak/pull/6163 > > On Mon, Nov 11, 2019 at 5:43 AM Matteo Restelli <mrestelli(a)cuebiq.com&gt; > wrote: > >> Hi guys, >> we’re experiencing issues about JWT access_token size and we were >> planning >> to remove the “roles” claim as a default, so to remove the claim from the >> access_token. Once we do that, the KC adapter / policy enforcer returns a >> 403. So at this point, does the access_token must have the roles inside >> it? >> Or it’s another problem which is giving us the 403? >> >> Thank you! >> Matteo >> >> -- >> >> Like <https://www.facebook.com/cuebiq/> I Follow >> <https://twitter.com/Cuebiq>I Connect >> <https://www.linkedin.com/company/cuebiq> >> >> >> This email is reserved >> exclusively for sending and receiving messages inherent working >> activities, >> and is not intended nor authorized for personal use. Therefore, any >> outgoing messages or incoming response messages will be treated as >> company >> messages and will be subject to the corporate IT policy and may possibly >> to >> be read by persons other than by the subscriber of the box. Confidential >> information may be contained in this message. If you are not the address >> indicated in this message, please do not copy or deliver this message to >> anyone. In such case, you should notify the sender immediately and >> delete >> the original message. >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > Like <https://www.facebook.com/cuebiq/> I Follow <https://twitter.com/Cuebiq>I Connect <https://www.linkedin.com/company/cuebiq> This email is reserved exclusively for sending and receiving messages inherent working activities, and is not intended nor authorized for personal use. Therefore, any outgoing messages or incoming response messages will be treated as company messages and will be subject to the corporate IT policy and may possibly to be read by persons other than by the subscriber of the box. Confidential information may be contained in this message. If you are not the address indicated in this message, please do not copy or deliver this message to anyone. In such case, you should notify the sender immediately and delete the original message.

On Mon, Nov 11, 2019 at 4:17 PM Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > > On Mon, Nov 11, 2019 at 10:40 AM Matteo Restelli <mrestelli(a)cuebiq.com&gt; > wrote: > >> Hi Pedro, >> thank you for your reply. >> No, i wasn't the one who requested the feature, anyway i'm still >> interested into it. Our use case includes several microservices (which >> represents modules of our PaaS) which performs authorization checks against >> realm based roles. Every microservices has each own client containing its >> authorization checks. >> > > Interesting, another use-case then ... > Yeah, we've separated authorization inside each backend client, in order to better separate authorization requirements. Each microservice will then validate and refer to its own authorization requirements. The frontend client, instead, is a single public client which receives the complete lists of roles (since they're defined at realm level) > > >> Besides the PR (which is really really interesting and i hope it will be >> included in further releases), what are your recommendations to reduce the >> access token size? I'm asking this because in some browsers there are >> limits (4KB) about cookies & headers length. I can imagine those solutions: >> >> - Keep the token "light" and perform a token exchange into our gateway >> once we receive the token from the single page application, in order to >> retrieve a new token with all the realms roles associated to the user >> > > The price you pay is a round-trip to the server. But it works ... > Yeah and i want to completely avoid that, in order to avoid to be "bottlenecked" by Keycloak > > >> - Use some particular mode of the adapter which will do the necessary to >> retrieve the roles (but i can't find something like that in the docs) >> > > Roles are gathered from the token, always ... > Yeah, i just saw it debugging the keycloak code locally... :( > > >> - Use RPT? Once the gateway receives the access token, perform the RPT >> request to retrieve a token with all the permissions for the particular >> client >> > > The beauty of the RPT is that the permissions should be enough as the > server already granted them based on the state of the current session. > Resource-based permissions also decouple applications from access control > mechanisms so that you have more flexibility and control over the policies > that govern access to your resources. > > It should not be seen as *the* solution for large tokens though ... > > >> - Something else unknown to us? :) >> > > Maybe use a mapper or don't include tokens by default in your token. So > that your client requests what he needs (yeah, more coupling between your > clients + resource servers). The client scopes functionality is very > interesting in this context given that you can set-up a scope that spans > multiple roles, on a per-application basis. > > >> >> Have you ever faced this kind of problem? >> > > Another user reported a similar requirement that originated that PR. I > see value in having this as it helps the "decouple authorization from your > applications* story. > Yeah me too. I know that the main idea is to validate only what is contained in the token, but maybe it could be possible to introduce some other feature including this possibility... Thank you again, Matteo > > >> >> Thank you again, >> Matteo >> >> On Mon, Nov 11, 2019 at 1:20 PM Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> >>> We had a PR [1] for addressing this use case but it was closed due to >>> not enough quorum to support the changes. >>> >>> While we should keep policy enforcement based on the state carried by >>> tokens, I see as an improvement to also allow users, on a per-use case >>> basis, to fetch roles directly from the realm instead, even if they are not >>> available in the token. >>> >>> I can't remember now, but I'm wondering if was you that first requested >>> this so I ended up working on these changes? >>> >>> Regards. >>> Pedro Igor >>> >>> [1] https://github.com/keycloak/keycloak/pull/6163 >>> >>> On Mon, Nov 11, 2019 at 5:43 AM Matteo Restelli <mrestelli(a)cuebiq.com&gt; >>> wrote: >>> >>>> Hi guys, >>>> we’re experiencing issues about JWT access_token size and we were >>>> planning >>>> to remove the “roles” claim as a default, so to remove the claim from >>>> the >>>> access_token. Once we do that, the KC adapter / policy enforcer >>>> returns a >>>> 403. So at this point, does the access_token must have the roles >>>> inside it? >>>> Or it’s another problem which is giving us the 403? >>>> >>>> Thank you! >>>> Matteo >>>> >>>> -- >>>> >>>> Like <https://www.facebook.com/cuebiq/> I Follow >>>> <https://twitter.com/Cuebiq>I Connect >>>> <https://www.linkedin.com/company/cuebiq> >>>> >>>> >>>> This email is reserved >>>> exclusively for sending and receiving messages inherent working >>>> activities, >>>> and is not intended nor authorized for personal use. Therefore, any >>>> outgoing messages or incoming response messages will be treated as >>>> company >>>> messages and will be subject to the corporate IT policy and may >>>> possibly to >>>> be read by persons other than by the subscriber of the box. >>>> Confidential >>>> information may be contained in this message. If you are not the >>>> address >>>> indicated in this message, please do not copy or deliver this message >>>> to >>>> anyone. In such case, you should notify the sender immediately and >>>> delete >>>> the original message. >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >> Like <https://www.facebook.com/cuebiq/> I Follow >> <https://twitter.com/Cuebiq>I Connect >> <https://www.linkedin.com/company/cuebiq> >> >> This email is reserved exclusively for sending and receiving messages >> inherent working activities, and is not intended nor authorized for >> personal use. Therefore, any outgoing messages or incoming response >> messages will be treated as company messages and will be subject to the >> corporate IT policy and may possibly to be read by persons other than by >> the subscriber of the box. Confidential information may be contained in >> this message. If you are not the address indicated in this message, please >> do not copy or deliver this message to anyone. In such case, you should >> notify the sender immediately and delete the original message. >> >

You are right. But today the token is the primary source of the identity (and access context). From a KC perspective, it does not make much difference as you said. Especially because in most cases, the primary (primary from an authz perspective) claims included in the token during authentication don't represent user consent or anything alike that could potentially tie the access context to the session. If this feature can just be enabled/disabled so that users decide what they want to do, for me it is fine. On Tue, Nov 12, 2019 at 6:14 AM Matteo Restelli <mrestelli(a)cuebiq.com&gt; wrote: > Hi Pedro, > Sorry for this second email. So the PR has been closed due to the fact > that it's necessary to validate only token contents. But, what about > javascript policies? I mean, if i have the following use case: > > An user is trying to make a GET to /organizations/1234/reports/1 path. To > access the following policies must pass (AND condition): > - An user must have the role "blabla" (role policy) > - An user must belong to a the group 1234 (javascript policy, we validate > the path against the fact that he belongs to a group, since we're modeling > organizations as groups in Keycloak) > > I'm validating both contents in the token and both something "external". > So it's not the same case of validating roles directly reading the database? > > Thank you, > Matteo > > > On Mon, Nov 11, 2019 at 4:47 PM Matteo Restelli <mrestelli(a)cuebiq.com&gt; > wrote: > >> >> >> On Mon, Nov 11, 2019 at 4:17 PM Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> >>> >>> On Mon, Nov 11, 2019 at 10:40 AM Matteo Restelli <mrestelli(a)cuebiq.com&gt; >>> wrote: >>> >>>> Hi Pedro, >>>> thank you for your reply. >>>> No, i wasn't the one who requested the feature, anyway i'm still >>>> interested into it. Our use case includes several microservices (which >>>> represents modules of our PaaS) which performs authorization checks against >>>> realm based roles. Every microservices has each own client containing its >>>> authorization checks. >>>> >>> >>> Interesting, another use-case then ... >>> >> >> Yeah, we've separated authorization inside each backend client, in order >> to better separate authorization requirements. Each microservice will then >> validate and refer to its own authorization requirements. The frontend >> client, instead, is a single public client which receives the complete >> lists of roles (since they're defined at realm level) >> >> >>> >>> >>>> Besides the PR (which is really really interesting and i hope it will >>>> be included in further releases), what are your recommendations to reduce >>>> the access token size? I'm asking this because in some browsers there are >>>> limits (4KB) about cookies & headers length. I can imagine those solutions: >>>> >>>> - Keep the token "light" and perform a token exchange into our gateway >>>> once we receive the token from the single page application, in order to >>>> retrieve a new token with all the realms roles associated to the user >>>> >>> >>> The price you pay is a round-trip to the server. But it works ... >>> >> >> Yeah and i want to completely avoid that, in order to avoid >> to be "bottlenecked" by Keycloak >> >> >>> >>> >>>> - Use some particular mode of the adapter which will do the necessary >>>> to retrieve the roles (but i can't find something like that in the docs) >>>> >>> >>> Roles are gathered from the token, always ... >>> >> >> Yeah, i just saw it debugging the keycloak code locally... :( >> >> >>> >>> >>>> - Use RPT? Once the gateway receives the access token, perform the RPT >>>> request to retrieve a token with all the permissions for the particular >>>> client >>>> >>> >>> The beauty of the RPT is that the permissions should be enough as the >>> server already granted them based on the state of the current session. >>> Resource-based permissions also decouple applications from access control >>> mechanisms so that you have more flexibility and control over the policies >>> that govern access to your resources. >>> >>> It should not be seen as *the* solution for large tokens though ... >>> >>> >>>> - Something else unknown to us? :) >>>> >>> >>> Maybe use a mapper or don't include tokens by default in your token. So >>> that your client requests what he needs (yeah, more coupling between your >>> clients + resource servers). The client scopes functionality is very >>> interesting in this context given that you can set-up a scope that spans >>> multiple roles, on a per-application basis. >>> >>> >>>> >>>> Have you ever faced this kind of problem? >>>> >>> >>> Another user reported a similar requirement that originated that PR. I >>> see value in having this as it helps the "decouple authorization from your >>> applications* story. >>> >> >> Yeah me too. I know that the main idea is to validate only what is >> contained in the token, but maybe it could be possible to introduce some >> other feature including this possibility... >> >> Thank you again, >> Matteo >> >> >>> >>> >>>> >>>> Thank you again, >>>> Matteo >>>> >>>> On Mon, Nov 11, 2019 at 1:20 PM Pedro Igor Silva <psilva(a)redhat.com&gt; >>>> wrote: >>>> >>>>> We had a PR [1] for addressing this use case but it was closed due to >>>>> not enough quorum to support the changes. >>>>> >>>>> While we should keep policy enforcement based on the state carried by >>>>> tokens, I see as an improvement to also allow users, on a per-use case >>>>> basis, to fetch roles directly from the realm instead, even if they are not >>>>> available in the token. >>>>> >>>>> I can't remember now, but I'm wondering if was you that first >>>>> requested this so I ended up working on these changes? >>>>> >>>>> Regards. >>>>> Pedro Igor >>>>> >>>>> [1] https://github.com/keycloak/keycloak/pull/6163 >>>>> >>>>> On Mon, Nov 11, 2019 at 5:43 AM Matteo Restelli <mrestelli(a)cuebiq.com&gt; >>>>> wrote: >>>>> >>>>>> Hi guys, >>>>>> we’re experiencing issues about JWT access_token size and we were >>>>>> planning >>>>>> to remove the “roles” claim as a default, so to remove the claim >>>>>> from the >>>>>> access_token. Once we do that, the KC adapter / policy enforcer >>>>>> returns a >>>>>> 403. So at this point, does the access_token must have the roles >>>>>> inside it? >>>>>> Or it’s another problem which is giving us the 403? >>>>>> >>>>>> Thank you! >>>>>> Matteo >>>>>> >>>>>> -- >>>>>> >>>>>> Like <https://www.facebook.com/cuebiq/> I Follow >>>>>> <https://twitter.com/Cuebiq>I Connect >>>>>> <https://www.linkedin.com/company/cuebiq> >>>>>> >>>>>> >>>>>> This email is reserved >>>>>> exclusively for sending and receiving messages inherent working >>>>>> activities, >>>>>> and is not intended nor authorized for personal use. Therefore, any >>>>>> outgoing messages or incoming response messages will be treated as >>>>>> company >>>>>> messages and will be subject to the corporate IT policy and may >>>>>> possibly to >>>>>> be read by persons other than by the subscriber of the box. >>>>>> Confidential >>>>>> information may be contained in this message. If you are not the >>>>>> address >>>>>> indicated in this message, please do not copy or deliver this >>>>>> message to >>>>>> anyone. In such case, you should notify the sender immediately and >>>>>> delete >>>>>> the original message. >>>>>> _______________________________________________ >>>>>> keycloak-user mailing list >>>>>> keycloak-user(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>>> >>>> Like <https://www.facebook.com/cuebiq/> I Follow >>>> <https://twitter.com/Cuebiq>I Connect >>>> <https://www.linkedin.com/company/cuebiq> >>>> >>>> This email is reserved exclusively for sending and receiving messages >>>> inherent working activities, and is not intended nor authorized for >>>> personal use. Therefore, any outgoing messages or incoming response >>>> messages will be treated as company messages and will be subject to the >>>> corporate IT policy and may possibly to be read by persons other than by >>>> the subscriber of the box. Confidential information may be contained in >>>> this message. If you are not the address indicated in this message, please >>>> do not copy or deliver this message to anyone. In such case, you should >>>> notify the sender immediately and delete the original message. >>>> >>> > Like <https://www.facebook.com/cuebiq/> I Follow > <https://twitter.com/Cuebiq>I Connect > <https://www.linkedin.com/company/cuebiq> > > This email is reserved exclusively for sending and receiving messages > inherent working activities, and is not intended nor authorized for > personal use. Therefore, any outgoing messages or incoming response > messages will be treated as company messages and will be subject to the > corporate IT policy and may possibly to be read by persons other than by > the subscriber of the box. Confidential information may be contained in > this message. If you are not the address indicated in this message, please > do not copy or deliver this message to anyone. In such case, you should > notify the sender immediately and delete the original message. >

Sure, please leave your comments in the PR or https://issues.jboss.org/browse/KEYCLOAK-10731. Thanks. On Wed, Nov 13, 2019 at 5:16 AM Matteo Restelli <mrestelli(a)cuebiq.com&gt; wrote: > Yeah, also for me it could be fine to introduce this feature with some > sort of a flag (from the KC GUI or directly in the KC adapter) to control > the desired behaviour. So, what about your colleagues? What do they think > about that? > If you want i can open a Jiira issue about that or i can comment the > previously closed PR. It could be fine for you? > > Thank you again, > Matteo > > On Tue, Nov 12, 2019 at 8:04 PM Pedro Igor Silva <psilva(a)redhat.com&gt; > wrote: > >> You are right. But today the token is the primary source of the identity >> (and access context). >> >> From a KC perspective, it does not make much difference as you said. >> Especially because in most cases, the primary (primary from an authz >> perspective) claims included in the token during authentication don't >> represent user consent or anything alike that could potentially tie the >> access context to the session. >> >> If this feature can just be enabled/disabled so that users decide what >> they want to do, for me it is fine. >> >> On Tue, Nov 12, 2019 at 6:14 AM Matteo Restelli <mrestelli(a)cuebiq.com&gt; >> wrote: >> >>> Hi Pedro, >>> Sorry for this second email. So the PR has been closed due to the fact >>> that it's necessary to validate only token contents. But, what about >>> javascript policies? I mean, if i have the following use case: >>> >>> An user is trying to make a GET to /organizations/1234/reports/1 path. >>> To access the following policies must pass (AND condition): >>> - An user must have the role "blabla" (role policy) >>> - An user must belong to a the group 1234 (javascript policy, we >>> validate the path against the fact that he belongs to a group, since we're >>> modeling organizations as groups in Keycloak) >>> >>> I'm validating both contents in the token and both something >>> "external". So it's not the same case of validating roles directly reading >>> the database? >>> >>> Thank you, >>> Matteo >>> >>> >>> On Mon, Nov 11, 2019 at 4:47 PM Matteo Restelli <mrestelli(a)cuebiq.com&gt; >>> wrote: >>> >>>> >>>> >>>> On Mon, Nov 11, 2019 at 4:17 PM Pedro Igor Silva <psilva(a)redhat.com&gt; >>>> wrote: >>>> >>>>> >>>>> On Mon, Nov 11, 2019 at 10:40 AM Matteo Restelli < >>>>> mrestelli(a)cuebiq.com&gt; wrote: >>>>> >>>>>> Hi Pedro, >>>>>> thank you for your reply. >>>>>> No, i wasn't the one who requested the feature, anyway i'm still >>>>>> interested into it. Our use case includes several microservices (which >>>>>> represents modules of our PaaS) which performs authorization checks against >>>>>> realm based roles. Every microservices has each own client containing its >>>>>> authorization checks. >>>>>> >>>>> >>>>> Interesting, another use-case then ... >>>>> >>>> >>>> Yeah, we've separated authorization inside each backend client, in >>>> order to better separate authorization requirements. Each microservice will >>>> then validate and refer to its own authorization requirements. The frontend >>>> client, instead, is a single public client which receives the complete >>>> lists of roles (since they're defined at realm level) >>>> >>>> >>>>> >>>>> >>>>>> Besides the PR (which is really really interesting and i hope it >>>>>> will be included in further releases), what are your recommendations to >>>>>> reduce the access token size? I'm asking this because in some browsers >>>>>> there are limits (4KB) about cookies & headers length. I can imagine those >>>>>> solutions: >>>>>> >>>>>> - Keep the token "light" and perform a token exchange into our >>>>>> gateway once we receive the token from the single page application, in >>>>>> order to retrieve a new token with all the realms roles associated to the >>>>>> user >>>>>> >>>>> >>>>> The price you pay is a round-trip to the server. But it works ... >>>>> >>>> >>>> Yeah and i want to completely avoid that, in order to avoid >>>> to be "bottlenecked" by Keycloak >>>> >>>> >>>>> >>>>> >>>>>> - Use some particular mode of the adapter which will do the >>>>>> necessary to retrieve the roles (but i can't find something like that in >>>>>> the docs) >>>>>> >>>>> >>>>> Roles are gathered from the token, always ... >>>>> >>>> >>>> Yeah, i just saw it debugging the keycloak code locally... :( >>>> >>>> >>>>> >>>>> >>>>>> - Use RPT? Once the gateway receives the access token, perform the >>>>>> RPT request to retrieve a token with all the permissions for the particular >>>>>> client >>>>>> >>>>> >>>>> The beauty of the RPT is that the permissions should be enough as the >>>>> server already granted them based on the state of the current session. >>>>> Resource-based permissions also decouple applications from access control >>>>> mechanisms so that you have more flexibility and control over the policies >>>>> that govern access to your resources. >>>>> >>>>> It should not be seen as *the* solution for large tokens though ... >>>>> >>>>> >>>>>> - Something else unknown to us? :) >>>>>> >>>>> >>>>> Maybe use a mapper or don't include tokens by default in your token. >>>>> So that your client requests what he needs (yeah, more coupling between >>>>> your clients + resource servers). The client scopes functionality is very >>>>> interesting in this context given that you can set-up a scope that spans >>>>> multiple roles, on a per-application basis. >>>>> >>>>> >>>>>> >>>>>> Have you ever faced this kind of problem? >>>>>> >>>>> >>>>> Another user reported a similar requirement that originated that PR. >>>>> I see value in having this as it helps the "decouple authorization from >>>>> your applications* story. >>>>> >>>> >>>> Yeah me too. I know that the main idea is to validate only what is >>>> contained in the token, but maybe it could be possible to introduce some >>>> other feature including this possibility... >>>> >>>> Thank you again, >>>> Matteo >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> Thank you again, >>>>>> Matteo >>>>>> >>>>>> On Mon, Nov 11, 2019 at 1:20 PM Pedro Igor Silva <psilva(a)redhat.com&gt; >>>>>> wrote: >>>>>> >>>>>>> We had a PR [1] for addressing this use case but it was closed due >>>>>>> to not enough quorum to support the changes. >>>>>>> >>>>>>> While we should keep policy enforcement based on the state carried >>>>>>> by tokens, I see as an improvement to also allow users, on a per-use case >>>>>>> basis, to fetch roles directly from the realm instead, even if they are not >>>>>>> available in the token. >>>>>>> >>>>>>> I can't remember now, but I'm wondering if was you that first >>>>>>> requested this so I ended up working on these changes? >>>>>>> >>>>>>> Regards. >>>>>>> Pedro Igor >>>>>>> >>>>>>> [1] https://github.com/keycloak/keycloak/pull/6163 >>>>>>> >>>>>>> On Mon, Nov 11, 2019 at 5:43 AM Matteo Restelli < >>>>>>> mrestelli(a)cuebiq.com&gt; wrote: >>>>>>> >>>>>>>> Hi guys, >>>>>>>> we’re experiencing issues about JWT access_token size and we were >>>>>>>> planning >>>>>>>> to remove the “roles” claim as a default, so to remove the claim >>>>>>>> from the >>>>>>>> access_token. Once we do that, the KC adapter / policy enforcer >>>>>>>> returns a >>>>>>>> 403. So at this point, does the access_token must have the roles >>>>>>>> inside it? >>>>>>>> Or it’s another problem which is giving us the 403? >>>>>>>> >>>>>>>> Thank you! >>>>>>>> Matteo >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Like <https://www.facebook.com/cuebiq/> I Follow >>>>>>>> <https://twitter.com/Cuebiq>I Connect >>>>>>>> <https://www.linkedin.com/company/cuebiq> >>>>>>>> >>>>>>>> >>>>>>>> This email is reserved >>>>>>>> exclusively for sending and receiving messages inherent working >>>>>>>> activities, >>>>>>>> and is not intended nor authorized for personal use. Therefore, >>>>>>>> any >>>>>>>> outgoing messages or incoming response messages will be treated as >>>>>>>> company >>>>>>>> messages and will be subject to the corporate IT policy and may >>>>>>>> possibly to >>>>>>>> be read by persons other than by the subscriber of the box. >>>>>>>> Confidential >>>>>>>> information may be contained in this message. If you are not the >>>>>>>> address >>>>>>>> indicated in this message, please do not copy or deliver this >>>>>>>> message to >>>>>>>> anyone. In such case, you should notify the sender immediately and >>>>>>>> delete >>>>>>>> the original message. >>>>>>>> _______________________________________________ >>>>>>>> keycloak-user mailing list >>>>>>>> keycloak-user(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>>> >>>>>>> >>>>>> Like <https://www.facebook.com/cuebiq/> I Follow >>>>>> <https://twitter.com/Cuebiq>I Connect >>>>>> <https://www.linkedin.com/company/cuebiq> >>>>>> >>>>>> This email is reserved exclusively for sending and receiving >>>>>> messages inherent working activities, and is not intended nor authorized >>>>>> for personal use. Therefore, any outgoing messages or incoming response >>>>>> messages will be treated as company messages and will be subject to the >>>>>> corporate IT policy and may possibly to be read by persons other than by >>>>>> the subscriber of the box. Confidential information may be contained in >>>>>> this message. If you are not the address indicated in this message, please >>>>>> do not copy or deliver this message to anyone. In such case, you should >>>>>> notify the sender immediately and delete the original message. >>>>>> >>>>> >>> Like <https://www.facebook.com/cuebiq/> I Follow >>> <https://twitter.com/Cuebiq>I Connect >>> <https://www.linkedin.com/company/cuebiq> >>> >>> This email is reserved exclusively for sending and receiving messages >>> inherent working activities, and is not intended nor authorized for >>> personal use. Therefore, any outgoing messages or incoming response >>> messages will be treated as company messages and will be subject to the >>> corporate IT policy and may possibly to be read by persons other than by >>> the subscriber of the box. Confidential information may be contained in >>> this message. If you are not the address indicated in this message, please >>> do not copy or deliver this message to anyone. In such case, you should >>> notify the sender immediately and delete the original message. >>> >> > Like <https://www.facebook.com/cuebiq/> I Follow > <https://twitter.com/Cuebiq>I Connect > <https://www.linkedin.com/company/cuebiq> > > This email is reserved exclusively for sending and receiving messages > inherent working activities, and is not intended nor authorized for > personal use. Therefore, any outgoing messages or incoming response > messages will be treated as company messages and will be subject to the > corporate IT policy and may possibly to be read by persons other than by > the subscriber of the box. Confidential information may be contained in > this message. If you are not the address indicated in this message, please > do not copy or deliver this message to anyone. In such case, you should > notify the sender immediately and delete the original message. >