-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long term server-side authenticated sessions #13
Comments
Hey @phochste! 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: solid/solid-oidc#81 Kind regards |
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:
|
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/access_token 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
The text was updated successfully, but these errors were encountered: