Reputation: 443
Following this article from Auth0 Redirect Users from rules, we have the following scenario in our app:
if answered properly, the authentication mechanism resumes using the mentioned url:
domain/continue?state=STATE_GENERATED
We built a sample app, working well with one issue. The Auth0 generated 'state' can be seen by users; whether in redirects or in browser's network tabs.
So we tried the following:
login -> redirect to challenge question (state appended to url) -> we did not proceed but copied the state and launched the resume url in the browser:
https://DOMAIN.auth0.com/continue?state=THE_ORIGINAL_STATE
From within the same browser and it did a redirect to our app with a token. Users could mitigate challenge questions like that.
What is a best practice/recommended way to protect the 'state' in similar flows where Multi factor authentication is done using rules and redirect from rules?
Upvotes: 2
Views: 854
Reputation: 8932
The state
is used to prevent CSFR in the authentication, it is not something that you can use to ensure a user has competed some action on your "challenge question" page. You should simply pass the state through.
What you need to do is use a shared secret to generate a token that can be passed from the challenge question page to the rule in order for it to be validated. Basically what you can do is after the user answers the question correctly, you generate a JWT token using a secret that both the challenge page server and the rule know. The JWT token can be anything, for example it could contain something like { challenge_success: true }
.
After you generate the token you redirect back to:
https://DOMAIN.auth0.com/continue?state=THE_ORIGINAL_STATE&token=GENERATED_JWT
Then in the rule you read and verify the token
and check that the claim is as you expect.
You can see a full example of how this works here: https://auth0.com/docs/rules/current/redirect#how-to-securely-process-results
Upvotes: 2