Open phochste opened 2 years ago
Hey @phochste! We’re currently discussing a more definitive solution for non-client-side Solid OIDC sessions in the authentication panel.
If you have any further suggested use cases or requirements, we’d be glad to discuss them in the panel. We hope this can lead to a proper discussion of these alternative flows in the authentication specification.
PR can be found here: https://github.com/solid/solid-oidc/pull/81
Kind regards Laurens
hey @laurensdeb
This is indeed exactly in line with what is required for our use-cases. I don't know the details of the OAuth 2.0 Token Exchange specification, but it seems that it should be for any client not much more processing than reading JSON and setting HTPP headers?
What I am interested in is the minimal infrastructure requirements for server scripts to make this all possible:
Do they need to install OAuth servers (or have access to them in a way) or is it possible with a minimal requirement to publish a public key somewhere?
For perpetual access I guess that it is dependent on the refresh tokens from the OAuth server where the server script gets the access_token.
This might be useful for this challenge https://docs.inrupt.com/ess/latest/services/service-application-registration/?highlight=session#app-registration-config
This would already be a great start https://communitysolidserver.github.io/CommunitySolidServer/5.x/usage/client-credentials/
Pitch
Current Solid authentication libraries are mainly targeted to browser clients where human agents need to be identified and authenticated against a choosen OIDC provider. E.g. the prefered OIDC provider can be set in the WebID profile of an agent. The Solid OIDC identification/authentication process results after some back and forth communication in _id_token/accesstoken that typically have a lifetime ranging from a few minutes to a few days (when they aren't refreshed).
When doing server side processing of data there are other requirements:
Desired solution
In theory the current Solid-OIDC tokens are not more than a signed JWT with the WebID of the agent, a client id and the web location of the OIDC issuer. All can be in control of the a server instance (e.g. a web server that publishes its own public key on a
/jwks
URL with a minimal.well-known/openid-configuration
).Given an access token, adding it as
Authorization
andDPoP
header is trivial and can be implemented easily in any programming language.Requirements command line tool to:
<someurl>/jwks
<someurl>/.well-known/openid-configuration
curl
would need it)Acceptance criteria
Pointers
Scenarios