Authorization mechanism to unify Rich Authorization Requests and Dynamic Scopes handling

[dgozalo]

In an effort to improve Keycloak's authorization mechanisms, we've been discussing the implementation of Dynamic Scopes and Rich Authorization Requests separately for the past few days.

As @stianst mentioned in a few places, we believe that these two authorization mechanisms should be handled in a unified way in order to avoid scattering all possible authorization handling proposals that may come in the future as OAuth evolves and GNAP starts being implemented.

The proposal PR has been created: keycloak/keycloak-community#325

From now on, let's unify all discussions about these topics in here.

[tnorimat]

Hello @dgozalo, @mposolda,

As @mposolda mentioned in #8488 (reply in thread) , it might be better to consider not only Dynamic Scopes and RAR but Grant Management for OAuth 2.0 (especially, how revoking consent/grant affects (Offline)UserSession and (Offline)AuthenticatedClientSession) because the current Keycloak only manages consent/grant of pre-registered scopes.

[mposolda]

@tnorimat Thanks for pointing this! We will consider adding some basic support for grant management API as part of this work and it will be mentioned in the design.

One thing, which I don't see to easily support is support for concurrent grants as described in the specification https://openid.net/specs/fapi-grant-management-01.html#section-3.5 . Adding support for them will require more refactoring of model as currently Keycloak always have just single UserConsentModel per the combination of user and client. Hence might be postponed for now until we have new store available. Also it will require changes in various other screens in Keycloak including UI. Question is, if we ever need concurrent grants, but that is something to be discussed as an additional step.

[tnorimat]

@mposolda IMO, it might be appropriate to take this feature as an additional step. It seems to be take a lot of time to complete whole Grant Management at one try. Therefore, supporting requirements described by Grant Management step by step by several PRs might be a good way.

[tnorimat]

As already mentioned, a consent screen needs to be enhanced to show contents determined dynamically, depending on an authorization request.
There is the other discussion trying to enhance the consent screen, but it does not directly relate to the discussion here.

[sschu]

I was reading https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar#section-3.1 and found the following information interesting:
"authorization_details" and "scope" can be used in the same authorization request for carrying independent authorization requirements.
The AS MUST consider both sets of requirements in combination with each other for the given authorization request. The details of how the AS combines these parameters are specific to the APIs being protected and outside the scope of this specification.

How would we combine these two things? A simple option would be to treat them independently and just allow "adding more things" to be authorised and not scopes modifying the semantics of an RAR.

[jbman]

As described at this discussion, this could be solved by mapping scopes into the rich authorization request structure internally.
A simple scope like "email" would be processed as

{
  "type": "email"
}

alongside other rich authorization data elements of other types. If the same type "email" occurs as authorization data element, Keycloak oould reject this combination. In all other cases the scopes and data element types could usually be handled independently one after the other with a corresponding "handler " implementation. These handlers will not only map data into the resulting tokens, they will need very type-specific processing logic as in the example at section 6.1 and 7.

In the beginning Keycloak may not have any built-in handlers, except for existing scopes. But at least a SPI and handler implementation would be needed as example how to process a rich request which includes more than a "type".

[dgozalo]

The PR for this proposal has been created in the Community repository: keycloak/keycloak-community#325

[cgeorgilakis]

We are interesting in dynamic scopes for migrating one old system to Keycloak. Now RAR is out of scope for us. We have enabled dynamic-scopes profile (together with all experimental features for other reasons) in Keycloak version 18.

Is there any documentation about current implementation of dynamic scopes? I see that the dynamic scopes epic is almost finished. Is dynamic scopes fully supported - if enabled - in version 18? Is any implementation part missing? What are your plan for fully support dynamic scopes at least as experimental?

I see in the original github discussion that tenant:tenant_1 ( maybe scope must be tenants:tenant_1 ) is returning only tenant_1 tenants. In our mind dynamic scopes must do this - filter claims. I can not do this in Keycloak version 18. I am confused after it with keycloak-community PR and this discussion and dynamic scopes epic. Could you explain in few words what dynamic scopes (fe tenants:tenant_1) will do in access token, introspection endpoint and Userinfo endpoint? What are the difference about static client scopes and dynamic scopes in this?

[alexisdondon]

Hi, i have activated the dynamic scopes features to give a try but i have some difficulties to find documentation on how to configure this.

I would try a dynamic feature, let say to get a token with a scope : groups:nameOfGroupToBefiltered or regexp or whatever current keycloak implementation could understand

[bobbabuilder]

I've had my struggles with it as well, as it's not well documented yet.

Got it working in 24.0.1 and was quite simple. Eg name: client
Put on the switch for "dynamic" scope, include it token scope (as I can then fetch it in my CustomProtocolMapper). Ensure that the client you use have it as an optional scope and you are good to god. You can then specify scopes e.g as "openid email client:80"

[jjmiranda]

Hi community, is RAR yet implemented now in Keycloak? Any good tutorial o doc about RAR to use with Keycloak?