Support for UMA 2.0 (User-Managed Access) / RPT Grant Type

[PrasanthVijayy]

Hi @panva & team,

I am currently building a custom IAM solution using oidc-provider as the core Authorization Server. The system integrates OpenID Connect (OIDC) for authentication and aims to implement fine-grained authorization similar to UMA 2.0 (User-Managed Access).

I would like to understand whether oidc-provider natively supports, or plans to support, UMA-related capabilities.

Context

My current setup includes:

Using oidc-provider for OIDC flows (authorization_code, refresh_token, client_credentials)
Implementing a Resource Server that enforces authorization based on resources and scopes
Exploring UMA concepts such as:
Permission tickets
RPT (Requesting Party Token)
Policy-based access control
Key Questions
Does oidc-provider support the UMA 2.0 grant type:
urn:ietf:params:oauth:grant-type:uma-ticket?
Is there any built-in support for:
Permission ticket issuance
Policy evaluation
RPT token structure (authorization.permissions)

If not supported natively:

• Is extending via custom grant types the recommended approach?

• Are there any best practices or examples for implementing UMA-like behavior on top of oidc-provider?

• Are there any plans or discussions around adding UMA support in future versions?

What I Am Trying to Achieve

A flow similar to:

• Client obtains access token via OIDC

• Resource Server denies access and returns a permission ticket

• Client exchanges ticket at /token endpoint

• Authorization Server evaluates policies

• Issues RPT containing permissions

• Resource Server enforces access based on RPT

Additional Notes

I am aware that UMA is not part of core OAuth 2.0/OIDC specifications, but I want to align with standard patterns used by systems like Keycloak.

Any guidance on architecture, extension points, or limitations would be greatly appreciated.

Thanks for your work on this project!

[panva]

I would like to understand whether oidc-provider natively supports, or plans to support, UMA-related capabilities.

• natively supports? no
• plans to support? no plans