I am trying to implement a way to obtain a short lived access token from dropbox, then upload multiple file to a folder. and finally revoke the token.
This can obtain access token can be .net code or in javascript. But what I am seeing from the dropbox documentation is having a redirect url which I don't want to redirect anything.
also I do not need to ask the end user to allow anything, what I need is to get a temp access token and upload some files.
This scenario is doable in Amazon S3 by generating a short lived policy for file upload.
Thanks for any help.
Related
I am trying to integrate the Google sign in sdk into my site.
I have already added the GSI button to my site and on clicking it, google sends the IDtoken containing the user info to my oauth endpoint.
Using this token, I can now create a new user account.
So far so good.But I am not sure what I am to do from here.
Should I put this IDtoken into a http_only and secure, cookie so that all authz server requests will contain the userid?
I am seeing lots of cookie and local storage based data has been been added to my sites jar. Am I supposed to use them in any way?
What do I need to do after the token expires after 1 hr? Do I need to have my users login yet again? I did not get any refresh token along with the idtoken. Do I even need to handle the refresh token or is the gsi sdk supposed to take care of all that for me?
Another part which is not clear is what do I get from using the Google sign in button/sdk vs the general Oauth-openid flow.
Situation: I run a Django app in the web, where logged-in users can also download .pdf files (non-public, with specific restrictions, depending on user rights). The most convenient way to do so (e.g. in S3) is to use a time-restricted, pre-signed URL because they open immediately in the browser, plus the app server does not have to handle additional traffic.
Problem: Backblaze B2 oviously does not offer an explicit method for creating presigned URLs to download non-public files directly in the browser.
Generating the api URL and the authorization token, and fetching the file from the object store happens at the app server level and the process is not exposed to the "ordinary" user.
But in the end, the API operation "b2_download_file_by_name" just uses a GET request, which means I can add the authorization token to the request's URL using "?Authorization=123xyz........". This way I get a presigned URL that works perfectly fine in the browser to allow access to a specific non-public file for a limited time. (Please note: B2 downloads can be restricted to files with specific prefixes [like s3 pseudo-folders], but if the specified "prefix" is long enough, I can make the auth token specific for one file.)
Question: As I wrote above, usually the authorization token is not exposed to the user. Now, if I make the URL visible, does this imply a security risk? In other words, could a user that posesses one or many tokens, extract the general access key from the token, or is the token encrypted well enough to avoid this?
According to the documentation for the b2_download_file_by_name call you can use the download authorization in a URL in the way you describe.
An authorization token can be provided in the URL query string instead of being passed in the HTTP header. An account authorization token obtained from b2_authorize_account will allow access to all files in a private bucket. A download authorization token obtained from b2_get_download_authorization will allow access to files whose names begin with the filename prefix used to generate the download authorization token.
However it seems that the expiry time set in the b2_get_download_authorization call is being ignored so the resulting URL never expires which is not secure of course. I have a support ticket in with B2 about this so hoping for a solution.
We have an Instagram client id and client secret, and already have gone through the documentation of generating access tokens which requires redirect url.
Note that we also have disabled the implicit OAuth flow.
Now we already have generated the access token using URL below (for authenticated user, it returns the access token appended in the response URL)
https://api.instagram.com/oauth/authorize/?client_id={client_Id}&redirect_uri={redirect_url}&response_type=token&scope=public_content
Can this token be stored in the database / configuration files and re-used for any new Instagram API requests? e.g.
https://api.instagram.com/v1/users/{user_id}/media/recent/?access_token={reusable_access_token}
Based on the official documentation, we understand that the access token can become invalid at any point of time, we would like to know if there are any specific scenarios which leads to invalidation of the access token?
What would be the best way to generate token once and use it for each API request? We definitely do not want users to enter credentials manually to generate tokens.
Unfortunately at that point it's not possible:/ Instagram doesn't provide refreshing access token in the background.
User needs to login with their credentials, so you can obtain new access token. Some kind of workaround (not nice, but it's working) is to watch for error type OAuthAccessTokenException and notify the user via e-mail about such fact. He will have to login once more, so you can get fresh and working access token.
Also, please keep in mind that access tokens has a pretty long life span. It doesn't expire after a day or two, unless Instagram API has some issues (like just now OAuth - unable to exchange code to access token for some users).
Otherwise it works really well.
However it would be super nice if Instagram could add to their API renewal option in the background for access tokens for users that autorised your app, but their token expired:)
My question seems similar to OneDrive for Business REST API - PUT,POST - 401 Unauthorized
However, instead of uploading, I am trying to download a file. What's strange is that I do get the file contents and data, but the response code is a 401.
Any idea why? Of course, I would like to be receiving a 200 and not have to ignore the response code.
As far as my Azure AD app permissions go, I am allowing pretty much all read permissions under delegated permissions for Office 365. I have listed all the permissions I selected here, for your reference.
Delegated Permissions I am allowing for Office 365:
Read managed metadata
Run search queries as a user
Read items in all site collections
Read user files
Delegated Permissions I am allowing for Windows Azure Active Directory:
Enable sign-on and read users' profiles
I have not enabled anything under Application Permissions.
There is a bug in our implementation - if you provide an Authorization: header with a bearer token on the download URL (which is pre-authenticate) the service rejects the authentication (hence the 401) but since the URL is pre-authenticated, the contents of the file are still sent.
We're working on a fix. You can track the status by watching this issue on our GitHub repo: https://github.com/OneDrive/onedrive-api-docs/issues/189
What is the proper way of delegating file access authentication from S3 to our authentiation service?
For example: web site's user(he have our session id in headers) sending request to S3 to get file by url. S3 sends request to our authentication service asking if user with such headers can access that file, and if our auth service allow getting that file it will be downloaded.
There are a lot of information about presigned requests but absolutely nothing about s3 quering with "hidden" authentication.
If a file has been made public on S3, then of course anyone can download it, using a direct link to the file.
If the file is not public, then there needs to be some type of authentication. There are really only two ways a file from S3 can be obtained if it is not public, one is via a pre-signed url, and the other is to be an Amazon user who has access to S3. Obviously this is how it works when you yourself want to access an object on S3, you must provide your access key and a signature in the header of the GET request. You can grant other users access to S3 via Amazon IAM, which is more like the 'hidden' authentication you mentioned. Via the IAM route, there are different ways of providing access including Federated Users. Visit this link to learn more:
http://docs.aws.amazon.com/AmazonS3/latest/dev/MakingAuthenticatedRequests.html
If you are simply trying to provide a authenticated user access to a file, the best and easiest way to do that would be to create a pre-signed url with an expiration time. The expiration time can be something short, like 10 minutes or even 1 minute, to prevent the user from passing the link to others.