Forum Replies Created

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter Jeremy Ward

    (@jmichaelward)

    I’ve done some more investigation into the existing behavior today to see whether I could better understand and diagnose the problem. The TL;DR is that it appears the plugin has specific Authorize and UserInfo controllers for the OpenID implementation, but no corresponding TokenController.

    In version 4.2.3 (the latest release of the paid plugin), the OpenID AuthorizeController has a method called needsIdToken which gets called when the authorize parameters are built. If the openid scope is included with the request, the controller generates the ID token and returns it in the response.

    Since there is not an OpenID implementation of the TokenController, that same check is not made when requesting a new refresh token via the /oauth/token endpoint.

    Ultimately, I’d expect /oauth/token to return an ID token if it’s specifically requested via the scope, but currently it’s not possible to retrieve it, which is causing issues with our implementation.

    Thread Starter Jeremy Ward

    (@jmichaelward)

    Hi @justingreerbbi,

    I’m responding once more in the hopes that I can get a response. Since we need to move forward with our integration, I’ve modified the plugin code directly to continue with our testing, knowing that of course we’ll lose these changes should we ever upgrade the plugin in the future. Toward that end, I’m wondering whether we could collaborate on an approach that would meet our third-party needs while also enhancing the plugin itself.

    As I mentioned before, I’m filtering wo_jwt_token to convert the iat and exp values of the access_token into UTC. Since I need the same values converted in the id_token, I’ve updated line 54 of library/WPOAuth2/OpenID/ResponseType/IdToken.php to be wrapped in the same filter.

    Would you be able to include this change in your next release so that those values can be filtered, as well, and I won’t have to worry about changing our integration when we update? Alternately, if you have different suggestions for ways to approach this issue, I’d welcome them. A better approach might be to pass a filtered timezone to each call to WordPress’s current_time so that we get the token back in the desired timezone, passing 0 as the default to avoid breaking previous integrations.

    I appreciate any attention you can give to this matter, but I understand if you’re unable to provide additional support.

    Thanks!

    • This reply was modified 4 years, 6 months ago by Jeremy Ward.
    Thread Starter Jeremy Ward

    (@jmichaelward)

    Good morning! I’m following up on this issue to see whether you have some advice/suggestions for how to approach the timezone issue with regard to expiration times in tokens. Thanks!

    Thread Starter Jeremy Ward

    (@jmichaelward)

    Hi Sylvain,

    Thank you so much for taking the time to address this issue and roll it into a new release. Our client and I really appreciate it!

    Have a wonderful week!

    Jeremy

Viewing 4 replies - 1 through 4 (of 4 total)