[discuss] multi-step-authentication #777
Conversation
Codecov Report
@@ Coverage Diff @@
## master #777 +/- ##
==========================================
+ Coverage 95.15% 95.32% +0.17%
==========================================
Files 80 84 +4
Lines 1774 1841 +67
Branches 348 362 +14
==========================================
+ Hits 1688 1755 +67
Misses 78 78
Partials 8 8
Continue to review full report at Codecov.
|
2 similar comments
Codecov Report
@@ Coverage Diff @@
## master #777 +/- ##
==========================================
+ Coverage 95.15% 95.32% +0.17%
==========================================
Files 80 84 +4
Lines 1774 1841 +67
Branches 348 362 +14
==========================================
+ Hits 1688 1755 +67
Misses 78 78
Partials 8 8
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #777 +/- ##
==========================================
+ Coverage 95.15% 95.32% +0.17%
==========================================
Files 80 84 +4
Lines 1774 1841 +67
Branches 348 362 +14
==========================================
+ Hits 1688 1755 +67
Misses 78 78
Partials 8 8
Continue to review full report at Codecov.
|
| this.db = store; | ||
| } | ||
|
|
||
| public async authenticateStep({ index, serviceId, ...params }: StepParams): Promise<StepResult> { |
There was a problem hiding this comment.
@ozsay Not sure I understand how this works. Could you write a small flow summary in a comment?
Who calls authenticateStep?
There was a problem hiding this comment.
currently, it's very much abstract due to changes required for us in graphql-api.
But the idea is that the client will call it.
let's say we want to make a two-factor authentication with username-password and code received from SMS.
so the flow is like this (considering the changes here #776):
- client will call
authenticateStep({index: 0, username: 'abc', password: '123'})and will receive:{ nextStep: 1, serviceId: '1234' } - client will call
prepareAuthenticationfrom the code service to send an SMS with a code. - after he got the SMS he can authenticate the next step:
authenticateStep({index: 1, code: '4455', serviceId: '1234'})and will receive the loginToken:{serviceId: '1234', token: '...'} - then he can perform the regular
loginWithService({ serviceName: 'multi-step-authentication', params: { serviceId: '1234', token: '...' } }).
There was a problem hiding this comment.
Ah okay, so this way we the client is actually oblivious to how many authentication steps there are? is there something in the response that indicates to the client that he should activate SMS rather then something like an authenticator app?
There was a problem hiding this comment.
Currently, the client should be aware of the authentication steps since I can't predict here the flow of the authentication (can involve SMS sending, EMAIL...)
| return hash.digest('hex'); | ||
| } | ||
|
|
||
| export function createToken(): { token: string; hash: string } { |
There was a problem hiding this comment.
@ozsay Is that the token we send back to the client?
|
@ozsay thanks for starting working on the multi-step authentication. I want this feature for quite some time inside accounts-js but never had time to start the implementation. I took some time to try to think about the best implementation possible. Currently we have 2fa with OTP code only for passwords but the way it's done is not flexible at all and limited to the password service. My approach was to make this multi-factor step in the core of the server package, no need to have a separate package for it. I really like the way
You can read more about it there https://auth0.com/docs/multifactor-authentication/api/challenges. Would love to have your thoughts about this :). |
|
@pradel thanks for sharing your thoughts on this PR. I guess that following what is done in do you have any technical followup of how to do it? it will require changes in User. where do you think the current MFA state (which challenges are remaining to resolve) should be stored (locally/db)? |
|
@ozsay do you want to join the slack channel? Might be easier to discuss the implementation :) |
|
sure why not :) |
|
invited |
|
closing it for the better method in #796 |
we have a 2 step login scenario that is not supported currently by accounts:
only after these 2 steps a user is logged in.
This Authentication strategy supports this (and more) scenario.
The Authenticator accepts 2 or more other Authentication services which are being authenticated one after another. finally, after all authentication steps are successful, a token is created to perform the actual login.
@davidyaha FYI