Most of our clients are having no issues whatever with our system. We have an integrator key and our users do an initial link up for integration using OAuth on REST. We store the access/refresh tokens. Works fine. At some point down the road some clients seem to randomly hit this.
We are using OAuth with the REST API and always get a new access token using the client's refresh token if their access token is within 30 minutes of expiring.
Q: If a client's access token expires before they make a subsequent call (some of our clients might go 30 days before having another document to sign) to get a new one with the refresh token can that cause this?
Q: Can the refresh token expire such that they would get this?
Q: Short of the client manually revoking access to the integration on their DocuSign account, what else could cause this?
If you get this error then you need to restart the oauth flow again.
A refresh token does expire at some point. When it expires is a policy issue. To achieve the longest possible refresh token lifetime, request scope extended in addition to signature.
Re:
Q: If a client's access token expires before they make a subsequent call (some of our clients might go 30 days before having another document to sign) to get a new one with the refresh token can that cause this?
A: I'm surprised that you're getting this specific error, but I haven't tried this for awhile. I'd think the error would have a different name.
Q: Can the refresh token expire such that they would get this?
A: Same answer as above re the specific error name. In any case, a refresh token can definitely expire. Requesting the extended scope should minimize this, but at some point an account may set a policy that will also expire extended scope refresh tokens. Bottom line: your app needs to be prepared to ask the user to go through the entire OAuth Auth Code Grant flow again.
Q: Short of the client manually revoking access to the integration on their DocuSign account, what else could cause this?
A: Using the wrong base url for the user. Also, at some point there will be organizational controls that can force policies upon the org's accounts. (Organizations own and control accounts.)
Related
Can we use the same access token to request another app resource or validate Token. What happens after 3599 seconds to an access_token? can we still use it?
How many times we can use the same refresh token? (Is there any way to restrict to one time if possible)
How to check if the existing access_token and refresh_token were valid ones or not?
Please help.
PAVANSAI C
Can we use the same access token to request another app resource or validate Token. What happens after 3599 seconds to an access_token?
can we still use it?
When you acquire an access token, it is only meant to be used against certain resources (you specify them when you request a token). You can't use that token for any other resources. Generally an access token is valid for an hour (3600 seconds) but that's configurable at Azure AD level. Once this time period expires, you can't use that token anymore as using it will throw an error.
How many times we can use the same refresh token? (Is there any way to restrict to one time if possible)
Similar to access token, there's also an absolute expiration for refresh token (it is usually 14 days). When you use a refresh token to get a new access token, you also get a new refresh token. You should be using the new refresh token instead of an old one.
How to check if the existing access_token and refresh_token were valid ones or not?
A successful response to an access token request will include the number of seconds the returned access token is valid for (expires_in), as well as the time at which the access token will expire (expires_on). Use these to keep track of whether the access token is still valid or not.
Note: You should consider using client libraries such as MSAL, which will do this automatically. Your code only needs to ask for a new token token, and the library will take care of figuring out if the last token received is still valid, or if a new one is needed.
Another possibly way to test it is try to use the access_token/refresh_token in an operation and catch the exception. Try to parse the exception to figure out what's wrong with the token. For example, if an access token has expired and you use it you will get an error telling you exactly that. That would be an indication for you to get a new access token using the refresh token. (This approach relies on the resource provider (i.e. the API) to return a message that clearly indicates that the token is expired, which is not always the case.)
In order to access resources in Azure AD web applications we retrieve an authorization code using the following workflow:
https://learn.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code
Now my questions is, does this retrieved code also have a specific lifetime (like tokens have) or will it never expire? I guess it won't expire but I need to be sure about that.
Yes, the authorization code has a lifetime of 10 minutes I think.
You use it to get the tokens you need and then throw it away.
You'll get refresh tokens so you can use them to get more tokens later.
ADAL.NET for example handles the token refresh for you, assuming you properly implement a token cache.
Reference: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-id-and-access-tokens (scroll all the way down) (it's for the v2.0 endpoint, but codes are similarly short-lived in v1)
Authorization codes (work or school accounts)
10 minutes
Authorization codes are purposely short-lived, and should be immediately redeemed for access tokens and refresh tokens when the tokens are received.
One of the steps to authorize our application to access our DocuSign account requires a human to navigate to the oauth service (https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=...) then login to the account, and grant it access.
I've seen some references throughout the developer portal about this being something that will need done multiple times, and I've also seen it written on the same site that it only needs to be done once (the site is actually fraught with contradicting information).
Does anyone know if this step will need to be done more than once? It makes sense to me that it should NOT.
Much appreciated!
Chris
You are referring to https://docs.docusign.com/esign/guide/authentication/oa2_auth_code.html and it is a correct place for documentation for DocuSign. Now with above flow, you get two types of tokens i.e AccessToken and Refresh Token. If Access Token expires then you can use refresh token to get new set of access and refresh token and it does not need any consent from the user or a human action, it can be done using DocuSign OAUTH API from backend. But if the response to the refresh operation is an error, or if the new access token’s expires_in value is less than your threshold, you will need to repeat the initial authentication flow. So you need to do proper exception/error handling before taking user back to the consent/OAuth login page.
I am using passport-facebook to obtain an access token. According to here
https://developers.facebook.com/docs/marketing-apis#access-token
under "Get Access Token", I should be getting a 60 day long-lived token. This is the case if the scope is only ads_read. However, when I add additional scopes of manage_pages and read_insights, there is no expiration when I check via the Graph API.
This seems to be a bit contradictory to me. My theory is based on the getting an API key with ads_read permission manually from the below tool.
https://developers.facebook.com/apps//marketing-api/tools/
Using this tool and debugging it via the Graph API, I see one difference in that it the manually generated access token has the "Page" row under it, indicating that it is a page access token (to my own pages). Since it is a PAT, it will never expire, as expected.
My passport-facebook generated access token has the ads_read, manage_pages, read_insights permission as well and the expiration says "Never Expires". However, it does not have the Page row on it. Does that mean I can still use it forever to query the ads insights API?
This is my attempt at obtaining a non-expiring Marketing API access token.
Yes, if the expiration row says Never expires, you can continue to use the token for querying ads insights.
On a side note, is you generate system user access tokens, they also never expire. You can read more about it here - https://developers.facebook.com/docs/marketing-api/businessmanager/systemuser/v2.8
there seems to be some conflicting advice on how to get an access token from a refresh token:
This SO answer says passportjs doesn't get involved with refreshing the access token and it should be done via cron job:
Refresh token in Passport.js
This SO answer says "No need for any cron jobs...when the user requests data from the API using an access token that has expired, this should trigger your framework to fail, renew, then retry."
OAuth 2.0 - When should an access token be renewed with refresh token?
What's the simplest way to ensure we're always giving Google a valid access token? Right now, we're just storing the refresh token in the database and never using it, which forces users through the "allow / deny permissions" flow every time their access token expires.
There are a few approaches. One is to just detect when the access token fails (with 401 I believe) and then refresh it and re-use it. However, most of the APIs that yield access tokens also tell you their expiry time, so you can just remember that and, when you’re about to use, if it’s less than say 10 min before expiry time, refresh then. If all else fails you could use the tokeninfo endpoint when you get a new access token, to find out its lifetime.