Registration

Describe the bug

Right now, CSRF errors end in an ugly JSON view that shows some error info. No real use will be able to deal with that.

Reproducing the bug

Perform a login/registration flow with an empty/changed CSRF value (e.g. copy the /login?request=... to an incognito browser).

Expected behavior

I would expect to either be redirect to the /login page with an error message telling me that I have to redo the flow due to security reasons (potential CSRF attack) or end up at /?error although the former is better UX.

Environment

• Version: all

these are just random notes, for now

• Abstraction layer for login
  • username+password
  • passwordless
  • SSO
  • OIDC
  • LDAP...maybe?
• Abstraction layer for registration
• Should support captchas
• 2FA strategies
  • sms
  • google authenticator?
• storing meta data and also oidc compliant data

• Configuration endpoint
  • Fallback to environment variables
  • Multiple emails per account
• Anomaly Detection
  • Brute-force Protection
  • Breached-password Detection
  • Login patterns
• Authentication
  • Client-side -> pass by ref? pass by val? if by-val then how to revoke/refresh?
  • Server-side -> easy, just send "ok"
• Pools, should allow plugin infrastructure
  • Database
    • There should be some type of password policy
      • Password history (remember last X passwords)
      • Password dictionary
      • Personal data (disallow data from metadata, username, etc)
      • Check with troyhunt's password database
      • Password Strength (minimum length, complexity)
  • Social
    • We probably need to enrich the profile data, this could be done with a trigger. Alternatively we could have default implementation / default enrichment strategies here.
    • How do we deal with the redirect URL? how do we transmit the auth data on the back channel?
  • Enterprise (LDAP, ...)
  • Passwordless < requires transactional api
  • API to list all of the auth methods to show the proper buttons etc
• MFA
  • Using push notifications (requires app)
  • Using duo security
  • Using Google AuthN
  • Using SMS
• Notifications
  • Add an ory:// provider that works together with sparkpost
  • Add support for smtp:// providers
  • Templates with i18n are required for this - or maybe just a trigger?
• Callbacks/Triggers/Event Manager (should be implementable with HTTP, NATS, ...)
  • Triggers when registering a user (pre/post) - for example enriching data from SSO providers?
  • Triggers when authenticating a user - for example block authentication?
• User Management
  • Ban/Block
  • We could have two types of metadata, app (not writeable by user) and user (writeable by user)
• Multi-tenant, realms
• Searching users
  • ... could be a remote api maybe?

It should be possible to (un-)link delegated identities (e.g. from Google) to existing identities in the system.

• Document account enumeration
• The delegated identity must not have a profile yet. If a profile exists, that profile must be merged or removed first using the REST API
• If the email (or any other identifier?) exists already for some other identity we should disallow sign up and ask to log in, then link the accounts. Anything else might lead to account impersonation or unexpectededly having 2 accounts which later need to be merged.

Included

• I want to be able to sign into my account when e.g. Google bans me or my Google account was stolen (recovery).
• I want to be able to recover my account using my email address
• https://postmarkapp.com/guides/password-reset-email-best-practices#secure-password-reset-emails

Excluded

• I want to set up one or more security questions for account recovery: Security questions have often been abused in social engineering attacks (e.g. Celebrity Leaks) because their answers ("What's your mother's maiden name?") are often easy to discover using OSINT attacks. Needs docs.
• I want to recover my account using SMS or phone calls: SMS for credential exchange isn't particularly secure (source, source). The problem with account recovery is that a single TOTP can switch ownership of an entire account. While with 2FA, both credentials (password) and TOTP are required, account recovery really has only one credential which can be eavesdropped using sim swapping and similar. Maybe something like IMSI can help though but that needs further investigation. Needs docs.

All storage adapters need a persistent DBAL. We want to support Postgres in the beginning, more adapters might follow at some point.

Right now, sign up and login can be done over and over again. We should protect these endpoints with some type of challenge (e.g. recaptcha) on consecutive requests.

Providing a tool to automatically register OAuth2 Clients (using OIDC Dynamic Client Registration) would be super helpful when setting up Social Sign In.

• GitHub: It is unfortunately not possible to programmatically create an OAuth2 Client because no such API endpoint exists.
• Google: apparently not supported
• LinkedIn: unknown

/cc @zepatrik

The prevent extension would:

• always prevent the user from writing to this field in a selfservice mannger (registration, profile update, ...)
• prevent the user from reading in a selfservice manner (e.g. ``) the field if a config option is set

e.g.

{
 "hive": {
    "protected": {
       "readable": true // just an example
     }
  }
}

