Use part of Solid-OIDC to login

[srosset81]

We would like to (try to) stay as close as possible from Solid OIDC Authorization Flow. Even if we don't implement DPoP immediately, favoring HTTP signature instead, the pathway to Solid compatibility would thus be shorter.

Proposed auth flow (see Solid flow)

• 1 The user access the application
• 2 The user go to the /login page of the app and select his Pod provider (or enter his WebID)
  • The Pod provider is prefilled in the query string if we opened the app from the Pod provider
• 2.1. If a WebID is provided, the app looks at the solid:oidcIssuer field in the WebID document
  • See Add missing Solid predicates #122
• 3 The app retrieves the /.well-known/openid-configuration endpoint of the Pod provider
• 4 The app generates a PKCE code challenge and code verifier
• 5 The app save the code verifier in the session storage
• 6 The app redirect to the authorize endpoint with redirect URI, client ID, code challenge
• 7 The Pod provider fetch Client ID Document (Use Solid Client ID document for applications #120)
• 8 The Pod provider ensure the provided redirect URI match the one of the Client ID Document
• 9 Show login screen if necessary
  • Ensure an ApplicationRegistration already exist, and is up to date, otherwise show authorization screen
• 10 The Pod provider generate a code and store it
• 11 The Pod provider redirects to the app's redirect URI, adding the code in the query string
• (12/13 Generate DPoP header ?)
• 14 Fetch request with returned code, code verifier (save in session storage), etc.
• 15 The Pod provider validate the code verifier
• (16/17 Validate DPoP header ?)
• 19 Generate ID token
• 20 Generate refresh token
• 21 Send back tokens to application

Pending issues

• Should we bother with DPoP for now ?
  • If we don't enforce DPoP immediately, we could avoid the steps 12-13-16-17 for now, and implement them later.
  • The token endpoint would thus be called without a DPoP header.
• What about access token ? There is no example of an access token.
  • If we don't use DPoP immediately, the app will receive a single access token, which can be refreshed.
  • In the Solid-OIDC spec, it seems access token are reference tokens, not JWT tokens
  • See also Adapt existing code to take into account app-specific JWT tokens #112 for a proposed format
• Should step 2.1 to 5 be done on the app frontend or backend ?
  • PKCE works on both frontend and backend so it's a matter of convenience.
  • Since it's the frontend which is requesting the token, it would make more sense to do it on the frontend.
• Is it the app frontend or the app backend which will receive the tokens ?
  • If the frontend receive the token, it would allow it to connect directly to the Pod
  • The access token can be formatted in a way to restrict rights to the ones of the application.
  • At first, the backend could rely only on HTTP signature to authenticate on Pod. We will need to be careful not to access another's pod data.
  • Alternatively, the backend could also request the tokens (without user interactions) and use them in its requests. It can refresh the token if necessary.
• How would this work for the Pod provider frontend ?
  • Since the login/authorization screens are on the frontend, it's difficult to generate access tokens for both the frontend and an third-party application.
  • We will keep on using custom JWT generated by the Pod server, until we complete Solid-OIDC authentication.