There is a pattern, where a user configures one credentialed entity for access to a RS, but controls neither the credentialed entity nor the RS. I might say technically the user is acting as the AS, but it isn't clear to me.
Concretely, CI/CD services such as GitHub and GitLab support runners that come with a JWT, whom this JWT should be issued to is not exactly clear. These tokens are intended to be used with third party RS such as AWS IAM to authenticate and access resources in AWS. (AWS reference <https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html> ) Currently, GitLab is prototyping support for this access and wants to know what's a good meaningful value for the AUD to be. (GitLab context <https://gitlab.com/gitlab-org/gitlab/-/issues/216259#note_708055501>) Personally, while I'm able to specify who is the client, RS, and AS, it doesn't feel exactly like it's something directly supported by any RFC, but it does seem like it should be. (AWS = RS, gitlab job = user, gitlab server = AS) Due to the nature of what's available for configuration on both sides, it's likely they want to go with altering the AUD to point itself at the git repository url where the token comes from rather than the RS which would like be the AWS account. The closing thought I have is if we suspend for one moment expectations about who is authorization by whom, it's possible to also see that AWS is the AS, and the gitlab runner is a client using the jwt-bearer credentials grant. Is there anyone that wants to weigh in on this, it's a potentially great opportunity to drive the right practice at the right time. (I'm happy to relay any outcome back to the thread or feel free to post directly on the Gitlab issue <https://gitlab.com/gitlab-org/gitlab/-/issues/216259#note_708055501>. - Warren Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