This field could still be modified/read when accessing the identity API through the admin port.

Alternatively, the identity model would get a privileged field that acts similar to traits and that is only writable through the admin port. It would be difficult to decide about the readability here. Other companies allow reads but no writes here.

It should be clear that users can see their own data by accessing /session/me. So things like {"note": "this customer is a fucking asshole"} might not be a good place to store in there.

(End-)Users should be able to sign up and sign in using form-based flows. Signing up usually requires form fields:

• username or email
• password
• csrf
• additional metadata such as "accept ToS", "first name", ...

Signing in requires form fields:

• username or email
• password
• csrf

Generally, username and email should be ambivalent. It should be possible to sign up/in with either one of those depending on domain policy (force username sign in, force email sign in).

Additional required features:

• This feature must be protected against spam. The most obvious course of action is adding a CAPTCHA challenge to either sign up or sign in. The CAPTCHA should be activated after X attempts of signing in, or after creating Y accounts on the system.
• It should be possible to completely disallow registration. Then, users could only be registered by using the administrative API. This is possible by the sign-up page to show an error message or redirect the browser to another api endpoint. Alternatively the sign up endpoint could be firewalled.
• It should be possible to require a token (e.g. invite system) when signing up: The sign-up endpoint can implement that check. We might have an API for generating such tokens but that's optional.
• It should be possible to require account activation. This only works with out-of-band communication via e.g. email or phone. I guess this could be a hook?
• It should be possible to issue a session after sign up. It should also be possible to not issue a session after sign up. This really depends on domain logic.

Hooks (selfservice.login.(before|after)) determine how hive should behave when a login or registration was completed without an error state. They do not modify the actual data of the identity and/or session. Therefore, they should be called "workflow" and "workflow step/handler/runner/part/item" from now on.

Example: Password Registration

In this example, we want the user to be immediately signed in and redirected to our home page after registering a new account using email/password.

Configuration:

selfservice:
  registration:
    after:
      password:
      - run: session
      - run: redirect
        config:
          default_redirect_url: http://example.com/welcome
          allow_user_defined_redirect: true # Allows "return_to" feature

Example: Password Registration with (Email/Phone) Verification before login

In this example, we want the user to activate his/her account (by verifying the email or phone) before being able to sign in to our platform using email/password.

Configuration:

selfservice:
  registration:
    after:
      password:
      - run: verify
      - run: redirect
        config:
          default_redirect_url: http://example.com/please-active-account.html
          allow_user_defined_redirect: false
  login:
    after:
      password:
      - run: verify # enforce that at least one email or phone is verified
      - run: session
      - run: redirect
        config:
          default_redirect_url: http://example.com/welcome

Flow:

Example: Password Registration with (Email/Phone) Verification and immediate Login

Alternatively, we could want our new users to be signed in immediately after registration, but still require email verification. The welcome page would then, for example, show a red notification bar with "please verify your email"

Configuration:

selfservice:
  registration:
    after:
      - run: verify
      - run: session
      - run: redirect
        config:
          default_redirect_url: http://example.com/welcome.html
          allow_user_defined_redirect: true

Example: Password Registration with JSON Response

In this example, we would expect a application/json response. This could be used for native apps for example.

Configuration:

selfservice:
  registration:
    after:
      password:
      - run: json

Example: Disallow Registration during Weekdays

We might want to disallow registration during weekdays:

selfservice:
  registration:
    before:
      password:
      - run: json-rpc
         url: http://api.example.com/workflows/before-registration

before-registration.js

const route = (r, w) => {
  if (isWeekDay) {
    w.send(403)
    return
  }
}

Example: Disallow Registration based on external service

Assuming we want to forbid registration because some upstream system (e.g. CRM) says "no" to the identity data

selfservice:
  registration:
    after:
      password:
      - run: json-rpc
         url: http://api.example.com/workflows/after-registration

after-registration.js

const route = (r, w) => {
  if (checkIfAllowedByCRM(r.body.identity)) {
    w.send(403) // this will tell hive to delete the identity
    return
  }
}

Example: Create user at Stripe after Login / Registration

selfservice:
  login:
    after:
      password:
      - run: json-rpc
         url: http://api.example.com/workflows/stripe
  registration:
    after:
      password:
      - run: json-rpc
         url: http://api.example.com/workflows/stripe

stripe.js

const route = (r, w) => {
  const user = r.body.identity.id
  const stripeData = createUserAtStripe(user)

  w.json({ traits: { stripe: stripeData } })
}

Example: enforced 2FA

Here we're using the built-in 2fa module:

