Support id_token_hint as Sign in method

[wdantuma]

One of the options to provide a better login UX for apps is supporting FedCM, one of the steps needed in a FedCM flow is to accept an token as means of identification. This PR implements the standardized OIDC id_token_hint parameter ( support for it was already partly in the code base)

Specification: https://openid.net/specs/openid-connect-core-1_0.html

This PR adds:

• accepting an id_token_hint in the authorization request
• validating the signature in the IdToken with the user's DID's verificationMethod
• creating a session for the user and continue with the consent screen

In this implementation I use a plain text id_token_hint because the PR has to be able to get the issuer from the token ( it needs to know where to send the request ), we could also choose to accept both an login_hint and id_token_hint to achieve this. also all the claims in the token are already public in ATProto.

Something we might also want to add is accepting IdTokens signed by one of the rotation keys listed in the user's DID document. This creates the possibility of using an external app (wallet maintaining the rotation keys) to use in the login flow, this is needed e.g when a user doesn't have an active login session on the device used, in this scenario an QR code could be presented to the app ( wallet ) which then provides a signed idToken. You could also choose to use a method where you let the idp ( PDS) authenticate (federate) with a SIOP flow but that would add extra user interaction.

IdTokens used in this flow should be short lived, in the demo I chose for 30secs

There's a demonstration of using this method here https://bsky.app/profile/willem.dobs.nl/post/3mcr73bs3pk2t

This isn't adding full FedCM support yet it is only a first step.

[matthieusieben]

Hello !

First of all, thank you for your contribution and interest in atproto.

FedCM integration is part of our road map for the coming months so we definitely want to improve its support in our code base.

There are several issues with this change:

0. We need this to work universally (on all PDS) so we first need to agree on specifications. I suggest you open a Github Discussion and/or a proposal

1. Issuing id_token should be part of the token response and would definitely need to be signed with the account's key (not the AS key), as a mean for oauth clients to verify that the AS is indeed controlling the account's DID keys.

2. On the actual implementation: the presence of an id_token_hint should not be enough to consider that the user has recently signed-in into that device (which is what upsertDeviceAccount does). We should instead, have some kind of temporary session, that is valid only for that id token, that allows showing the consent screen, then accepting right away. The best way to do this would probably be to bind the particular request (identified by the requestUri) to the sub from the id_token (instead of using null as is currently done by default).

[wdantuma]

Hi Matthieu,

0. We need this to work universally (on all PDS) so we first need to agree on specifications. I suggest you open a Github Discussion and/or a proposal

Fully agree, if i'll find the time will create a proposal, but wanted to start with something we can experiment with

1. Issuing id_token should be part of the token response and would definitely need to be signed with the account's key (not the AS key), as a mean for oauth clients to verify that the AS is indeed controlling the account's DID keys.

I wanted to split up the work in several more or less independent PR's this is just a first step, the IdToken in case of FedCM would be issued by the FedCM /assertion endpoint which would be implemented in a next PR but before I do that work I need to know if this is something we want. Signing the token with one of the user keys is also my preferred way, but didn't want to introduce a dependency on @atproto/identity yet

2. On the actual implementation: the presence of an id_token_hint should not be enough to consider that the user has recently signed-in into that device (which is what upsertDeviceAccount does). We should instead, have some kind of temporary session, that is valid only for that id token, that allows showing the consent screen, then accepting right away. The best way to do this would probably be to bind the particular request (identified by the requestUri) to the sub from the id_token (instead of using null as is currently done by default).

I agree but was not sure how to correctly add the ephemeralToken in the flow, need first to understand the atproto codebase better

[wdantuma]

PR updated to verify the idToken with the users signing key and don't store the session on the device but use an ephemeraltoken for the consent flow.

[wdantuma]

Added a comment to discussion #2796