Why use developer ID or third party user ID for backend authentication

In the IOS SDK S3TransferManager example provided as an Amazon Web Services example, it looks like I can access AWS resources like s3 without having to go through authentication providers like Facebook or Google. So what's the purpose of having my own developer ID, or authenticating through the backend rather than mobile if I use Parse? For example, I believe Parse uses front-end authentication (on mobile) to authenticate users, not to authenticate using its cloud code service ( https://parse.com/docs/js/guide#cloud-code )

"Cloud Code is easy to use because it built on the same JavaScript 
SDK that powers thousands of apps. The only difference is that this  
code runs in the Parse Cloud rather than running on a mobile device."

      

Can't I just authenticate users with front-end parsing and when that succeeded, just copy and run this code below into the success block?

// Authenticate with Parse and if authentication succeeded execute code below
AWSCognitoCredentialsProvider *credentialsProvider = [[AWSCognitoCredentialsProvider alloc]
                                                      initWithRegionType:AWSRegionUSEast1
                                                      identityPoolId:@"identity-pool"];

AWSServiceConfiguration *configuration = [[AWSServiceConfiguration alloc] initWithRegion:AWSRegionUSEast1 credentialsProvider:credentialsProvider];

[AWSServiceManager defaultServiceManager].defaultServiceConfiguration = configuration;

      

and still have access to my aws resources. This way I don't need to use the AWSCredentialsProvider protocol, which needs an access key, secret key, and session key sent to my application from the backend. Plus, it looks like the IOS SDK manages the token session allocation by itself (automatically) on mobile, am I thinking right or am I missing something? still new to this, so sorry if i sound clueless

+3


source to share


1 answer


Cognito delegates credentials based on two different kinds of realms - non-authenticated and authenticated. The power of these user types is determined by the unauth and auth roles that are created and associated with the used identity pool. The S3 demo used unauthenticated users, so they did not require any provider. If you don't have any external need and are only thinking about using Cognito for credentials, you don't need unauthenticated users. They work independently. See the Cognito Developer Guide for more information .

Cognito supports Facebook, Twitter, Digits, Amazon, Google, OIDC providers and authenticated developer IDs to authenticate users. If you want to use Parse to authenticate users, you will need to use them as the authenticated provider.



To be clear, this does not mean that your server has to send an access key / private key ... etc. to your device. This blog post covers it in more detail, but the app is sending the login credentials to your server. This backend will validate them and get an id / token from Cognito. They will be sent back to the device, which will then be sent back to obtain the credentials to access AWS.

+2


source







All Articles