selfservice:
  login:
    after:
      password:
      - run: 2fa
  registration:
    after:
      password:
      - run: 2fa

hive/2fa.go

if hasExecuted2FA(ctx.Request) {
  session.Enhance("I am now 2fa yay")
  return nil
} else if has2faEnabled(ctx.Request) {
   return ErrorRedirect("https://example.org/2fa-login")
} else !has2faEnabled(ctx.Request) {
   return ErrorRedirect("https://example.org/2fa-setup")
}

Example: contextual 2FA (e.g. based on source ip)

Assuming there is some context for our 2fa like a non-internal network ip

selfservice:
  login:
    after:
      password:
      - run: json-rpc
         url: http://api.example.com/workflows/2fa
  registration:
    after:
      password:
      - run: json-rpc
         url: http://api.example.com/workflows/2fa

2fa.js

if (ipRange !== "192.168.0.0/24") {
  if hive.is2faEnabled(r.query.request)
    send({ redirect_to: "https://example.org/2fa-setup" })
  else if hive.is2faEnabled(r.query.request)
    send({ redirect_to: "https://example.org/2fa-login" })
  else
    send(200)
}

Right now it is possible to access login and registration even when a session exists. This should not be allowed.

This currently affects e.g. checkboxes during OIDC sign up as well as password sign up

• Fix "false" string in password sign up
• Fix missing "true" value for oidc sign up

This flag would run the daemon in dev mode:

• All URLs can be http
• ...

Assuming we have strategy "password" and "google-oidc" enabled. Assuming [email protected] has a registered account at hive using the password strategy. If another user with "google-oidc" signs up, and also has [email protected] as email, this should not be allowed. This should work with all strategies.

Instead, the user should be requested to "combine" his/her accounts by linking them.

We need to make sure that our validator checks for this usecase and rejects any requests not compliant with this policy.

• Disallow oidc strategy sign up for identities that already have the email registered (form error)
• Disallow password strategy sign up for identities that already have the email registered (form error)
• Write test for oidc strategy
  • Test double sign up with existing identifier from password strategy
  • Test double sign up with existing identifier from oidc strategy
• Write test for password strategy
  • Test double sign up with existing identifier from password strategy
  • Test double sign up with existing identifier from oidc strategy

The registration form parser supports:

• numbers (float64)
• boolean
• string

It also supports json paths for traits in the form of traits[foo.bar.baz] using sjson.

Examples

• Include examples from sjson docs or build our own

Limitations

Nested Items

The way json schema works is that required propagates to deeper levels. If key baz of foo.bar.baz is always required, foo and bar must also be required.

When using form fields, this is very challenging to automate for us at the moment (explain here that go json schema is limited). Basically, the form payload would need to send {foo:{bar:{}}}, otherwise the only error you will see is that foo is required, which can then not be properly assigned to the actual <input name="traits[foo.bar.baz]"> because the keys do not match.

Workaround:

How To: Nested elements

Assuming a traits model:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "name": {
      "type": "object",
      "properties": {
        "first": {
          "type": "string"
        },
        "last": {
          "type": "string"
        }
      }
    }
  }
}

You could address name.first this with a form name of:

<input type=checkbox" value="true" name="traits[path.to.my.boolean]"

• Document limitations, see #45

How To: Checkbox to boolean:

If it's not checked:

<input type=checkbox" value="true" name="traits[path.to.my.boolean]" />

If the checkbox is checked:

<input type=checkbox" value="true" name="traits[path.to.my.boolean]" checked />

If the checkbox should be toggled based on the form value (e.g. when form validation fails):

<input type=checkbox" value="true" name="traits[path.to.my.boolean]" checked={{ this.value===true }} />

How To: Array elements

• Todo: Add array element docs

Right now the JSON Schema is being re-loaded/compiled on every validation request. This is because the internal structure is written in such a way that it's not possible to create a copy of the JSON Schema Go Struct as the internal referencing get's messed up. This has to do with hooks and so on.

Describe the bug

When an user is deleted it's sessions are still valid and contain all the user information.

Expected behavior

Sessions should be deleted along with user data.

Some clients may want to choose to send JSON payload instead of form encoded. To make this work we have to obviously support JSON decoding and be able to return form errors properly - plus redirect hook should send redirect_to as a JSON response when the content-type is json!

This is an umbrella issue for all things related to single and second factor authentication, the different factors, passwordless authentication, and more.

• TOTP
• Recovery Codes
• WebAuthn
• Documentation
• UI examples

Implementation of these features by the ORY Kratos maintainers has officially started: #26 (comment)

It would be nice if we could support RISC (e.g. via Hydra)

