Duo's WebSDK now requests the authorization code as 'duo_code'
Activity
Philip Smart April 22, 2021 at 10:20 AM
Updated Duo WebSDK library and removed duo_code checks.
Philip Smart April 20, 2021 at 10:58 AM
I should add, this is not a regression from moving to 1.1.1, it was always there but I did not see it before.
Philip Smart April 20, 2021 at 10:43 AMEdited
I have updated the WebSDK client to 1.1.1. I have also removed the old hack to check for both `code` and `duo_code` as I am now able to set their client to use only `code`.
They do have a possible NPE in their auth code exchange logic. It should never happen but I reported it anyway https://github.com/duosecurity/duo_universal_java/issues/8. The Nimbus version handles this (HTTP 400) correctly.
Philip Smart March 17, 2021 at 9:23 AM
Version 1.1 and 1.1.1 have been released:
https://github.com/duosecurity/duo_universal_java/releases/tag/1.1.0
https://github.com/duosecurity/duo_universal_java/releases/tag/1.1.1
Will update the plugin post 1.0
Philip Smart March 11, 2021 at 9:53 AM
Looks like they will soon release v1.1 with a way to set this back to `code` (see issue above). It also seems to include a Builder for class instantiation - so requires a few more changes to the WebSDK Client Adaptor. Possibly too late for v1 of the Duo plugin.
Duo, as a temporary fix for some thick clients, changed the URL parameter name of the authorization code that is returned from the authorization server to `duo_code` from the OAuth2.0 standard/common `code`.
The latest version of their webSDK (1.0.3) is hardcoded to request this. If not requested e.g. like in the Nimbus client, it is returned as the expected `code`. The plugin's controller needs to accept both versions.
I've asked if there is a plan to make this optional in their WebSDK so we do not need to diverge from the standard here (https://github.com/duosecurity/duo_universal_java/issues/5).