There are multiple authorization paths in the server.
- RS <-> AS interactions where a PAT is required, following the UMA specification.
- Client claims during a token request.
- Other client interactions outside of the specifications, such as policy management and access requests. This uses standard OIDC headers.
The problem is if some of these overlap, which happened in #101, where the client wanted to access the list of registered resources. The current solution is to allow both the PAT flow, and standard client OIDC authentication, but it should be investigated if these can be more aligned since in the end both use OIDC tokens, but slightly differently.
There are multiple authorization paths in the server.
The problem is if some of these overlap, which happened in #101, where the client wanted to access the list of registered resources. The current solution is to allow both the PAT flow, and standard client OIDC authentication, but it should be investigated if these can be more aligned since in the end both use OIDC tokens, but slightly differently.