@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
nonce
set 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_token
received from the authorization server to complete authentication. The authentication succeeds if:- The
sub
claim must match the subject registered on the canister (or otherwise this must be considered a new user) - The
iat
claim must not be too old (e.g. 10 minutes) - The
aud
&azp
claims 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
nonce
claim must correspond to the public key used to make the call, i.e the self authenticating principal of the key included innonce
is 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.