I have using docusign node module for using embedded signing flow. Things have been working fine but suddenly we have started seeing errors such as access token limit exceeded.
Here is the error
Description: Maximum number of access tokens exceeded.
at /Users/amitagwl/Projects/Personal/support.birdeye.com/node_modules/docusign-node/components/auth.js:105:17
Questions:
In quick look up I found that production accounts have 10 as token limit. Why is that ? If I have exceeded the limit, does it mean I can't use my account any more ?
Can I reuse existing token ? How do I see my previously created token ?
Each application is allowed 10 tokens per authenticated user. In other words your app can connect to a user's account only 10 times. The tokens can (and should) be reused. Typical apps will require only one token for each user - or one token for each account of Send-On-Behalf-Of is used.
In general you should authenticate once, get the token, store that token, and use it for future access to that user's account. The user may revoke that token at any time so your app should prompt for authentication if necessary.
I got the answer. Tokens can be revoked under "connected apps". (Classic experience only).
Related
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.
I was going through Oauth2 docs and thought it was kind of permissive security wise, so i tried to implement JWT tokens with a special scheme like in the picture for a mobile app communicating with a web API.
Notes : i didnt like Oauth2 refresh tokens idea as they might get stolen and allow parallel usage (by legit and malicious users) unless you implement theft detection by rotating them (refreshing refresh token upon each request) in this case why use them at all ?
How the auth flow works :
A user logs in with credentials gets a jwt of 20 minutes lifetime.
Upon expiry the jwt gets refreshed by hitting the db checking if it's blacklisted (relogin) and if not check if it was used to generate a new token.
If it was never used to refresh it is accepted and used to issue a low grade access token.
If the token was used before, or had different client+device+user than its parent offer a credential check (password or lockscreen code)
If passed, this check issues a new first grade token that blacklists all its parents and children on the db, its like a new first user login.
If lockscreen fails the user is presented with login screen.
The questions are :
What are possible security holes ? (I found two use cases : stolen valid access token lasts 20 minutes same issue as Oauth tokens. No gain no loss here. And stolen sleeping token : user not logged in for say 7 days, token gets stolen and used until user logs in again or token chain revoqued after 3months of persistance - our policy - and this theft has small chances since token has to be intercepted at the last request the user makes on the app , slimmer than stealing an Oauth2 refresh token )
What are user experience problems an attaker can cause on the app while on this scheme ?
OAuth2 refresh tokens are not meant to be used by mobile clients. Using refresh tokens requires client credentials, which cannot be stored securely in a mobile application.
Refresh tokens are used from confidentials clients (server side web applications for example). They are often renewed when used (server sends back new access and new refresh token). In contrast to access tokens, the refresh token is only sent to the authorization server, not the resource (API) server.
Regarding your auth flow. Step 2 is the weak link IMO. You allow the client to use an expired token to generate a new access token. So if I find your phone and access the device, it will allow me to get a fresh access token and impersonate you.
You could force the client to refresh the token every say 15 min., but then you have to define what happens if the app gets closed or the device is turned off? Is it okay to re-authenticate the user again?
I'm building an ASP.NET Web API service which connects to Azure Graph API to get a list of users.
So my scenario is to create an MVC page on this service => let Azure AD admin login and grant permission => cache access_token and use this to call API.
However, I acknowledged that access_token will be expired after 1 hour. Even if it's renewed by using refresh_token, admin will actually have to manually sign in on this service again after 90 days.
I read on some example which use AcquireTokenSilentAsync method from ADAL library. But not sure if it would be useless after 90 days ?
Yes, currently the Access Token will expire within the hour. The Refresh Token will be valid for 14 days, and can be used to obtain a new Access Token and a new Refresh Token. You can carry on doing this for up to 90 days. (Note that these are the current values, they may change in the future.) AcquireTokenSilent and AcquireTokenSilentAsync will attempt to use existing state (i.e. Refresh Tokens, if available) to obtain a new Access Token, or throw an exception if this is not possible.
That said, I suspect that is probably not the best approach for your scenario. It sounds like you are in one of two situations:
You are building a middleware service (an API) that will be used by a different app which is accessed by authenticated users. If this is the case, you can use on-behalf-of flow, where (a) your middleware service is registered as a web app/API in Azure AD, (b) the user-facing client app and obtains an Access Token (for the current user) to the middleware API, and (c) the middleware API uses that Access Token to obtain a new Access Token to the Azure AD Graph API, on behalf of the original user.
Sample: active-directory-dotnet-webapi-onbehalfof
You just need to enable unattended access to the Graph API. If the middleware service is a highly-trusted environment, you can use app-only authentication (also known as "headless", or "daemon" apps) to obtain an Access Token without any user context. (This is the Client Credentials Grant OAuth 2.0 flow.)
Sample: active-directory-dotnet-daemon-certificate-credential
Sample: active-directory-dotnet-daemon
Yes, by default refresh tokens expire in 14 days (access tokens in an hour) but with some configuration I believe it can go until 90 days. This is for security reasons and a good practice. Nothing wrong with it. However, this will only work if you implement your own cache because by default ADAL cache uses memory and upon restart it will lose those tokens.
https://github.com/Azure-Samples/active-directory-dotnet-webapp-webapi-openidconnect
DocuSign RestAPI Guide says "Up to 10 access_tokens are supported per userId."
I have been using demo.docusign.net account to create access tokens. More than 10 access tokens are generated by this account using the same Integrator key and username.
There are some posts related to OAuth access token limit
DocuSign OAuth Token error - “An entry with the same key already exists” when access token limit crosses 10.
I verified lists of tokens generated at Preferences -> connected Apps in my DocuSign web console. They are already been crossed 50 and no maximum limit exception been thrown by DocuSign endpoint.
So What is OAuth2 access token limit? Is it only applicable to Production environment?
The user OAuth token limit has been increased in the DocuSign Demo (Developer) environment to 200. The OAuth token limit in production, though, is still the expected 10. Once you try to create more than 10 tokens in production it will error out.
I am posting this here, as Docusign has requested all docusign api questions be placed on StackOverflow:
REFERENCE
I have been working on a Docusign application that uses their OAuth flow. In order to test this, I have been using my free account (www.docusign.com) to get access tokens from the application I created on my developer account (demo.docusign.net).
The integrator key I am using is live.
In the process of my testing, I have obtained an access token 10 times using the free account. I did not keep track of those tokens as it states that they can be revoked in the web console. Docusign Reference
However, there is no such section in the www.docusign.com account. All it shows is 5 other accounts that I can connect to.
I now have lost all 10 of those tokens, and the response from the service tells me that I reached the maximum number of access tokens.
Now here's the interesting part, if I use my developer account credentials to authenticate to my application, I can see the access tokens that are active, with the option to revoke.
I know that there is a revoke token endpoint, but you need to know the token in order to use it.
How can I revoke these 10 tokens as I no longer know what they are (due to testing), and there is no interface to revoke them on www.docusign.com? Essentially, this account is now locked out of my application.
I cannot add screenshots to this post as I do not have high enough reputation