We need an RPC hook for transforming data after login and/or sign up.

Right now, credentials will be forwarded to hooks. This should be removed.

Right now, nothing happens if a job in after returns 403. This should change, the identity should be deleted!

Describe the bug

The GitHub provider fails with a 401 error, the user is redirected to the system error page. Instead,

Reproducing the bug

Most likely configure the github provider without the email scope, then login, then update config, then login again.

We're normalizing data from OIDC providers to fit the general OpenID Connect Claim model. This is normally working as expected for OIDC certified providers, but non-oidc certified providers like GitHub need some more magic. Any type of enrichment (e.g. "how many repos does the user have?" should be done via an RPC).

We should document what the results of these providers look like. We also need to address that some providers only share a subset of resources, e.g.:

• GitHub does not provider family name, first name, etc, nor address and so on

We need administrative APIs to manage (CRUD) identities. The following use cases are relevant:

• Resetting a password to a temporary one
• Creating a new account with a temporary password

• Should email addresses be compared case-sensitively or not?
• Should domains from email addresses be compared case-sensitively or not?
• Are there potential problems with UTF-8 shinanigans? ("In modern DNS, we now have Internationalized Domain Names (IDN) which allows Unicode characters. The problem is that defining upper- and lowercase can be tricky in languages and character sets outside of ASCII. The intent of domain names is to be case-insensitive, but there may be complications with particular characters. So there is no simple YES or NO answer to your question.")

"Keep me signed in on this device" tells the browser (when using the session issuer) to set a TTL on the browser cookie (e.g. 90 days). If the browser's cookie policy allows remembering cookies in such a way, the user will have his session for that period of time and will have to log in again once the TTL expires.

As an alternative, the TTL is not sent, telling the browser to delete the cookie when closing the window (or the browser, depends on the implementation).

The difficulty is adding this to the form field during sign in and combining that with the session hook.

Another question is how this should be handled for Social Providers.

Another question is how this should be dealt with after registration.

There should be a verification API that allows to verify email addresses and phone numbers:

• email: Uses the mail configuration to send out a TOTP to that email address
• phone: Uses sms configuration to sound out a TOTP to that phone number

The request is initialized by sending the browser to /verification/phone|email. For email, a link will be sent. For SMS, a code will be sent (needs UI to show a form where the number can be entered).

Internally, the system keeps a record of the emails and phones that have been verified:

In some cases, we might want to (enforce) password reset:

• When a temporary password is set by an administrator, the password must be changed on next login
• Password update requirement (update password every n weeks) https://techcrunch.com/2019/06/02/password-expiration-is-dead-long-live-your-passwords/
• When the password is leaked, reset it

OpenID Connect errors (especially with validation) should not longer be form errors with the oidc strategy. the user can not do anything. instead, this should be treated as a misconfig.

This should only be implemented if we decide to go for a "registration completion" flow.

Right now, CSRF tokens are never reset. It is however considered best practice to reset CSRF tokens when session principals change (source).

selfservice.ErrorHandler's only source of test coverage comes from integration tests of oidc and password strategies. Instead, it should be tested on its own.

We want to broadcast events in an asynchronous fashion. For example:

Here, we would send three events, depending on the sign in state. The payloads would be different depending on the event type and would need to be documented somewhere.

This feature allows to, for example, synchronize users from hive with a thrid-party service (e.g. mailchimp).

Broadcasting is asynchronous and fire-and-forget. Hive will not wait for a result.

Broadcasting should be compatible with different message buses:

-� v0.0.1 release

• HTTP (default): Easiest to implement on the client-side
• Later release
  • STAN
  • AMQP

/cc @zepatrik

Right now, we provide a way to normalize data from e.g. GitHub using JSON Schema. Unfortunately, this can not cover all of the use cases, including:

• Adding required user profile info such as date of birth
• Asking for consent regarding Terms of Service and marketing emails

Other solutions offload this to the UI and e.g. grey out the button "sign up with ..." when the consent box is not ticked. I'm not sure how well that works with "sign in with ..." when no account exists. This is obviously not a great system because the validation should be done server side so that it stays consistent across UI implementations.

One possibility would be to have a "profile completion" page or handler or whatever that can deal with this. Maybe this is a hook?

We need to be able to send object stubs in form payloads for nested keys to properly work:

<input type="hidden" name="traits[theobjectpath]" value="__object__" />

• Implementation
• Documentation

Right now, ErrorHandler only supports form-based requests. In the future, JSON should be supported as well. See the // TODO item.

The password strategy lowercases the identifiers. It is therefore not possible to have case-sensitive usernames. This limitation must be documented.