Im working on an web application using the MEAN Framework, within that app I want to give the users the ability to upload files.
Now heres the main thing:
All users uploaded files should be uploaded to a SINGLE dropbox account (my account)
They will only upload files of with the max size of 20MB (I've already built the functionality to check the file size before upload)
What I've done:
Ive gone to a Dropbox developers and I have setup my app. And now I have access to my appKey, appSecret and also a Access Token
My questions:
Is it possible for me to connect a single dropbox account (my
account) to my app and give users in my app access to upload/download files from the dropbox but by using my apps interface?
As I already have the access token would I or every user in my app still need to go through
the OAUTH process?
Can I just send my Access Token with each request to Dropbox api every
time a user uploads a file through a specific form on my app?
If you can provide an example or a link that would be very helpful.
UPDATE:
I generated my token using the following button on the dropbox developers console:
Assumption: it is supposed the user of your apps are "legit" and that they won't do anything of your dropbox files that should concern you.
Yes, it is. You can configure your app to be the consumer of your dropbox; of course, your app will also have to make sure the users of the app are legit (check them with user/password login and so on) --note: consequences can be that any unauthorised person able to use your app can delete permanently all your files (or do anything as bad as possible according to the privileges)
The access token is part of OAuth, so I am not sure what you mean when you say "process". I will interprete your question as "how do I refresh my token?". Simply, before every call to dropbox API by your app, you check the expiration of your access token: if it is still valid you just perform the call, otherwise you request a new token. You do not need a Refresh token in this case: the OAuth mechanism (or 'grant flow' as per OAuth jargon, or 'process' to use your word) you are using is called "client credentials grant flow"
See above 2)
Some links for you: Here some overview of the grant flows.
Here a schema of that grant flow (note: MS uses another component called "ActiveDirectory" to grant permission; in your case, both "Azure AD" and "Resource API" are just "the dropbox server")
Related
I'm trying to migrate my PHP based system to AWS but the biggest thing I'm struggling with is user management/authentication side of things. I've made API Gateways and Lambda functions to get data from my RDS instance and I can use API key or ID token for authentication to protect the data they generate. What I'm really struggling with is the Cognito side of things. In my head, the system would work as follows?
User goes to my website and clicks the login button.
User is redirected to the hosted cognito UI and logs in.
The user is redirected to the chosen page and the id token is displayed in the URL
I use JavaScript to store the ID token in local storage (not sure this is the right way)
I can then pull the ID token out and use it in SDK to run and authenticate my APIs
In PHP I would check the session existed before loading the page to prevent users who aren't logged in accessing my system if the session didn't exist they would be redirected to the login page. How do I do this with Cognito/JWT, do I need to verify the JWT with a Lambda function at the top of every HTML page for my site? I basically want to only allow users who are signed in via Cognito user pool to have access to all the HTML, js, CSS files of my system, except the home page.
It sounds like you have most of the cognito stuff worked out.
If you are calling the api gateway from the web client, you are most likely passing that jwt token in the header and those api calls will fail before the user logs in.
If you are using a client side framework (React, Vue, etc), then you probably have access to a router that renders various UI components. This works analgously to what you do on the server in php, and it's pretty easy to lock down certain routes or the rendering of certain components based on a user being logged in. Doing it without a framework will probably require a significant amount of effort.
You can also stand up a php server, validate the jwt token and do what you normally do for authenticated users.
Or you could take the hyper-modern, serverless approach. You could host your html/css in an S3 bucket and put a Cloudfront distribution in front of that. You could write some Lambda#Edge functions to enforce permissions on the content in the S3 bucket.
Likely, if you are creating an api based javascript application you won't need to protect your markup/css.
I need to authenticate users in browser (not mobile app) using AWS Cognito with username/pass, not FB/google IdProviders.
There are a lot of docs but they seem to be separate blocks which either incomplete, do not fit the requirements or do not fit each others :(
I created Cognito User Pool, then Identity pool and tied the userPool to the idPool, then I stuck. Do not know which library to use and how to use it.
The closest I find are:
https://aws.amazon.com/sdk-for-browser/ but my experience is not enough to convert their FB samples to not-using FB
https://github.com/aws/aws-amplify but using this lib I'll have to study React/Angular from the very beginning (I'm not a front-end developer, sorry) and I have no clue how to convert their npm-based samples to front-end javascript (npm is for NodeJS thus back-end, isn't it?).
All I need is plain html form with username/pass, send the request to Cognito and a way to check during the next page load whether the password was correct. If it matters I will use AWS Lambda as back-end for processing future tasks.
How can I do it? Is there a tutorial/doc for my case?
Thank you.
You can use AWS Cognito UserPools Hosted UI for your use case. The simplest form of authentication is using the Implicit Grant.
For more information about setting up Hosted UI refer Add an App to Enable the Hosted Web UI.. This will create a UserPool where users can register them self (If you plan to restrict this, you will need to either add users using the AWS Web Console, Cognito UserPools or using their SDK)
The steps are as follows.
Set up Cognito Hosted UI and register your application domain. This will create the login/registration pages for you where each of this will have a unique URL. What you have to do is, if the user is not authenticated (Let's discuss how to detect it later), you need to redirect the user to the Login page.
In the Login URL, you also need to specify the redirect back URL to the application so that after a successful login, Cognito will redirect back the user to the application providing the token in a query string.
You can then access the id_token from inside the application and use it for querying the backend.
Since the id_token is a JWT token you can verify it at your Backend using the public key available at the Cognito token endpoint.
To implement the JWT verification, you can also refer Cognito JWT Token validator NodeJS module.
Note: If you need to keep the user's logged in for a longer time period (Than 1 hr), you might need to use the Code Grant flow which will return a Refresh Token, which could be used to retrieve new id_tokens programmatically.
I have created a web app which is making use of OneDrive API (https://learn.microsoft.com/en-us/onedrive/developer/rest-api/) to perform actions such as create/update/rename/delete of documents etc. I am authorizing requests with OAuth 2.0 (client side - that means every access token is valid for ~1h and then silently I am getting a new token) and then perform previous actions using that token.
I have a new requirement for the authorized user to share his/her documents for writing/updating them (I found out that API has option for inserting permissions (https://learn.microsoft.com/en-us/onedrive/developer/rest-api/api/driveitem_invite).
Is it possible for a non-authenticated user to be able to write/update documents (programmatically - via OneDrive API or some other API?) that have been created from the authenticated user that shared these? (something that is similar to Microsoft Word online when a user is sharing his document and offline/ guest users are able to edit it?
Thanks.
Some Update:
First of all documentation for REST API/ endpoints is chaotic. (https://github.com/OneDrive/onedrive-api-docs/issues/839)
I found out that I can get shared document via these endpoints:
GET: https://api.onedrive.com/v1.0/shares/encodedUrl/driveItem
And update shared document only if I have an access token
PUT: https://api.onedrive.com/v1.0/shares/encodedUrl/driveItem/content?access_token=accessToken
where encodedUrl can be obtained as : https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/shares_get
(check example on C# with sharing url )
So, I am still wondering how possible is to update a document without any authentication but just a share url.
I'm new to webdev so forgive me if this is an obvious one, but I can't wrap my head around a solution.
I'm currently hosting a static website on AWS S3. The login page is available for public access, but all other pages are only available to a specific IAM role that an authorized user will assume. Once a user enters their login credentials they will receive temporary AWS credentials that grant them access to restricted pages.
My question is: how do I programmatically load a restricted webpage? Normally I would do something like:
$('body').load(/path/to/index.html);
But the /path/to/index.html is only accessible to users with the IAM role. So do I need to use the S3 sdk to access that file? In my head I would need to do something like:
$('body').load(s3.getObject(/path/to/index.html));
But that wouldn't actually work.
Thanks for the help!
Do not put the page (HTML) itself as secret. Instead, put your essential data into a json file, and do a XHR to it.
Using a frontend framework with router, you can check if the user is authenticated and render a 403 if not.
The method depends on your framework, and I'm not going to describe it. You can use AWS SDK to fetch from S3 with authentication.
I have an ASP.NET MVC website deployed as Azure website (called website). That website has a section that needs authorization. I already have set up Windows Azure Active Directory (WAAD) to protect access to that section. Once that protected section has loaded, it will load a Javascript app that allows integration with the Azure Mobile Service.
I also have a separate Azure Mobile Service that I use for data storage (called mobserv). I want to access mobserv table and api endpoints from website. I am using the .NET backend for Azure Mobile Services.
Of course, I need to protect those mobserv endpoints using [AuthorizeLevel].
Tutorials show how to do this when I want to authenticate as Application (using [AuthorizeLevel(AuthorizationLevel.Application)]) - just add a reference to the proper Javascript Client (MobileServices.web-1.2.5.js), provide mobserv app id and token. CORS is set up to allow interaction. So far, so good.
But now, I want to protect certain endpoints using [AuthorizeLevel(AuthorizationLevel.User)]. So now, the request has to be authorized as User. Since the website already has been protected by WAAD, I do not want the client to perform a new sign in for the javascript client - I want to reuse the current WAAD authentication headers to have a Single Sign On Experience, so that mobserv will recognize the user.
I have not found any hints on how to do this. Tutorials only show application level auth against mobserv or using explicit login dialogs.
Does anybody have a clue how to do this?
Following up on vibronet's post, Mobile Services does support HTTP POST of an access token, but the access token must specify the audience as your mobile service. So a token issued for your website will not work on its own. You will need to transform it through one of the AAD flows.
So in AAD, you need you have two web application registrations, one for your web site and one for the mobile service. On the mobile service registration, you would need to define permissions that can be exposed to the other resource. The first section of the Mobile Services + ADAL tutorial ("Register your mobile service with the Azure Active Directory") walks you through this. Then, instead of registering a native client app which accesses that permission, you would go to your web site registration and configure the access there.
Once you have an AAD token for your website, you can leverage this permission to get a token for the mobile service. This can best be accomplished using an on-behalf-of flow in the Active Directory Authentication Library (JS or .NET, depending on where you want to do things). The AAD team has a nice sample on how to do this, and mobile services also has a tutorial which might be helpful, although it does mobile service access to SharePoint Online as opposed to web site access to a mobile service)
Then you can send the token to your mobile service using the "client flow" method, as described in "How to: Authenticate Users" for the HTML/JS SDK. For AAD, the call will look something like:
client.login(
"aad",
{"access_token": "<TOKEN-FROM-AAD>"})
.done(function(results){
alert("You are now logged in as: " + results.userId);
},
function(error){
alert("Error: " + err);
});
The user will not see any new UI, but they will be logged in, and subsequent calls from the SDK will be authenticated.
It might also be easier to do this from your MVC backend. I believe you can get the access token from the ClaimsIdentity, and then you can just use the Mobile Services .NET client SDK to do the login action and facilitate calls from the MVC site to your mobile service:
JObject payload = new JObject();
payload["access_token"] = "<TOKEN-FROM-AAD>";
MobileServiceUser user = await App.MobileService.LoginAsync(MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, payload);
token reuse 'as is' cannot be achieved given that the tokens you get for website are scoped to your app and should be rejected if forwarded to any other resource. From the AAD perspective there are various flows that would allow you to trade in your original token for a new token meant to be used with a web API - all without requiring any new action from the user. However your scenario includes some Mobile Services specific moving parts, hence I am not sure how that would apply here. I am flagging this post for the Mobile Services guys, hopefully they'll be able to chime in.