Hi team, We're having an issue using the invitati...
# ory-network
m
Hi team, We're having an issue using the invitation workflow. Some of our clients use an email protection service that opens email links to scan them, invalidating the invite links. When the invite link is invalid, our clients land on the recovery page, attempting to add their email address and request a recovery link. However, as mentioned, some of our clients use email protection services, invalidating the recovery link. This results in a loop between the email and recovery page, frustrating our clients. For context, we implemented a similar approach from this doc: https://www.ory.sh/docs/kratos/manage-identities/invite-users. We're also using custom auth pages (not Account Experience). Has anyone encountered the same issue? Do you have any alternative approach for the invite workflow? Thanks!
cc @jolly-ocean-27001
j
For further context, even though we can mitigate the issue on recovery by using OTP, it results in a terrible user experience. 1. User receives an invite 2. Link immediately expires 3. User is redirected to recovery flow (unaware) and has to now do a password reset via OTP Overall just feels a bit clunky. This wasn't an issue we had with Auth0, I imagine because the links wouldn't expire on access, but rather when they were actually used (recovery actually happens).
really keen for some help as this is annoying our clients considerably and most the ones affected are corporates.
Thank you in advance 🙏 🙂
j
Hey @refined-kangaroo-48640, as described above, we did switch to OTP
it does resolve one issue (the loop in recover flow), but it doesn't address the issue for users that receive the invite, then expire, then have to reset (via OTP). Unless I'm misunderstanding?
r
When you first invite the user, are you generating an OTP recovery flow?
j
I'll defer to @mysterious-van-90907 to confirm
r
That guide instructs you to invite users by creating a recovery link for them. You may also invite them by creating a recovery code for them, through this API: https://www.ory.sh/docs/reference/api#tag/identity/operation/createRecoveryCodeForIdentity
For further context, even though we can mitigate the issue on recovery by using OTP, it results in a terrible user experience.
1. User receives an invite
2. Link immediately expires
3. User is redirected to recovery flow (unaware) and has to now do a password reset via OTP
Overall just feels a bit clunky. This wasn't an issue we had with Auth0, I imagine because the links wouldn't expire on access, but rather when they were actually used (recovery actually happens).
This sounds like you're first creating a recovery link (with short expiry(?))
j
you might be right. The issue isn't the expiry though.
The issue is the email scanners open the link
so as soon as the email is opened, the link is crawled and becomes invalid
@mysterious-van-90907 perhaps we could look into switching the invitation workflow to OTP, thereby bypassing all this frustration to users?
👍 1
r
Exactly, that's what I'm proposing.
Generating an OTP code for the invite will still generate a link you can send to your users.
j
so basically same flow, but the link won't expire
👍 1
I think that sounds like a solid plan 🙂
any concerns here @mysterious-van-90907?
m
Hey @refined-kangaroo-48640, I see the response for the https://www.ory.sh/docs/reference/api#tag/identity/operation/createRecoveryCodeForIdentity is
Copy code
{
  "recovery_link": "/ui/recovery?flow=1440ef91-3863-43e7-bb44-ecb64cc2eef3",
  "recovery_code": "118217",
  "expires_at": "2024-03-22T04:07:16.37783255Z"
}
Will the "recovery_link" not be invalidated if scanned by email scanners? Invalidating the flow ID?
r
Nope, because the user will have to input the code and submit the form.
For "magic links" the equivalent code is part of the query parameter of the URL.
which is why it's sometimes invalidated when scanned by security software
m
Another thing, is there a way to send both OTP and recovery link UI using https://www.ory.sh/docs/reference/api#tag/frontend/operation/updateRecoveryFlow?
r
Not sure I'm following.
m
Would adding
{{ .RecoveryCode }}
and
{{ .RecoveryURL }}
in the email template work?
r
Should work, yes.
m
Thanks! We'll look into it.
It looks like it doesn't work if both the placeholder for the code and URL are in the same email.
r
Ah, I'm noticing right now the field
.RecoveryURL
is not available in the the OTP recovery template.
I was under the impression that you construct the email yourselves?
h
Hello everyone, thank you for raising this issue. You have also create a ticket in ZenDesk. Please use only one channel (ZenDesk) to discuss these issues, because otherwise we have multiple people working on the same topic which leads to confusion and duplicate work. Thank you!
j
Will do @high-optician-2097, thanks!