Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IUserTwoFactorTokenProvider #37

Closed
mausch opened this issue Mar 19, 2024 · 5 comments
Closed

IUserTwoFactorTokenProvider #37

mausch opened this issue Mar 19, 2024 · 5 comments

Comments

@mausch
Copy link

mausch commented Mar 19, 2024

We're currently implementing the "Traditional Prompt" and part of this is implementing IUserTwoFactorTokenProvider for Duo.

How do we migrate this to the new "universal prompt"? There seems to be no mention of this anywhere.

Many thanks.

@AaronAtDuo
Copy link
Contributor

@mausch Duo published a few guides that should be helpful in explaining the new flow, and the differences from the prior (Web SDK 2) based prompt.
https://duo.com/docs/duoweb#upgrading-from-web-sdk-2 is a good place to start. If you are familiar with Python, there is a demonstration pr (duosecurity/duo_python#57) that shows an example of migrating a python application from Web SDK 2 to Web SDK 4. Unfortunately we can't create step-by-step instructions for every language and framework.

@mausch
Copy link
Author

mausch commented Mar 19, 2024

Yep sure, thanks. I guess since this is a .NET repo that has a example app I was expecting it to use the standard .NET APIs for 2FA integration. Or if the standard APIs are not to be used with the new Universal Prompt then why?

@AaronAtDuo
Copy link
Contributor

@mausch The Duo prompt in general is not a "token" provider suitable for use with the built-in abstractions. It is a web-based flow that involves redirecting the user out of the application and back. While we do have a data object we refer to as a 'token' it is not the type of token that IUserTwoFactorTokenProvider deals with, as far as I can tell.

@mausch
Copy link
Author

mausch commented Mar 19, 2024

Thanks for the quick reply!
It seems the developer that implemented this in our code used the wrong APIs then 🙂

@mausch mausch closed this as completed Mar 19, 2024
@AaronAtDuo
Copy link
Contributor

Well, I can see how the old method (what we call "Web SDK 2") could be stretched to be considered a 'token', subject to special validation rules. But I don't think the new scheme can unfortunately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants