The most scalable and customizable identity server on the market. Replace your Homegrown, Auth0, Okta, Firebase with better UX and DX. Has all the tablestakes: Passkeys, Social Sign In, Multi-Factor Auth, SMS, SAML, TOTP, and more. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters.
We have special requirements for our user identifiers which are just random generated activation codes which might exist before the user even is registered. It is quite impractical to store them in the traits, because this would require a quite complex setup to restrict the user from not changing these traits.
So what we actually want to achieve is that the user enters an identifier which is checked by our own system which user is responsible for it and then start the login process using this user.
Describe your ideal solution
A webhook that resolves custom identifiers
Workarounds or alternatives
A workaround to achieve somewhat similar would be a toogle which adds the userid to the registration, login and recovery flows and before we submit one of those flows we call an endpoint which resolves the identifier to the correct user or if not found to a random uuid. This prevents attackers from doing a Account Enumeration Attack like in #133
Adding userid to the flows is no security risk, because it is far more difficult to guess a uuid than a simple email, which might have been already exposed by a data breach.
Preflight checklist
Ory Network Project
No response
Describe your problem
We have special requirements for our user identifiers which are just random generated activation codes which might exist before the user even is registered. It is quite impractical to store them in the traits, because this would require a quite complex setup to restrict the user from not changing these traits.
So what we actually want to achieve is that the user enters an identifier which is checked by our own system which user is responsible for it and then start the login process using this user.
Describe your ideal solution
A webhook that resolves custom identifiers
Workarounds or alternatives
A workaround to achieve somewhat similar would be a toogle which adds the userid to the registration, login and recovery flows and before we submit one of those flows we call an endpoint which resolves the identifier to the correct user or if not found to a random uuid. This prevents attackers from doing a Account Enumeration Attack like in #133
Adding userid to the flows is no security risk, because it is far more difficult to guess a uuid than a simple email, which might have been already exposed by a data breach.
Version
1.3.1
Additional Context
No response