In the Dropbox file API, one had the option to create a non-expiring access token. Dropbox has communicated that this option will be removed on 2021-09-30.
Will the non-expiring token that I already created continue to work, and for how long?
The creation of new long-lived (non-expiring) Dropbox access tokens is now considered deprecated, but we don't currently have a plan to disable existing long-lived access tokens. (If that changes, we will of course announce that ahead of time.) That being the case, you can continue using existing long-lived access token(s). Note though that after the change you won't be able to create new long-lived access tokens.
Related
I was going through the DocuSign REST API's(docusignapi), but didn't come across any API which will get me the list of Integration API keys available in the specified Account.
My requirement is to display the list of API Integration keys available if there aren't any then Create a new using the data required to generate an API Integration key.
We don't have a public/documented API to enable developers to get the list of Integration Keys at this time. Sorry about that.
There may be some miscommunication here:
We have an account for sandbox which has many Integration Keys available around >100, so we were planning to provide an interface to users where we will list down all the Integration keys which are not expired, and if there are no keys then it will create one through API, once the key is selected we will configure the Connect configuration using the API, in short we were trying to ignore manual steps to Login into the Sandbox environment, creating an API key, and creating a custom configuration.
Integration Keys (also known as client_ids) do not expire.
Integration Keys are used one per application. I don't know of a reason why
an application would need more than one IK. Why do you have > 100 IKs?
Integration Keys are used (via OAuth) to obtain access keys. If the OAuth Authorization Grant flow is used then a refresh token is also created.
Access Tokens do expire.
Creating/refreshing an Access Token depends on how you created it:
Authorization Code Grant: use the refresh token or have the user authenticate again.
Implicit Grant: the user must authenticate again.
JWT Grant: re-do the JWT Grant flow to obtain a new access token.
Added
From the comment, it sounds like the issue might be that the applications' access tokens are expiring and the desire is automatically refresh them.
That can be done for access tokens received via the authorization code grant flow by using the refresh token. This can be done as a batch process, but your applications must maintain their own record of the access tokens, the matching refresh tokens, and expiration times.
This type of information not available via any API since it would be a security hole if it were available. Your app(s) must store this information.
I am using IHttpClientFactory for sending requests and receiving HTTP responses from my Web API to an external APIs using Net Core 2.2.
The access token and the refresh tokens used to send the request to the API have been stored in the appsettings.json. When a request returns 403 or 401 errors, I get a new token dynamically and add it to the header of the request.
But How Can I update appsettings.json with the new access and refresh token in order to use it for subsequent requests.
Is It there a much better approach to store access and refresh tokens than the appsettings.json?
Since you are using IHttpClinetFactory (and assuming you are using Typed Client as well), you can create your own HttpMessageHandler which would be triggered before any request made by your Typed Client and link it with your typed client via DI like this:
services.AddHttpClient<IServiceContract, ServiceImplementation>()
.AddHttpMessageHandler<TokenHandler>();
Inside that TokenHandler you can check if the request has a token in the headers or not. If not check the cache (Memory Cache) for available tokens, then validate the lifetime of the token.
If the token is expired or there is no such a token in the cache, issue a new one and store it in the cache.
I am sure there are better ways, but that what I would do.
Note: If your application is distributed on multiple servers, then use Distributed Cache instead of the Memory Cache. You can add either easily via DI.
Update:
You can register your handler like this:
services.AddTransient<TokenHandler>();
Giving the hypothesis your client WEB API connects automatically to your external APIs (and also, ask automatically the tokens), you don't need to store tokens and refresh tokens.
Your webservice needs to keep the tokens in memory (in a singleton) and use it whenever needed.
When the external API wants a new token (e.g. after token expiratoin), you just need to ask a new one and update your singleton.
We use this way of working for several projects and it's reliable.
In general, you should store the token in database for permanent save by EF Core or any other data provider.
If you insist on saving in the appsettings.json, you need to implement the custom feature.
For a demo, check Manually trigger IOptionsMonitor<>.OnChange
I have been using JWT to authenticate the users for the HTTP endpoints in my ASP.NET Core 2.1 API project. I have configured the authentication service and everything is going on well.
while generating the token, I usually set the expiry to 24 hours. My problem is, what if the user is blocked by the admin after issuing the token. Now that the token is issued the authentication middleware will simply authenticate the request.
So, I thought I need to intercept every request to make a backend call to know whether the user is blocked or not. I can do this at every endpoint level, but it is not so efficient I think.
What are the optimal solutions for this issue, which is quite common? Are there better ways to solve it than what I thought?
When you choose to use a JWT then accept the nature of the JWT. This means that the only way to have 'real-time' information is to expire the token when the information becomes obsolete. Set the lifetime of the access token to a small window, like less than five minutes. This way you know the information is always valid and you don't have to change anything about the current handling. This is 'almost real-time', as the changes become effective within five minutes.
The advantage of a short lifetime is that this also increases the security of your website. When the token is compromised, it can only be used for a short time.
You'll have to add support for a refresh token, because you don't want the user to login every five minutes. So when the access token expires use a refresh token to request a new access token. This will only work for apps that can keep a secret. Because the refresh token is very powerful and you don't want it to fall into the wrong hands. You can use one-time only refresh tokens to limit the risks and add strategies to detect different behaviour. For more details read my answer here.
You can also choose to remove authorization claims from the JWT and move authorization to your middleware, where you can real-time check the permissions of the user. In that case the JWT only includes the user claims that identify and model the user. Claims that are not likely to change very often. As a result the access token doesn't have to be short-lived, but for security reasons I think this is still advisable.
The minimal requirement is a sub or userid claim. This is enough to identify the user and grant the user access to the website.
I think the Policy Server is a good example of a possible middleware authorization implementation. Here the middleware reads permissions from a json file and adds permissions as claims to the identity. Where policies decide what the user is allowed to do. Also implement resource-based authorization.
An alternative is to use reference tokens, as implemented by IdentityServer. IdentityServer stores the contents of the token in a data store and will only issue a unique identifier for this token back to the client. The API receiving this reference must then open a back-channel communication to IdentityServer to validate the token.
The advantage here is that you can revoke the reference token at any time, using the revocation endpoint.
I have built a Web API and now I am trying to determine the best approach to secure it.
I would like to use tokens along with credentials and thus, once the user is validated, on future requests a token can be passed with the http request. This API will always be called by one particular account and the username/password will always remain the same.
I am working with an already existing site backend, which has its own login implemented and stores user data. So I would like to stay away from creating new database tables to store user records. For that reason, I think implementing .Net Identity is maybe a overkill.
One of the options I am thinking of is grabbing the credentials from the http request and attempting the SQL connection with it. If the connection passes, then the user is legit. If it does not, it means I have to return access denied. Is this a good way of going about it? If yes, what can I use for token generation and validation?
Check out this guide which is specific for Oauth tokens with .NET:
OAuth with JSON Web Tokens In .NET
Also, make sure to follow the guideliness, because tokens must expire and be renewed after a while, for security reasons. You shoudn't use a permanent token, of course.
I have been studying the documentation for the Dropbox API but I couldn't find a way to directly access an account without going to the OAuth process. Is there a way to achieve that?
My final goal is to have a webpage with a list of files and folders from a specific Dropbox account (my own), which can be viewed and downloaded by anyone.
To access a user's Dropbox account via the API, your app will need to be authorized by the user. The Dropbox API currently requires that this authorization be done via the OAuth flow. You only need to perform this step once per user though, as you can store and reuse the access token for each user.
It sounds like you intend to use only one account though (your own), so you can just process this flow once manually yourself, and save and reuse the access token programmatically.
New answer, 9 years later, so probably new changes.
When you create an app in Dropbox, the settings page has a button to Generate Access Token. This will create a permanent token to access your own account without going through the oauth flow.