-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[WIP] Work so far on the new
auth package (#3894)
* Building out password auth, reset password link and magic link auth functionality * Type Fixes Co-authored-by: Jed Watson <[email protected]>
- Loading branch information
Showing
23 changed files
with
1,225 additions
and
283 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,79 @@ | ||
| # Auth Hooks Spec'ing | ||
|
|
||
| See: | ||
|
|
||
| - The current [hooks API ref](https://www.keystonejs.com/api/hooks#authentication-hooks) | ||
| - The current [hooks guide](https://www.keystonejs.com/guides/hooks) | ||
| - The [PR that added auth hooks](https://github.com/keystonejs/keystone/pull/2039) (I thought there'd be more relevant discussion in here but there isn't really) | ||
|
|
||
| Currently: | ||
|
|
||
| ```js | ||
| keystone.createAuthStrategy({ | ||
| type: PasswordAuthStrategy, | ||
| list: 'User', | ||
| hooks: { | ||
| resolveAuthInput: async (...) => {...}, | ||
| validateAuthInput: async (...) => {...}, | ||
| beforeAuth: async (...) => {...}, | ||
| afterAuth: async (...) => {...}, | ||
|
|
||
| beforeUnauth: async (...) => {...}, | ||
| afterUnauth: async (...) => {...}, | ||
| }, | ||
| }); | ||
| ``` | ||
|
|
||
| ## New Operations | ||
|
|
||
| We now have **more potential auth-related operations**: | ||
|
|
||
| - `authenticate` (existing) | ||
| - `unauthenticate` (existing) | ||
| - `createInitialItem` | ||
| - `sendPasswordResetLink` | ||
| - `redeemPasswordResetLink` | ||
| - `sendMagicAuthLink` | ||
| - `redeemMagicAuthLink` | ||
|
|
||
| (See [existing operations](https://www.keystonejs.com/guides/hooks#operation).) | ||
|
|
||
| ## Opinions | ||
|
|
||
| - We don't need hooks for the `createInitialItem` operation, it's once off | ||
| - Or.. is this how we collect metrics from the demo projects? | ||
| - We should maintain the separation between "resolve" (can modify `resolvedData`) AND "validate" (can add validation errors) for auth hooks | ||
| - We should _reuse_ the existing `resolveAuthInput` and `validateAuthInput` functions for the new auth operations (as we do with update/create) | ||
|
|
||
| ## Usage | ||
|
|
||
| So usage becomes something like...? | ||
|
|
||
| ```js | ||
| keystone.createAuthStrategy({ | ||
| type: PasswordAuthStrategy, | ||
| list: 'User', | ||
| hooks: { | ||
| resolveAuthInput: async (...) => {...}, | ||
| validateAuthInput: async (...) => {...}, | ||
|
|
||
| beforeAuth: async (...) => {...}, | ||
| afterAuth: async (...) => {...}, | ||
|
|
||
| beforeUnauth: async (...) => {...}, | ||
| afterUnauth: async (...) => {...}, | ||
|
|
||
| beforeSendPasswordResetLink: async (...) => {...}, | ||
| afterSendPasswordResetLink: async (...) => {...}, | ||
|
|
||
| beforeRedeemPasswordResetLink: async (...) => {...}, | ||
| afterRedeemPasswordResetLink: async (...) => {...}, | ||
|
|
||
| beforeSendMagicAuthLink: async (...) => {...}, | ||
| afterSendMagicAuthLink: async (...) => {...}, | ||
|
|
||
| beforeRedeemMagicAuthLink: async (...) => {...}, | ||
| afterRedeemMagicAuthLink: async (...) => {...}, | ||
| }, | ||
| }); | ||
| ``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| ## Identity Protection | ||
|
|
||
| TODO: Edit | ||
|
|
||
| If we're trying to maintain the privacy of accounts (hopefully, yes) make some effort to prevent timing attacks | ||
| Note, we're not attempting to protect the hashing comparisson itself from timing attacks, just _the existance of an item_ | ||
| We can't assume the work factor so can't include a pre-generated hash to compare but generating a new hash will create a similar delay | ||
| Changes to the work factor, latency loading the item(s) and many other factors will still be detectable by a dedicated attacker | ||
| This is far from perfect (but better than nothing) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.