I am using amazon S3 to provide IAP content.
Is there a "Safe" way to store the secretAccessKey inside my app so hackers can't use it to get the files?
The best way to do this is not to give out normal secret access keys at all.
First create an IAM user that has access to only what is needed, so that even if someone does get their hands on the credentials they can only access what you want them too (e.g. get files from a specific S3 bucket, but not modify them)
When the iOS app needs to access the S3 files it connects to a web server you control. That web server users STS to generate a set of credentials that will expire after the desired amount of time. These look like normal aws credentials (access key, secret, session id) but will eventually expire.
Amazon provide some reference implementations of these token vending machines and has an article discussing the setup in more detail.
Did you look for appropriate method using Keychain framework? Keychain Services Tasks for iOS
Related
Please forgive my ignorance on this topic. I've been a developer for a long time, but there's a huge gap in my knowledge and experience when it comes to authentication & authorization protocols and proper handling of tokens.
We've got a whole homegrown suite that consists of:
4 web apps (2 in Ruby/Rails, 1 in Elixir/Phoenix, 1 single-page React)
1 image server (serverless app written as an AWS Lambda / API Gateway)
1 custom data API (also serverless Lambda / API Gateway)
We also have an Amazon Cognito User Pool connected to our backend identity provider to authenticate users and generate tokens.
All but one of these allow some form of anonymous access; the other is only available to logged in users. If a user is logged in, they all need to access the user's profile info from the ID token, preferably without initiating another auth flow. Our backend apps may also need to make use of the access token, but obviously we wouldn't be handing that out to to the SPA or public API consumers.
My first thought is to store the tokens in a key/value store on the backend, and have a short-lived, encrypted JWT containing a unique session ID set on the shared domain that all of the backend apps have access to, with the key stored in a config secret. By decoding the session ID, they can get what they need from the data store. The API would also refresh when necessary.
I also know that API Gateway can use a Cognito user pool as an authorizer, but I'm unclear how I would make that work while integrating it with the rest of our apps and requirements above. Sometimes requests to the API are made from the browser (in the React app, for example), and sometimes they come from the backend of one of the web apps.
The image server and API are used by our apps, but are also documented and accessible for other people to build their own applications on. But they would have to register their apps as OIDC clients to receive any profile info from logged in users.
I'd love some advice on how to make all of this work, or at least pointers toward resources that might help make it less dizzying.
We are exploring the Graph API to let users authenticate to our service via their MS account. However, to be able to encrypt user data properly, we need a 'secret' that we can use. Typically API's return an application specific key that is unique to the user/application that can be used for this purpose. However, I don't see anything that would be usable for that in GraphAPI.
Questions
Can anyone tell if getting such an application specific key is possible using the Graph API?
Otherwise, we will generate a secret ourselves, but want/need to store that securely in the user profile that we would be able to get after logging in. Any suggestion on how to do that?
Thanks!!
Regards,
Rick
This is not currently supported in Graph API. Being said that, you can file a user voice for this ask so that it could be considered for future implementations.
Try storing the secret securely in the Azure Key vault and you can retrieve it from there.
I am currently trying to use amazon s3 for uploading images from IOS app with a Rails Back-end.
I currently don't understand how security works. In their docs
http://docs.aws.amazon.com/mobile/sdkforios/developerguide/s3transfermanager.html
it's not clear to me how to upload/destroy safely objects in sync with the back-end. For instance, in order to post/destroy, I was expecting a mechanism of asking a signature to the Rails server, and only then be able to upload the image to amazon. But I can't find this kind of mechanism.
Has someone gone through this kind with aws?
If you are using your server to generate temporary credentials for the AWS Mobile SDK, we recommend the following approach:
Generate the access key, secret key, and session token on your server. You have many language options including Java, .NET, PHP, Ruby, Python, and Node.js.
Implement your credentials provider by conforming to AWSCredentialsProvider. Take a look at the implementations of AWSWebIdentityCredentialsProvider and AWSCognitoCredentialsProvider as examples. This credentials provider should:
Retrieve the access key, secret key, and session key from your server.
Persist them locally until they expire.
Return the credentials when requested.
Re-retrieve them from your server if they are expired.
Initiate the credentials refreshing process when - refresh is called.
I encourage you to take a look at Amazon Cognito Identity. With Amazon Cognito, you can create unique end user identifiers for accessing AWS cloud services by using public login providers such as Amazon, Facebook, Google, and any OpenID Connect compatible provider, or by using your own user identity system. It covers many of the custom server use cases, and it is easier to use and manage.
I've followed the instructions in this post http://mobile.awsblog.com/post/Tx371Y7CA0QJ95X/Simplifying-Token-Vending-Machine-Deployment-with-AWS-CloudFormation
And I can see that it's working somewhat, and i understand the overall concept of what TVM is and why it's needed, however I still have hard time understanding how this works in practicality. I read a post somewhere that anonymous token vending machine is designed for read-only and if I wanted to actually provide write access I need to use identity TVM.
In the demo app it makes me register my account on the cloudformation server i set up, but I don't understand how this works with say my own web app. I have a mobile app that connects to rails app where I need users to upload their profile images as well as post photo content. I already have the app running except for the integration part with the TVM (basically my aws credentials are embedded in the app which Amazon doesn't recommend)
So my question is how do i integrate an existing REST based iOS app with identity token vending machine to upload photos to S3? How can i integrate it without making users separately create an "account" for the identity token vending machine on top of registering for my app?
We recently launched Amazon Cognito, which obviates the need for the TVM in many cases, particularly in the "anonymous TVM" case. Through Cognito's unauthenticated access you can grant users of your application limited access privileges to various AWS resources. Cognito leverages existing functionality of IAM Roles and STS to deliver these credentials.
If you want to maintain the integration with your existing backend authentication solution, you will need to generate and maintain the list of identity ids for your application. You can read more about the APIs involved in our API documentation.
Your app can act as the TVM, mapping your user identities to the IAM Roles with the permissions they need. Then can use the AssumeRole calls on STS to create temporary credentials for these users. Your app then creates a S3Client object with these credentials and use it to upload the photo.
See the "Identity federation" and "Web identity federation" sections of the of IAM Roles documentation
The AWS Web Identity Federation Playground is a nice example app to see it at work.
CoudFormation will automate the creation, updates and deletion of AWS Resources, including EC2 Instances and IAM Roles, but will not be directly related to the user authentication.
My goal is to offer a service for user of my website to store their private notes.
I want that users can trust the service, therefore the data should not be accessible for my company.
Can i realize this with google-cloud-storage and oauth-2.0 authentication? I would use the Google Cloud Storage JSON API to send the notes directly from the browser into the cloud.
What would be the basic steps to implement this?
There are a couple of ways to handle this, depending on how you want to handle authentication. If you want to make sure that your application cannot access the objects and only the users can, you'll need the users to have Google accounts and authenticate your app to act as their agent using OAuth 2.
Your app could involve a piece of JavaScript that would prompt the user to authenticate with Google and grant it access to Google Cloud Storage under their name. It would then receive a token that it could use to act as them. From there, it would upload the note using that token with an ACL granting permissions only to the uploader.
The uploaded object would go into your bucket, but it would be owned by the end user. You'd have the ability to delete it, but not to read it, and your bucket would be billed for storage and access.
The downside here is that all of your users would need to have Google accounts that they could entrust to your application for short periods of time.
Here are some details on the OAuth 2 exchange: https://developers.google.com/accounts/docs/OAuth2UserAgent
Here's the JavaScript client that does a lot of the authorization heavy lifting for you:
https://code.google.com/p/google-api-javascript-client/
And an example of using that library for authorization:
https://developers.google.com/api-client-library/javascript/samples/samples#AuthorizingandMakingAuthorizedRequests
Another alternative would be for the user to upload directly to the cloud using YOUR credentials via signed URLs, but if you went down this road, you would be able to read the notes after they were uploaded.