You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to request support for ECDSA-based signatures of OpenID Connect (OIDC) tokens in the configure-aws-credentials GitHub Action. AWS STS recently announced support for ECDSA signatures, allowing users to choose between RSA and ECDSA keys for signing OIDC JWTs.
This enhancement would improve security and flexibility for users who want to leverage ECDSA's strong security with smaller key sizes compared to RSA. It would also allow users to adopt this feature without any changes to their existing AWS IAM configurations.
Proposed Solution
No response
Other Information
No response
Acknowledgements
I may be able to implement this feature request
This feature might incur a breaking change
The text was updated successfully, but these errors were encountered:
Does GitHub support ECDSA-signed JWTs? https://token.actions.githubusercontent.com/.well-known/openid-configuration shows that the supported algorithm is RS256 only. As far as I can tell neither the @actions/core toolkit nor GitHub support ECDSA keys yet. Presently this action only supports getting a token from GitHub's OIDC provider.
Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
Describe the feature
I would like to request support for ECDSA-based signatures of OpenID Connect (OIDC) tokens in the
configure-aws-credentials
GitHub Action. AWS STS recently announced support for ECDSA signatures, allowing users to choose between RSA and ECDSA keys for signing OIDC JWTs.For more details, please refer to the AWS announcement.
Use Case
This enhancement would improve security and flexibility for users who want to leverage ECDSA's strong security with smaller key sizes compared to RSA. It would also allow users to adopt this feature without any changes to their existing AWS IAM configurations.
Proposed Solution
No response
Other Information
No response
Acknowledgements
The text was updated successfully, but these errors were encountered: