@ilbert: Find below a very concise summary of the design. Let me know if you need more information. Ideally we would build a reference implementation of that flow, but currently we do not have one.
- The dapp front-end generates a session public/private key pair
- The dapp initiates an OpenID Connect authentation flow with response_type=id_token and the nonceset to the public key generate in step 1.
- When the OpenID Connect flow completes (i.e. the user is redirected back to the dapp) it then makes a canister call to the back-end with the id_tokenreceived from the authorization server to complete authentication. The authentication succeeds if:- The subclaim must match the subject registered on the canister (or otherwise this must be considered a new user)
- The iatclaim must not be too old (e.g. 10 minutes)
- The aud&azpclaims must match the application id as registered with the OpenID Connect authorization server
- The signature on the ID token must be valid and signed with a well known authorization server public key. Can most likely be fetched using HTTP outcalls from the JSON Web Key Set (JWKS) endpoint.
- The nonceclaim must correspond to the public key used to make the call, i.e the self authenticating principal of the key included innonceis equal to thecaller
 
- The 
If step 3 succeeds, the canister should associate the caller principal with the user matching the sub claim for the duration of a reasonable session. Alternatively, the canister can also issue a delegation to a principal associated with the user profile on the public key. The delegation has has an expiration and hence relieves the canister from checking session expiry itself.
I hope this helps.