Skip to content
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

Open
phochste opened this issue Feb 21, 2022 · 5 comments
Open

Long term server-side authenticated sessions #13

phochste opened this issue Feb 21, 2022 · 5 comments
Labels
challenge technical problem applied to a use case proposal: approved ✅ topic: security

Comments

@phochste
Copy link

phochste commented Feb 21, 2022

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:

  • Server processes need to be able to run without any human interaction (or even access to the server) ..e.g. no entering of passwords
  • Server processes could have their own Webid not connected to a human user
  • Server processes need to proof their identity when requesting resources from remote Solid Pods
  • Many processes can run simultaneously with the same Webid (and thus identification/authentication requirements)
  • Each process has a plethora of choices to be implemented in any programming language

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 and DPoP header is trivial and can be implemented easily in any programming language.

Requirements command line tool to:

  • Generate a private/public key
  • Publish the public key as <someurl>/jwks
  • Publish a minimal OpenID configuration as <someurl>/.well-known/openid-configuration
  • Generate an access_token (id_token in the future)
  • Given a stored access_token generate the headers (e.g. as curl would need it)

Acceptance criteria

  • Command line tool to generate public/private keys/jwks/openid-configuration/accesstoken and headers
  • Provide an example how the accesstoken can be used in Python, Groovy, Node , ...
  • Provide a tool to publish jwks/openid-configuration
  • Demonstrate that these tokens work to update a remote Solid Pod where the server WebID has given the ACL rights to update a resource

Pointers

Scenarios

@phochste phochste added challenge technical problem applied to a use case proposal: pending ❓ labels Feb 21, 2022
@laurensdeb
Copy link

laurensdeb commented Feb 21, 2022

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: solid/solid-oidc#81

Kind regards
Laurens

@phochste
Copy link
Author

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.
    - I ask this because in server processing you want to minimise missing a refresh a token (e.g. when you need to reboot a server , restart processing, network outage).

@pheyvaer
Copy link
Contributor

@pheyvaer
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
challenge technical problem applied to a use case proposal: approved ✅ topic: security
Projects
None yet
Development

No branches or pull requests

6 participants