IAM users can assume a role with the AWS STS (Secure Token Service) "AssumeRole" API--this returns an independent set of expiring credentials for the role that you can use to make AWS API requires in the context of the role. Using roles, you can create specialized security contexts that may be more limited (or even more permissive) than what an IAM user can do directly. Groups on the other hand simply aggregate policies onto an IAM user, resulting in a single final set of policies for the user. Any agent with the IAM user's credentials can do anything the user can do.

In general, IAM users should correspond to real individual human beings, with varying responsibilities and accountability. They should never share their IAM user credentials or install their credentials on a headless machine/instance. Groups can be used to conveniently assign policy to individual IAM users based on their job requirements. Such policies might include the ability to create new roles or launch instances with specific roles. Roles should be used whenever code (i.e., an agent) needs access to resources, and that code is running on a box not directly authenticated by an individual human that controls the box. Roles can also be used by humans (using AssumeRole) when they want to execute actions in a security context different from their default IAM policy. A common example is in an organization with multiple AWS accounts. Policy can be set up to allow an IAM user in one account to assume a role within another AWS account even though that user does not have an independent IAM user identity within the second account.

Roles can also be used in cases of delegation--e.g., if you have a website that needs access to resources on behalf of of the IAM user logged into the website. It is possible for the user to create temporary, limited role credentials and pass them to the website, allowing the website to work on behalf of the user, without the unsafe practice of the user handing over full IAM user credentials to the website.

as @billowy-army-68599 suggested, a lot of single signon solutions (I'm only personal familiar with OneLogin) forego the use of IAM users entirely. instead, you log into your single-signon provider and they give you some temporary role credentials that you can use to access AWS resources--or they pass temporary role credentials along to websites you access (including the AWS console), and the website uses those role credentials to access AWS services on your behalf. The role credentials are temporary and need to be refreshed. This is important to note, and one of the main pain-points of this model, because it means that you can't just launch a long-running process on your desktop and go home to sleep. At some point the temporary credentials will expire and you will have to re-authenticate with your SSO provider. This problem may have been alleviated since last I looked at it.

Very simple to grok.

Lots of assume-role configuration, and that's what the reusable code simplifies.