Authorization server behaviour for Client-Credentials Grant flow

[laurensdeb]

Context

For our use case we have a number of server-side applications which need to access resources in Solid Pods using an organisation-level WebID. Before, we used an oAuth 2.0 Client-Credentials Grant to authenticate with an OAuth AS that had support for DPoP, the webid claim and scope. This flow was implictly possible under an earlier definition of the spec as an Access Token was employed as bearer token throughout it (however OAuth discovery was broken, as the specification assumes the OIDC discovery URI to be used).

Problem description

With the recent revision of the Solid OIDC specification, we noted the use of an additional authorization service that is identified by the as_uri provided in the 401 error response of the storage endpoint. The specification however only explicitly mentions the OIDC ID token as a supported UMA profile, and not the use of Access Tokens.

Perhaps now is the time to clarify the specification and also permit the use of oAuth 2.0 Access tokens as first-class citizens (and not by coincidence as was previously the case).

Ways to resolve this issue

• Clarify how applications outside of a browser session should obtain the token necessary to authenticate with the authorization service.
• Add OAuth Access Token support as an explicit requirement for the authorization service.
• Or specify the requirements for the JWT expected by the authorization service in more abstract terms, rather than directly limiting it to concrete authentication standards (i.e. "a signed JWT with some claims X, Y and Z, which could be an OIDC ID Token or a non-opaque OAuth Access Token" )

Impact

• OAuth discovery URIs differ from OIDC discovery URIs in their format. The specification must then also clarify how to handle both of these for an issuer at the level of the authorization service, e.g. by differentiating through the claim_token_format.
• Perhaps it implies that the naming of the specification should be reconsidered, or that this capability has to be split out. But this is a broader discussion to be had, I think.

We can elaborate on this issue and our use case in a next Authentication Panel meeting if desired.

[elf-pavlik]

Thank you for your feedback @laurensdeb!

We can elaborate on this issue and our use case in a next Authentication Panel meeting if desired.

Yes, I'll add it to the agenda for tomorrow.

Before, we used an oAuth 2.0 Client-Credentials Grant to authenticate with an OAuth AS that had support for DPoP, the webid claim and scope.

Clarify how applications outside of a browser session should obtain the token necessary to authenticate with the authorization service.

We plan to shift focus to specify Client-Credentials Grant for OpenID Provider, this way server-side clients will be able to obtain ID Token from OP. Credentials issued for a given client would be bound to a specific WebID of a user, this website will be used in webid claim in ID Token.

We can discuss it in more detail tomorrow, I just wanted to bring it up here already.

BTW I think @justinwb has a similar use case to yours.