tests for implemented flows (username password)

[hifabienne]

As ZITADEL Admins we want to ensure that all of the implemented oidc flows always work with the current ZITADEL Cloud version.

Acceptance Criteria

• Flow
  • Admin login
  • User register with password
  • User register with passkey
  • User reset password
  • User change password on existing user
  • User login with password
  • User login with password and OTP SMS
  • User login with password and OTP Email
  • User login with password and TOTP (Google Authenticator emulation)
  • User login with passkey
  • User login with external IDP
    • Apple
    • Generic JWT
    • Generic OAuth
    • Generic OIDC
    • Github
    • Github Enterprise
    • Gitlab
    • Gitlab Self Hosted
    • Google
    • LDAP
    • Microsoft
    • SAML
• Fixtures (preparation of user to use in tests)
  • User with password
  • User with passkey (User register with passkey, because of GUI for passkey registration)
  • User with OTP SMS
  • User with OTP Email
  • User with TOTP (Google Authenticator emulation)
  • User with link to external IDP
    • Apple
    • Generic JWT
    • Generic OAuth
    • Generic OIDC
    • Github
    • Github Enterprise
    • Gitlab
    • Gitlab Self Hosted
    • Google
    • LDAP
    • Microsoft
    • SAML
• Sink ( necessary for tests with externally sent notification)
  • Receiver for Email
  • Receiver for SMS
  • Read sent notifications for code
  • Setup of Email and SMS provider configurations in ZITADEL as HTTP providers
  • Container for runtime in Docker compose
• OIDC ( using the typescript login with OIDC )
  • Redirect to application
  • Redirect to default
  • Token has expected claims (have a look at current token and take those claims, so we have a starting point)
• PRs can only be merged if e2e tests succeed (test against latest ZITADEL docker)
• Nightly e2e acceptance tests ensure we detect breaking cloud version changes early (@hifabienne I (@eliobischof) changed the word e2e to acceptance) chore: test accepance against QA and Prod #303
• Tests don't rely on results of other tests

Additional Test Cases:
Given: Username password login is enabled

• Login with username without suffix
• Login with username with suffix
• Login with email address
• Login with phone
• Login with disabled user --> error
• Login with locker user -->
• Not existing username --> error
• Wrong password --> error

Open Questions

How do we want to run the e2e tests?
To preview deployement?
In the pipeline?

[eliobischof]

I would add to the AC:

• PRs can only be merged if e2e tests succeed
• Nightly e2e tests ensure we detect breaking cloud version changes early

Estimation: 3

[peintnermax]

I would add to the AC:

• PRs can only be merged if e2e tests succeed
• Nightly e2e tests ensure we detect breaking cloud version changes early

Estimation: 3

agree 👍