No email verfication view after registration with login_challenge

[mh-zwave]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Network project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe the bug

We have a selfhosted Kratos + Hydra enviroment. For the Kratos UI we used the https://github.com/ory/kratos-selfservice-ui-node repo as reference for our own implementation.

Reproducing the bug

When we run a registration flow with a Hydra login_challenge the email verification view is skipped. If we do the same without a Hydra login_challenge the email verification view will be displayed.

Relevant log output

No response

Relevant configuration

version: v0.13.0

log:
  level: debug
  leak_sensitive_values: true

dsn: xxx
serve:
  public:
    base_url: https://xxx.xxx.xxx.tech:4433/
    cors:
      enabled: true
      allowed_origins:
        - https://xxx.xxx.xxx.tech
        - https://xxx.xxx.tech
        - https://*.xxx.xxx.tech
      allowed_methods:
        - POST
        - GET
        - PUT
        - PATCH
        - DELETE
      allowed_headers:
        - Authorization
        - Cookie
        - Content-Type
      exposed_headers:
        - Content-Type
        - Set-Cookie
    tls:
      cert:
        path: /etc/letsencrypt/live/xxx.xxx.tech/fullchain.pem
      key:
        path: /etc/letsencrypt/live/xxx.xxx.tech/privkey.pem
  admin:
    base_url: https://xxx.xxx.xxx.tech:4434/
    tls:
      cert:
        path: /etc/letsencrypt/live/xxx.xxx.tech/fullchain.pem
      key:
        path: /etc/letsencrypt/live/xxx.xxx.tech/privkey.pem
session:
  cookie:
    domain: xxx.xxx.tech
    path: /
    same_site: Lax
cookies:
  domain: xxx.xxx.tech
  path: /
  same_site: Lax
selfservice:
  default_browser_return_url: https://xxx.xxx.tech/
  allowed_return_urls:
    - https://xxx.xxx.tech/
    - https://xxx.xxx.tech/dashboard
  methods:
    password:
      enabled: true
      config:
        min_password_length: 8
        identifier_similarity_check_enabled: true
        haveibeenpwned_enabled: true
    profile:
      enabled: true
    totp:
      config:
        issuer: Cloud
      enabled: true
    code:
      enabled: true
      config:
        lifespan: 30m
  flows:
    registration:
      enabled: true
      ui_url: https://xxx.xxx.xxx.tech/registration
      after:
        password:
          hooks:
            - hook: show_verification_ui
            - hook: web_hook
              config: 
                url: https://xxx.xxx.xxx.tech/auth/registration_hook
                method: POST
                body: file:///home/ubuntu/ory/after_registration_hook.jsonnet
            - hook: session
    login:
      ui_url: https://xxx.xxx.xxx.tech/login
      after:
        hooks:
          - hook: require_verified_address

    settings:
      ui_url: https://xxx.xxx.xxx.tech/settings
      required_aal: highest_available

    verification:
      enabled: true
      ui_url: https://xxx.xxx.xxx.tech/verification
      use: code
      notify_unknown_recipients: true

    recovery:
      enabled: true
      ui_url: https://xxx.xxx.xxx.tech/recovery
      use: code 
      notify_unknown_recipients: true

    logout:
      after:
        default_browser_return_url: https://xxx.xxx.tech
        
    error:
      ui_url: https://xxx.xxx.xxx.tech/error

session:
  whoami:
    required_aal: aal1

identity:
  schemas:
    - id: customer
      url: file:///home/ubuntu/ory/schemas/customer.schema.json
  default_schema_id: customer
courier:
  smtp:
    from_address: xxx
    from_name: Test
    connection_uri: xxx

oauth2_provider:
  url: https://xxx.xxx.xxx.tech

Version

v0.13.0

On which operating system are you observing this issue?

Linux

In which environment are you deploying?

Binary

Additional Context

No response

[aeneasr]

Interesting finding, that definitely smells like a bug.

[alnr]

related? #3320

[woylie]

I'm seeing the same issue.

1. initiate OAuth2 login flow
2. GET /self-service/registration/browser?login_challenge={login_flow.oauth2_login_challenge}
3. fill out and submit registration form
4. user is directly redirected to OAuth2 callback URL

oauth2_provider.override_return_to is set to true.

I tried working around this by accessing /self-service/registration/browser?after_verification_return_to={login_flow.return_to} instead. That seems to work until the very end (with the drawback that I can't access the OAuth2 client information in the registration flow): I can register and verify, but when I submit the log in form, Kratos immediately asks me to confirm the action again by entering my password a second time. After that, I'm being redirected correctly to the callback URL, but the double authentication is a bit awkward.

If someone has a better workaround until this is fixed, please let me know.

[kghost]

Suffering from the same problem, is there any progress ?

[jpogorzelski]

I confirm that it still occurs.

[knaoe]

I confirmed this was fixed in master branch. They had discussed in ory/network#320 (its not kratos repo, but they are talking about kratos). The fix will be included in a future release, possibly kratos v1.1.0.

[alnr]

Yep, this was resolved in #3427

Will be part of Kratos v1.1.