AWS app registration

AWS' IAM approach is to leverage IAM Policies which dictate what actions to which resources can be performed. Policies can be attached to Roles, Users, and Groups. Roles, Users, and Groups (to a lesser extent) define who is able to do something in an AWS Account (based on the attached or associated policies). Users are AWS IAM user constructs which when the API functionality is enabled provide long term credentials. Groups offer a logical organization of users (e.g. Developers, Admins, etc.) which can help manage the user of IAM Users. Roles provide a human (if done through federated access) and system/service/programmatic access to perform actions.

IAM Users are great for folks who are just starting out in AWS or for companies which do not have their own Identity Provider (e.g. AzureAD, Ping, Auth0, etc) which provides authentication of a human. If a company has an Identity Provide, IdP, it is recommended that they use federated access (also called "assuming a role") to provide ephemeral, short term, credentials which decreases the likelihood of credential compromise.

If an application has the ability to assume a role in AWS, then it can perform any action defined by the policy (or policies) attached to it. There are several ways this can happen. if your application is under your development control, you can build in the ability for it assume a role and store the credentials for use in the calls it makes. If the application cannot assume a role, and you're running the application on an Amazon EC2 instance, you can create an EC2 instance profile (which is an IAM Role/Policy for EC2 instances) which allows anything running on that instance to be able to perform the allowed actions. the necessary credentials are available via the Amazon Metadata Service (referred to as IMDS). If your application requires credentials to be provided to it as a configuration of the application, IAM Users can be leveraged, however this is not considered an AWS Security best practice and additional guardrails should be in place to ensure rotation and credential safe guarding are in place.

Hey,

I totally get where you're coming from. Registering a third-party app in your AWS account and managing its permissions is crucial, just like in Azure app registration. I've been down this road before, and I'd love to share my experience.

Creating an IAM user is indeed a common approach, but let me suggest an alternative that might suit your needs better. Have you considered using AWS Identity and Access Management (IAM) roles for your third-party app? Roles can be assumed by the app temporarily and provide the necessary permissions without dealing with long-lived credentials.

Here's what you can do: Set up an IAM role with the specific permissions your app requires. Then, when your app needs access, it assumes this role and gets temporary credentials. This way, you avoid the hassle of managing credentials directly.

For your use case, setting up read-only permissions through IAM roles should work great. This not only streamlines security but also helps manage permissions more effectively. Feel free to reach out if you need a step-by-step guide on setting this up.