iam-identity-center-team: a request and approval loop that removes admin access on its own

TEAM exists because admin permissions never get revoked

The problem TEAM addresses is not authentication, it is the persistence of privilege. The README describes an open source solution that integrates with AWS IAM Identity Center and lets you manage and monitor time-bound temporary access to a multi-account AWS environment at scale. Users request access to an AWS account only when they need it and only for a specific period; once that period elapses, the temporary access is removed automatically. That last clause is the whole point. Standing administrative access across dozens of accounts accumulates because nobody wants to be the person who breaks someone's production job, so the fix has to be structural rather than procedural. The intended users are platform and security engineers in large AWS estates, and the reference material for the background is the AWS Security Blog post on temporary temporary access management with IAM Identity Center.

The expiry rule is a GraphQL TTL transformer, not a scheduled job

The dependency list in `package.json` tells you how the time bound part is implemented. Alongside `@aws-amplify/api` and `@aws-amplify/graphql-transformer-core` sits `graphql-ttl-transformer` at version 2.0.1, which is the piece that gives records an automatic expiry. The repository root has an `amplify` directory and a `.graphqlconfig.yml` file, which is the Amplify CLI convention for a GraphQL backend with a schema and resolvers, and `customHttp.yml` at the top level for custom HTTP integration. In other words, an approval or a permission grant is stored as a data record with a time to live, and the expiry is enforced by the data layer rather than by a cron job that has to remember to clean up. The directory layout also separates concerns in a recognisable way: `src` for the application code, `deployment` for infrastructure, `docs` for the documentation site, `public` for static assets, and `parameters.js` for deployment parameters.

The front end is a React app on react-scripts with AWS UI components

The UI layer is a conventional Create React App setup, and the root `package.json` shows the exact commands:

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },

The `start` script runs the development server, `build` produces a production bundle, and `eject` is the escape hatch that exposes the build configuration, which is a decision most teams make deliberately and irreversibly. The component stack combines `@aws-amplify/ui-react` with `@awsui/components-react` and `@awsui/collection-hooks`, so the screens follow the AWS console design language rather than a bespoke one, with `antd` at 4.18.0 also present for layout and form work. `react` and `react-dom` sit at 17.0.2, `react-router-dom` at 5.2.0, and `react-scripts` at 5.0.1, which places this on the older Create React App generation rather than the newer tooling. Styling goes through `sass`, dates through `moment`, and the browser targets in `browserslist` are a conservative set for production and the latest three browsers for development.

The README is a pointer to hosted docs, not an installation guide

There is no install command in this repository's README, and that is a deliberate choice about where the documentation lives. The Getting Started section sends you to the documentation pages published at aws-samples.github.io/iam-identity-center-team, and the quick links list a deployment page, a solution architecture and workflows page, and a user guides and walkthrough page, alongside the blog post, a ReInforce conference talk on YouTube, and a feedback form on pulse.aws. Practical consequence for anyone evaluating the sample: the deployment instructions, the request and approval workflow, and the configuration steps live outside the repository, so you will be reading hosted pages and the `deployment` directory together rather than one self-contained README. The repository does carry a `changelog.md`, which is the place to look for what changed between versions when you are planning an upgrade.

MIT-0 for the code, AWS Content terms for everything else

The licence story has two layers and it is worth reading both. The README states that this library is licensed under the MIT-0 License, with the LICENSE file at the root, and the repository also carries a `LICENSE-THIRD-PARTY` file for the dependencies that bring their own terms. The disclaimer is broader: the sample code, libraries, command line tools, proofs of concept, templates and related technology are provided as AWS Content under the AWS Customer Agreement or the relevant written agreement, and you are responsible for testing, securing and optimising it for production use based on your own quality control practices. The same paragraph warns that deploying can incur AWS charges for chargeable resources such as running Amazon EC2 instances or using Amazon S3 storage. The root `package.json` separately declares its own license field as ISC, which is a leftover from the private application package rather than the licence of the repository, and is worth ignoring when you assess the terms.

A community Terraform provider, not just a CDK sample

The README points to a community-supported Terraform provider designed for awsteam, published as `awsteam-contrib/awsteam` in the Terraform registry. That is the part of the ecosystem that changes the adoption calculus. An AWS sample that ships only infrastructure as code in one framework forces you to translate it if your estate uses another, whereas a community provider means other engineers have already done that work and the configuration model is a set of resources and inputs you can read in the registry. It also means the provider is maintained separately from the application, so its version and its compatibility with TEAM releases move on a different schedule. The repository itself is JavaScript, with `package-lock.json` present, and the most recent release listed is v1.5.2 on 2026-09-23 after v1.5.1 on 2026-09-14 and 1.5.0 on 2026-06-26, with the last push on 2026-10-17. Patch level churn in the 1.5 series is what you should expect to absorb if you follow upstream closely.

What TEAM does not decide for you

TEAM manages the request, the approval, and the removal of temporary access. It does not decide which permissions a role should carry, and it does not replace the permission sets you define in IAM Identity Center. Nothing in the README describes how approval routing works across teams, whether request justification is captured, or how access to TEAM itself is federated and authorised, and those are exactly the questions a multi-account rollout raises. There is also no statement about audit export, about how the approval records are retained once expired, or about a rollback if the expiry path misbehaves. Treat those as design work rather than configuration. The second limit is the usual one for AWS samples: the disclaimer pushes responsibility for hardening and testing onto you, so a production rollout of this pattern means someone on your side owns the code path that actually revokes the permissions.

Editorial conclusion

TEAM is worth adopting when your organisation has many AWS accounts, uses IAM Identity Center as the identity source, and currently hands out standing administrator permissions that nobody dares to revoke. Treat it as a reference implementation rather than a product, since the README is a pointer to hosted documentation rather than a self-contained guide, and because the licence is MIT-0 for the code while the repository content is offered under the AWS Customer Agreement. Before you build on it, read the deployment documentation, confirm your identity source and account layout match what the deployment expects, and check whether the community Terraform provider for awsteam covers the resources you need, since that provider is where most of the operational work will land.

Frequently asked questions

Official sources

1. aws-samples/iam-identity-center-team on GitHub
2. License: MIT-0
3. Project website
4. README
5. Releases