Users must manually log into the official web gui and generate a “personal login token” (perhaps this is called CLI token in “OpenID speak”?). This is a single-use token that can be used to create the real token (access and refresh). It is a base64 encoded json containing an url to OpenID configuration (well_known_link, ends with “/.well-known/openid-configuration”) and an authentication token that can be used (only) for creating the real token. To create the token one then must send a request to the “token_endpoint” url found from the OpenID configuration (ends with “/protocol/openid-connect/token”), with a form of password authentication using credential information contained in the initial single-use login token.
Is this a flow which differs from existing backends in Duplicati?
Edit: I guess it is, as you already expressed with:
which Duplicati can’t do AFAIK, though it does do OAuth (which underlies it) in Duplicati OAuth Handler.
I actually have a branch of Duplicati now, which has a rough implementation of the entire authentication flow (couldn’t resist). But it simply creates an entirely new access/refresh token every time and requires me (the user) therefore to supply a fresh personal login token every time. This, how Duplicati should manage the tokens, is the challenge.