oauth-wg / oauth-first-party-apps

https://datatracker.ietf.org/doc/html/draft-parecki-oauth-first-party-apps
Other
11 stars 8 forks source link

E-mail confirmation code #86

Closed yaronf closed 3 months ago

yaronf commented 6 months ago

Sec. A.4, The more typical use case is for the user to follow a link received in the email message. Please add a bullet that describes this alternative. Should the auth_session be part of the URL?

aaronpk commented 4 months ago

The auth_session is a secret known only to the device, so should not be sent in an email. It would be a separate code sent in the email link, and the native client would take the code from the link and include the auth_session and the code in the request to the AS.

yaronf commented 3 months ago

Re: auth_session, understood. But this wasn't my point. The current text is:

The Client presents a user experience guiding the user to copy the e-mail verification code to the Client.

I think in reality, it would not be a manual copy-paste. Instead, the email would contain a link that redirects into the Client (in a mobile app, through registration of the app to some URLs).

aaronpk commented 3 months ago

Yes that should be described as well. But both flows are common. The email link tends to be more common for email verification where the user is expected to complete that task later, but email codes are more common when used as a second factor.

In any case, the protocol doesn't change for either one, since the link in the email would ultimately launch the native app passing the email verification code into the app, which the app would then send in a request along with the auth_session it already has.