05-28-2018 12:57 PM
Hi There,
I’m attempting to build an authentication integration through the API. Most everything is working as expected, except for the auth_status endpoint when working through an ‘asynchronous’ request (only tested using the ‘push’ factor)
The initial request returns the ‘txid’ attribute as documented.
However, when I then try to check on the status of that authentication after a few seconds using the auth_status endpoint, sending ‘txid’ as a parameter, the API call results are not returned until the authentication request has completed (‘allow’ or ‘deny’), or the https connection times out, similar to a ‘non’-asynchronous request.
This isn’t what I had anticipated, thinking instead the results of the query would be returned ‘immediately’, indicating whether the request has completed, or is still ‘waiting’. Have I made an incorrect assumption, or perhaps done something wrong?
Thanks,
Sean.
05-29-2018 06:38 AM
Could you provide an example of your application’s POST to /auth/v2/auth
?
05-29-2018 09:41 AM
Sure thing!
I’m pulling these values out of the example Java client with some added ‘println’ lines…
To /auth/v2/auth endpoint is posted:
async=1&device=$deviceId&factor=push&username=$uid
where $deviceId is the Duo ID for the device
and where $uid is the Duo username associated with ‘my’ (test) account.
The endpoint returns (in my latested test):
{“txid”: “$transactionId”}
where $transactionId is a GUID that I assume is a ‘transaction identifier’
I then send a ‘GET’ request to:
/auth/v2/auth_status
with the query parameters:
txid=$transactionId
… and the call to that endpoint holds the HTTPs connection open until the authentication is complete, or the HTTPs connection times out.
Thanks,
Sean.
02-07-2019 05:09 PM
I’m curious as to where this topic got to. I have the same question as Sean, in that the call to auth_status responds the first time but time’s out on subsequent calls.
The API documentation is ambiguous in that the description for auth endpoint async param states:
“If you enable async, then your application will be able to retrieve real-time status updates from the authentication process, rather than receiving no information until the process is complete.”
However, the description for the auth_status endpoint states:
" The /auth_status
endpoint “long-polls” for the next status update from the authentication process for a given transaction. That is to say, if no status update is available at the time the request is sent, it will wait until there is an update before returning a response."
The behaviour as described by the async param is what I would expect for an async process.
02-08-2019 10:46 AM
Hi There,
I never received any followup on the subject. We’ve been living with the “wait until response or timeout” for now as we had to move on. I did not notice the “long-poll” statement on the endpoint documentation, so the behaviour was extra confusing to me at the time…
At least I know I’m not alone now!
Thanks,
Sean.
04-02-2019 04:42 AM
I’m curious about this one too.
I don’t see the point of having /auth with async while /auth_status is not asynchronous. I’d expect the API call /auth_status to return immediately everytime even if the status is the same.
I’m doing the same thing as Sean. I implemented a short timeout.
11-12-2019 06:23 PM
Same problem here. The /auth endpoint allows us to pass async=1 so that we can then call /auth_status asynchronously, but then /auth_status only allows one asynchronous call and then we are back to waiting for a response. This makes it so we can’t ever build and application against your API where the user has the option of canceling the request, thus the user still has to wait for the auth to time out before they can do anything else.
Please fix this!
11-15-2021 11:52 AM
Hi Everyone - I’m new here but trying to integrate Duo Auth into my Dash application (built on Flask / Python). I was wondering whether there is a way to periodically poll whether someone is authenticated or not? My application runs on a subdomain of another one and doesn’t need to actually authenticate the user, but I do need to ensure that the user is authenticated prior to (and while) using the application. I would ideally not like to tie up a thread every time that someone opens up the application with the long polling and would vastly prefer some sort of interval status check instead. The interval part I can take care of in Dash but I was wondering whether anyone found a workaround to the long polling solution that requesting /auth_status gives us? Thanks!
11-16-2021 06:29 AM
No, the API isn’t designed for Duo to maintain a persistent authenticated state service-side for another app to keep checking. When the Duo request to auth
completes and returns the response, sync or async, it’s done.
You could store the Duo auth status in the application that actually authenticates the user for the other application that doesn’t authenticate the user directly to check, or try storing the Duo API trusted_device_token
value on that first auth for subsequent use by the application for whatever duration you wish the session to last.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide