Extra excited about this now. sso:GetRoleCredentials takes account and role name parameters (weird that it's not a role ARN but whatever). This looks to me like the client is in control of what IAM principal the user will become. This is a good thing! ⏬1/9
A great enabling capability for an org is creating single page apps w/ serverless backends, and now with these APIs in JS those apps can use SSO. One of the difficulties with these apps is that there may be many copies of a given app, for dev or just in many different accts 2/9
You should be able to stand up a copy of an app, go to its front page, and log in with SSO. But most SSO flows assume well-known URLs that you give to the SSO system. But with these AWS SSO APIs/Device Flow, that's no longer a problem. 3/9
An instance of the app registers as a client, with some auto-generated client name (the CLI does this too, "botocore"+timestamp). It doesn't need a well-known destination because it's polling for the token with its client name. OK, on to IAM: 4/9
An app is going to have some set of IAM roles it has defined for access to its backend. But a user will have access to many roles. So how does the user get the right role for what they are doing? 5/9
With the current sts:ASsumeRoleWithSAML flow, there's a big role and account selection page, and the user has to know which is relevant to the work they are doing, which isn't obvious if you're just starting from a web page you've visited. 6/9
So now, the client gets to tell SSO which role to assume in GetRoleCredentials. The auth flow the user sees is only about authentication, not role selection. If there are multiple roles to choose from, the client gets to prompt the user to chose, within that app's design. 7/9
Obviously the user has to have permissions to assume the role, but that's managed outside this auth flow. If there's multiple roles, I don't see a clear way for the app to know which to list based on permissions, but that's probably ok? 8/9
I guess the next step is to get support for this SSO auth in Amplify, so the creation of these apps can be that much easier. The ability to easily create management consoles for your cloud systems, and to get web devs empowered to create internal apps is huge. cc @undef_obj 9/9
An #awswishlist is for a new API method sso:ListRolesForToken, so a client with a token can narrow the options to present to a user. It would be ok if the API took a list of roles and returned which ones the token has access to (rather than enumerating all possible roles)
