OIDC sign in that creates account does not redirect to after-registration URL about kratos HOT 3 OPEN

In particular, it does not request the scopes provided in selfservice.methods.oidc.config.providers[].scope

This is interesting, as I can't immediately tell from the code why this would be. We use the same config in both registration and login, and thus the same code URL for the OIDC provider. The translation from login -> registration only happens in the OIDC callback after the OIDC provider has redirected the user to Ory/Kratos. Any additional information you might have would help!

and it does not redirect to selfservice.flows.registration.after.default_browser_return_url.

Yes, this is true, because the login flow fully wraps the registration flow, and after it completes, does the after login flow redirect. If you have a page welcoming new users, they wouldn't be redirected as Kratos treats the flow as a login flow, leading to weird UXs. So I agree that this should either be configurable or just be changed (though this would be an unexpected breaking change, IMO).

from kratos.

This is interesting, as I can't immediately tell from the code why this would be. We use the same config in both registration and login, and thus the same code URL for the OIDC provider. The translation from login -> registration only happens in the OIDC callback after the OIDC provider has redirected the user to Ory/Kratos. Any additional information you might have would help!

This turns out to likely be my mistake - our registration flow unconditionally manually sets upstream_parameters to force the scopes fetch, and our login flow doesn't, and I should be able to configure our login flow to do it. So the only real issue is the "wrong" after login url when login is actually a registration.

In our case, you are absolutely right - after a registration, we drop the user into an welcoming onboarding flow intended to finish configuration for new users, so if they happened to click "Sign In" instead of "Sign Up", they don't get our welcoming page unless we hack that state outside of the Kratos system.

from kratos.

Retitled for specificity.

Another solution that would work— less preferable, but maybe easier—would be allowing us to disable creating accounts on sign in.

from kratos.