Hello, we are testing Keycloak 4.1.0.Final for authentication and authorization (UMA 2.0 flow). Some assumptions: - The Resource Server owns the resource Foo, and protects it by using two scope-based permissions, one requiring READ scope, and the other one requiring WRITE scope. - User Alice has been granted READ scope for resource Foo. - We are not using Policy Enforcers. Enforcement will be implemented at the Resource Server. We are modeling the following flow: 1. The Requesting Party (Alice) requests access to resource Foo in the Resource Server. This request DOES NOT provide an RPT. 2. The Resource Server detects the absence of RPT, so it requests a Permission Ticket to Keycloak, for the Foo resource and both READ and WRITE scopes (providing a valid PAT). 3. Keycloak returns a valid Permission Ticket to the Resource Server. 4. The Resource Server returns the Permission Ticket (including Keycloak token URI (http://${host}:${port}/auth/realms/${realm}/protocol/ openid-connect/token) at WWW-Authorization header) with status code 401 to the Requesting Party. 5. The Requesting Party sends the Permission Ticket (for the Foo resource and both READ and WRITE scopes) to Keycloak, in order to get a valid RPT. Here is where things start to get confusing. We expected that Keycloak would reject the authorization request due to failed permission evaluation (Alice has READ scope for resource Foo, but DOES NOT have WRITE scope). Nevertheless, Keycloak returns a valid RPT, granting permission for resource Foo (just for READ scope). We are aware that this behavior is UMA 2.0 compliant <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#rfc. section.3.6.4> : > If the value is non-null and CandidateGrantedScopes < RequestedScopes, the > authorization server MUST subsequently issue either an RPT containing > CandidateGrantedScopes (upgrading as appropriate; see below), or one of the > error codes. The reason for the two options is that granting only partial > scopes may not be useful for the client's and requesting party's purposes > in seeking authorization for access. But as the RFC explicitly points out, this behavior may not be useful for the client. We think that the RFC is right, because this renders the client unable to tell whether the authorization has been partially or completely fulfilled. And consequently the Resource Server will request again a Permission Ticket for the Foo resource and both READ and WRITE scopes, so the whole flow will be repeated over and over again. If this is Keycloak expected behavior, how can we avoid the infinite loops? Another question is, when providing a valid RPT along with a Permission Ticket, why Keycloak deems an RPT as upgraded = true even when the requested resource has not been authorized? It returns the same RPT with just jti, exp and iat updated. Since we think that the Authorization Server must be the one stopping the UMA flow, should not Keycloak return a 403 Forbidden instead? Is this behavior configurable in any way? Thank you in advance! _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Hello, we are testing Keycloak 4.1.0.Final for authentication and authorization (UMA 2.0 flow). Some assumptions: - The Resource Server owns the resource Foo, and protects it by using two scope-based permissions, one requiring READ scope, and the other one requiring WRITE scope. - User Alice has been granted READ scope for resource Foo. - We are not using Policy Enforcers. Enforcement will be implemented at the Resource Server. We are modeling the following flow: 1. The Requesting Party (Alice) requests access to resource Foo in the Resource Server. This request DOES NOT provide an RPT. 2. The Resource Server detects the absence of RPT, so it requests a Permission Ticket to Keycloak, for the Foo resource and both READ and WRITE scopes (providing a valid PAT). 3. Keycloak returns a valid Permission Ticket to the Resource Server. 4. The Resource Server returns the Permission Ticket (including Keycloak token URI (http://${host}:${port}/auth/realms/${realm}/protocol/ openid-connect/token) at WWW-Authorization header) with status code 401 to the Requesting Party. 5. The Requesting Party sends the Permission Ticket (for the Foo resource and both READ and WRITE scopes) to Keycloak, in order to get a valid RPT. Here is where things start to get confusing. We expected that Keycloak would reject the authorization request due to failed permission evaluation (Alice has READ scope for resource Foo, but DOES NOT have WRITE scope). Nevertheless, Keycloak returns a valid RPT, granting permission for resource Foo (just for READ scope). We are aware that this behavior is UMA 2.0 compliant <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.html#rfc. section.3.6.4> : > If the value is non-null and CandidateGrantedScopes < RequestedScopes, the > authorization server MUST subsequently issue either an RPT containing > CandidateGrantedScopes (upgrading as appropriate; see below), or one of the > error codes. The reason for the two options is that granting only partial > scopes may not be useful for the client's and requesting party's purposes > in seeking authorization for access. But as the RFC explicitly points out, this behavior may not be useful for the client. We think that the RFC is right, because this renders the client unable to tell whether the authorization has been partially or completely fulfilled. And consequently the Resource Server will request again a Permission Ticket for the Foo resource and both READ and WRITE scopes, so the whole flow will be repeated over and over again. If this is Keycloak expected behavior, how can we avoid the infinite loops?

Another question is, when providing a valid RPT along with a Permission Ticket, why Keycloak deems an RPT as upgraded = true even when the requested resource has not been authorized? It returns the same RPT with just jti, exp and iat updated. Since we think that the Authorization Server must be the one stopping the UMA flow, should not Keycloak return a 403 Forbidden instead? Is this behavior configurable in any way? Thank you in advance! _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

If Keycloak behavior is changed according to your proposal described in your previous message, then there shouldn't be any problem with authz requests in our model. It is true that the scopes described in our example are a bit misleading. Think about something like READ and READ-PREMIUM instead, used at a GET endpoint, and the Resource Server just checks whether one of these scopes is contained in the RPT, returning a ticket with READ and READ-PREMIUM when none of them has been provided. When the Client requests the new RPT by using the ticket, Keycloak would return a RPT including either READ or READ-PREMIUM, or 403 Forbidden. As I said before, this is perfectly aligned with the new Keycloak behavior. On jue, jul 12, 2018 at 7:35 , Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: On Tue, Jul 10, 2018 at 6:22 AM, Francisco José Bermejo Herrera < francisco.bermejo.herrera(a)tecsisa.com&gt; wrote: > Hello, we are testing Keycloak 4.1.0.Final for authentication and > authorization (UMA 2.0 flow). > > Some assumptions: > > - The Resource Server owns the resource Foo, and protects it by using > two scope-based permissions, one requiring READ scope, and the other > one > requiring WRITE scope. > - User Alice has been granted READ scope for resource Foo. > - We are not using Policy Enforcers. Enforcement will be implemented at > the Resource Server. > > We are modeling the following flow: > > 1. The Requesting Party (Alice) requests access to resource Foo in the > Resource Server. This request DOES NOT provide an RPT. > 2. The Resource Server detects the absence of RPT, so it requests a > Permission Ticket to Keycloak, for the Foo resource and both READ and > WRITE > scopes (providing a valid PAT). > 3. Keycloak returns a valid Permission Ticket to the Resource Server. > 4. The Resource Server returns the Permission Ticket (including > Keycloak > token URI (http://${host}:${port}/auth/realms/${realm}/protocol/openid > -connect/token) > at WWW-Authorization header) with status code 401 to the Requesting > Party. > 5. The Requesting Party sends the Permission Ticket (for the Foo > resource and both READ and WRITE scopes) to Keycloak, in order to get a > valid RPT. > > Here is where things start to get confusing. We expected that Keycloak > would reject the authorization request due to failed permission evaluation > (Alice has READ scope for resource Foo, but DOES NOT have WRITE scope). > Nevertheless, Keycloak returns a valid RPT, granting permission for > resource Foo (just for READ scope). > > We are aware that this behavior is UMA 2.0 compliant > <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21. > html#rfc.section.3.6.4> > : > > > If the value is non-null and CandidateGrantedScopes < RequestedScopes, > the > > authorization server MUST subsequently issue either an RPT containing > > CandidateGrantedScopes (upgrading as appropriate; see below), or one of > the > > error codes. The reason for the two options is that granting only > partial > > scopes may not be useful for the client's and requesting party's > purposes > > in seeking authorization for access. > > > But as the RFC explicitly points out, this behavior may not be useful for > the client. We think that the RFC is right, because this renders the > client > unable to tell whether the authorization has been partially or completely > fulfilled. And consequently the Resource Server will request again a > Permission Ticket for the Foo resource and both READ and WRITE scopes, so > the whole flow will be repeated over and over again. If this is Keycloak > expected behavior, how can we avoid the infinite loops? > For this particular case, each scope is associated with a specific HTTP method ? Can't you obtain tickets accordingly including only the scopes you need ? As you noticed, by default, Keycloak issues a RPT for any resource/scope you sent along with an authorization request. Resource servers (or clients sending authz requests directly without ticket) should be able to ask only for specific resources/scopes. > > Another question is, when providing a valid RPT along with a Permission > Ticket, why Keycloak deems an RPT as upgraded = true even when the > requested resource has not been authorized? It returns the same RPT with > just jti, exp and iat updated. Since we think that the Authorization > Server > must be the one stopping the UMA flow, should not Keycloak return a 403 > Forbidden instead? Is this behavior configurable in any way? > > Thank you in advance! > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user >

We're OK with all your changes. But, just a quick remark, you say: Still keep current behavior where the server may grant additional permissions even though you requested only a sub set of them. E.g.: You ask for source "foo" + scope "a" and the server may grant resource "foo" + scope "a" and "b". IMHO this isn't the current behavior, since if you ask for resource "foo" + scope "a", the server grants "foo" + scope "a". But, it is true that if you ask for resource "foo" + any scope (by leaving scope empty), the server may grant you resource "foo" + scope "a" and "b". For example: - Ticket request (just "read" scope) POST /auth/realms/TestRealm/authz/protection/permission HTTP/1.1 Host: 127.0.0.1:8080 Content-Type: application/json Authorization: Bearer eyJ... [ {"resource_id": "fooresources", "resource_scopes": ["read"]} ] - RPT issued using the ticket (note: Alice has permissions for both "read" and "write" scopes) { "jti": "2a8a98ed-f058-4d4d-8321-1501896f773d", "exp": 1531489206, "nbf": 0, "iat": 1531485606, "iss": "http://127.0.0.1:8080/auth/realms/TestRealm", "aud": "auth-demo-ws", "sub": "4c3b0694-c1fe-405a-ac35-d4cf9e14aabd", "typ": "Bearer", "azp": "auth-demo-webapp", "auth_time": 0, "session_state": "34a4ec1e-9bd3-4413-b785-ae0dda7287d6", "acr": "1", "allowed-origins": [], "realm_access": { "roles": [ "offline_access", "uma_authorization" ] }, "resource_access": { "auth-demo-webapp": { "roles": [ "owner" ] }, "auth-demo-ws": { "roles": [ "fooresource-reader", "fooresource-writer" ] } }, "authorization": { "permissions": [ { "scopes": [ "read" ], "rsid": "dbc5e6a1-d65a-4510-b354-d12b8dd67dc2", "rsname": "fooresources" } ] }, "scope": "email profile", "tenant_id": "12345", "email_verified": true, "roles": [ "role_owner" ], "name": "Alice Brown", "groups": [ "/auth-demo/admin" ], "preferred_username": "alice", "given_name": "Alice", "family_name": "Brown", "email": &quot;alice(a)test.com&quot; } On vie, jul 13, 2018 at 2:26 , Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: I see. Just to make sure we are aligned. The changes I'm proposing are more aligned with spec and provide: * Only mark RPT as upgraded if ALL permissions granted by a previous RPT were granted * DENY authorization requests in case you are sending a previous issued RPT and ANY additional permissions in a ticket are DENIED. * Still keep current behavior where the server may grant additional permissions even though you requested only a sub set of them. E.g.: You ask for source "foo" + scope "a" and the server may grant resource "foo" + scope "a" and "b". On Fri, Jul 13, 2018 at 5:17 AM, Francisco José Bermejo Herrera < francisco.bermejo.herrera(a)tecsisa.com&gt; wrote: > If Keycloak behavior is changed according to your proposal described in > your previous message, then there shouldn't be any problem with authz > requests in our model. > > It is true that the scopes described in our example are a bit misleading. > Think about something like READ and READ-PREMIUM instead, used at a GET > endpoint, and the Resource Server just checks whether one of these scopes > is contained in the RPT, returning a ticket with READ and READ-PREMIUM when > none of them has been provided. When the Client requests the new RPT by > using the ticket, Keycloak would return a RPT including either READ or > READ-PREMIUM, or 403 Forbidden. > > As I said before, this is perfectly aligned with the new Keycloak > behavior. > > On jue, jul 12, 2018 at 7:35 , Pedro Igor Silva <psilva(a)redhat.com&gt; > wrote: > > > > On Tue, Jul 10, 2018 at 6:22 AM, Francisco José Bermejo Herrera < > francisco.bermejo.herrera(a)tecsisa.com&gt; wrote: > >> Hello, we are testing Keycloak 4.1.0.Final for authentication and >> authorization (UMA 2.0 flow). >> >> Some assumptions: >> >> - The Resource Server owns the resource Foo, and protects it by using >> two scope-based permissions, one requiring READ scope, and the other >> one >> requiring WRITE scope. >> - User Alice has been granted READ scope for resource Foo. >> - We are not using Policy Enforcers. Enforcement will be implemented >> at >> the Resource Server. >> >> We are modeling the following flow: >> >> 1. The Requesting Party (Alice) requests access to resource Foo in the >> Resource Server. This request DOES NOT provide an RPT. >> 2. The Resource Server detects the absence of RPT, so it requests a >> Permission Ticket to Keycloak, for the Foo resource and both READ and >> WRITE >> scopes (providing a valid PAT). >> 3. Keycloak returns a valid Permission Ticket to the Resource Server. >> 4. The Resource Server returns the Permission Ticket (including >> Keycloak >> token URI (http://${host}:${port}/auth/r >> ealms/${realm}/protocol/openid-connect/token) >> at WWW-Authorization header) with status code 401 to the Requesting >> Party. >> 5. The Requesting Party sends the Permission Ticket (for the Foo >> resource and both READ and WRITE scopes) to Keycloak, in order to get >> a >> valid RPT. >> >> Here is where things start to get confusing. We expected that Keycloak >> would reject the authorization request due to failed permission >> evaluation >> (Alice has READ scope for resource Foo, but DOES NOT have WRITE scope). >> Nevertheless, Keycloak returns a valid RPT, granting permission for >> resource Foo (just for READ scope). >> >> We are aware that this behavior is UMA 2.0 compliant >> <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.h >> tml#rfc.section.3.6.4> >> : >> >> > If the value is non-null and CandidateGrantedScopes < RequestedScopes, >> the >> > authorization server MUST subsequently issue either an RPT containing >> > CandidateGrantedScopes (upgrading as appropriate; see below), or one >> of the >> > error codes. The reason for the two options is that granting only >> partial >> > scopes may not be useful for the client's and requesting party's >> purposes >> > in seeking authorization for access. >> >> >> But as the RFC explicitly points out, this behavior may not be useful for >> the client. We think that the RFC is right, because this renders the >> client >> unable to tell whether the authorization has been partially or completely >> fulfilled. And consequently the Resource Server will request again a >> Permission Ticket for the Foo resource and both READ and WRITE scopes, so >> the whole flow will be repeated over and over again. If this is Keycloak >> expected behavior, how can we avoid the infinite loops? >> > > For this particular case, each scope is associated with a specific HTTP > method ? Can't you obtain tickets accordingly including only the scopes you > need ? > > As you noticed, by default, Keycloak issues a RPT for any resource/scope > you sent along with an authorization request. Resource servers (or clients > sending authz requests directly without ticket) should be able to ask only > for specific resources/scopes. > > >> >> Another question is, when providing a valid RPT along with a Permission >> Ticket, why Keycloak deems an RPT as upgraded = true even when the >> requested resource has not been authorized? It returns the same RPT with >> just jti, exp and iat updated. Since we think that the Authorization >> Server >> must be the one stopping the UMA flow, should not Keycloak return a 403 >> Forbidden instead? Is this behavior configurable in any way? >> >> Thank you in advance! >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > >

I see. There is no problem either way. BTW, we tested your implementation of the proposed changes and it seems to work perfectly. Nice job! 2018-07-13 17:57 GMT+02:00 Pedro Igor Silva <psilva(a)redhat.com&gt;: > Yeah, you are right. Bad example. I was thinking about asking two scopes > and returning only one of them because other was denied ... > > > On Fri, Jul 13, 2018 at 9:47 AM, Francisco José Bermejo Herrera < > francisco.bermejo.herrera(a)tecsisa.com&gt; wrote: > >> We're OK with all your changes. But, just a quick remark, you say: >> >> Still keep current behavior where the server may grant additional >> permissions even though you requested only a sub set of them. E.g.: You ask >> for source "foo" + scope "a" and the server may grant resource "foo" + >> scope "a" and "b". >> >> >> IMHO this isn't the current behavior, since if you ask for resource >> "foo" + scope "a", the server grants "foo" + scope "a". But, it is true >> that if you ask for resource "foo" + any scope (by leaving scope empty), >> the server may grant you resource "foo" + scope "a" and "b". >> >> For example: >> >> - Ticket request (just "read" scope) >> >> POST /auth/realms/TestRealm/authz/protection/permission HTTP/1.1 >> >> Host: 127.0.0.1:8080 >> Content-Type: application/json >> Authorization: Bearer eyJ... >> [ >> {"resource_id": "fooresources", "resource_scopes": ["read"]} >> ] >> >> >> - RPT issued using the ticket (note: Alice has permissions for both >> "read" and "write" scopes) >> >> { >> >> "jti": "2a8a98ed-f058-4d4d-8321-1501896f773d", >> >> "exp": 1531489206, >> >> "nbf": 0, >> >> "iat": 1531485606, >> >> "iss": "http://127.0.0.1:8080/auth/realms/TestRealm", >> >> "aud": "auth-demo-ws", >> >> "sub": "4c3b0694-c1fe-405a-ac35-d4cf9e14aabd", >> >> "typ": "Bearer", >> >> "azp": "auth-demo-webapp", >> >> "auth_time": 0, >> >> "session_state": "34a4ec1e-9bd3-4413-b785-ae0dda7287d6", >> >> "acr": "1", >> >> "allowed-origins": [], >> >> "realm_access": { >> >> "roles": [ >> >> "offline_access", >> >> "uma_authorization" >> >> ] >> >> }, >> >> "resource_access": { >> >> "auth-demo-webapp": { >> >> "roles": [ >> >> "owner" >> >> ] >> >> }, >> >> "auth-demo-ws": { >> >> "roles": [ >> >> "fooresource-reader", >> >> "fooresource-writer" >> >> ] >> >> } >> >> }, >> >> "authorization": { >> >> "permissions": [ >> >> { >> >> "scopes": [ >> >> "read" >> >> ], >> >> "rsid": "dbc5e6a1-d65a-4510-b354-d12b8dd67dc2", >> >> "rsname": "fooresources" >> >> } >> >> ] >> >> }, >> >> "scope": "email profile", >> >> "tenant_id": "12345", >> >> "email_verified": true, >> >> "roles": [ >> >> "role_owner" >> >> ], >> >> "name": "Alice Brown", >> >> "groups": [ >> >> "/auth-demo/admin" >> >> ], >> >> "preferred_username": "alice", >> >> "given_name": "Alice", >> >> "family_name": "Brown", >> >> "email": &quot;alice(a)test.com&quot; >> >> } >> >> >> On vie, jul 13, 2018 at 2:26 , Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> >> I see. Just to make sure we are aligned. The changes I'm proposing are >> more aligned with spec and provide: >> >> * Only mark RPT as upgraded if ALL permissions granted by a previous RPT >> were granted >> * DENY authorization requests in case you are sending a previous issued >> RPT and ANY additional permissions in a ticket are DENIED. >> * Still keep current behavior where the server may grant additional >> permissions even though you requested only a sub set of them. E.g.: You ask >> for source "foo" + scope "a" and the server may grant resource "foo" + >> scope "a" and "b". >> >> On Fri, Jul 13, 2018 at 5:17 AM, Francisco José Bermejo Herrera < >> francisco.bermejo.herrera(a)tecsisa.com&gt; wrote: >> >>> If Keycloak behavior is changed according to your proposal described in >>> your previous message, then there shouldn't be any problem with authz >>> requests in our model. >>> >>> It is true that the scopes described in our example are a bit >>> misleading. Think about something like READ and READ-PREMIUM instead, used >>> at a GET endpoint, and the Resource Server just checks whether one of these >>> scopes is contained in the RPT, returning a ticket with READ and >>> READ-PREMIUM when none of them has been provided. When the Client requests >>> the new RPT by using the ticket, Keycloak would return a RPT including >>> either READ or READ-PREMIUM, or 403 Forbidden. >>> >>> As I said before, this is perfectly aligned with the new Keycloak >>> behavior. >>> >>> On jue, jul 12, 2018 at 7:35 , Pedro Igor Silva <psilva(a)redhat.com&gt; >>> wrote: >>> >>> >>> >>> On Tue, Jul 10, 2018 at 6:22 AM, Francisco José Bermejo Herrera < >>> francisco.bermejo.herrera(a)tecsisa.com&gt; wrote: >>> >>>> Hello, we are testing Keycloak 4.1.0.Final for authentication and >>>> authorization (UMA 2.0 flow). >>>> >>>> Some assumptions: >>>> >>>> - The Resource Server owns the resource Foo, and protects it by >>>> using >>>> two scope-based permissions, one requiring READ scope, and the >>>> other one >>>> requiring WRITE scope. >>>> - User Alice has been granted READ scope for resource Foo. >>>> - We are not using Policy Enforcers. Enforcement will be >>>> implemented at >>>> the Resource Server. >>>> >>>> We are modeling the following flow: >>>> >>>> 1. The Requesting Party (Alice) requests access to resource Foo in >>>> the >>>> Resource Server. This request DOES NOT provide an RPT. >>>> 2. The Resource Server detects the absence of RPT, so it requests a >>>> Permission Ticket to Keycloak, for the Foo resource and both READ >>>> and WRITE >>>> scopes (providing a valid PAT). >>>> 3. Keycloak returns a valid Permission Ticket to the Resource >>>> Server. >>>> 4. The Resource Server returns the Permission Ticket (including >>>> Keycloak >>>> token URI (http://${host}:${port}/auth/r >>>> ealms/${realm}/protocol/openid-connect/token) >>>> at WWW-Authorization header) with status code 401 to the Requesting >>>> Party. >>>> 5. The Requesting Party sends the Permission Ticket (for the Foo >>>> resource and both READ and WRITE scopes) to Keycloak, in order to >>>> get a >>>> valid RPT. >>>> >>>> Here is where things start to get confusing. We expected that Keycloak >>>> would reject the authorization request due to failed permission >>>> evaluation >>>> (Alice has READ scope for resource Foo, but DOES NOT have WRITE scope). >>>> Nevertheless, Keycloak returns a valid RPT, granting permission for >>>> resource Foo (just for READ scope). >>>> >>>> We are aware that this behavior is UMA 2.0 compliant >>>> <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-21.h >>>> tml#rfc.section.3.6.4> >>>> : >>>> >>>> > If the value is non-null and CandidateGrantedScopes < >>>> RequestedScopes, the >>>> > authorization server MUST subsequently issue either an RPT containing >>>> > CandidateGrantedScopes (upgrading as appropriate; see below), or one >>>> of the >>>> > error codes. The reason for the two options is that granting only >>>> partial >>>> > scopes may not be useful for the client's and requesting party's >>>> purposes >>>> > in seeking authorization for access. >>>> >>>> >>>> But as the RFC explicitly points out, this behavior may not be useful >>>> for >>>> the client. We think that the RFC is right, because this renders the >>>> client >>>> unable to tell whether the authorization has been partially or >>>> completely >>>> fulfilled. And consequently the Resource Server will request again a >>>> Permission Ticket for the Foo resource and both READ and WRITE scopes, >>>> so >>>> the whole flow will be repeated over and over again. If this is >>>> Keycloak >>>> expected behavior, how can we avoid the infinite loops? >>>> >>> >>> For this particular case, each scope is associated with a specific HTTP >>> method ? Can't you obtain tickets accordingly including only the scopes you >>> need ? >>> >>> As you noticed, by default, Keycloak issues a RPT for any >>> resource/scope you sent along with an authorization request. Resource >>> servers (or clients sending authz requests directly without ticket) should >>> be able to ask only for specific resources/scopes. >>> >>> >>>> >>>> Another question is, when providing a valid RPT along with a Permission >>>> Ticket, why Keycloak deems an RPT as upgraded = true even when the >>>> requested resource has not been authorized? It returns the same RPT >>>> with >>>> just jti, exp and iat updated. Since we think that the Authorization >>>> Server >>>> must be the one stopping the UMA flow, should not Keycloak return a 403 >>>> Forbidden instead? Is this behavior configurable in any way? >>>> >>>> Thank you in advance! >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> >> >