github.com/Kansuler/gcp-jwt-go/v2
Package gcpjwt has Google Cloud Platform (Cloud KMS, IAM API, & AppEngine App Identity API) jwt-go implementations. Should work across virtually all environments, on or off of Google's Cloud Platform. It is highly recommended that you override the default algorithm implementations that you want to leverage a GCP service for in dgrijalva/jwt-go. You otherwise will have to manually pick the verification method for your JWTs and they will place non-standard headers in the rendered JWT (with the exception of signJwt from the IAM API which overwrites the header with its own). You should only need to override the algorithm(s) you plan to use. It is also incorrect to override overlapping, algorithms such as `gcpjwt.SigningMethodKMSRS256.Override()` and `gcpjwt.SigningMethodIAMJWT.Override()` Example: As long as a you override a default algorithm implementation as shown above, using the dgrijalva/jwt-go is mostly unchanged. Token creation is more/less done the same way as in the dgrijalva/jwt-go package. The key that you need to provide is always going to be a context.Context, usuaully with a configuration object loaded in: Example: Finally, the steps to validate a token should be straight forward. This library provides you with helper jwt.Keyfunc implementations to do the heavy lifting around getting the public certificates for verification: Example:
Readme
Google Cloud Platform (Cloud KMS, IAM API, & AppEngine App Identity API) jwt-go implementations
Google Cloud KMS now supports signatures and support has been added to gcp-jwt-go!
IAMConfig.OAuth2HTTPClient is deprecrated and unused - Use IAMConfig.IAMClient instead.IAMConfig.ProjectID is deprecrated and unused. The API will infer the project from the service account name.To continue using the older version, please import as follows: import "gopkg.in/Kansuler/gcp-jwt-go.v1"
gcp-jwt-go has basic implementations of using Google Cloud KMS, Google IAM API (both signJwt and signBlob), and the App Identity API from AppEngine Standard on Google Cloud Platform to sign JWT tokens using the golang-jwt/jwt package. Should work across virtually all environments, on or off of Google's Cloud Platform.
Please read the documentation at https://godoc.org/github.com/Kansuler/gcp-jwt-go
There are many tradeoffs which the various signing mechanism available from Google's Cloud Platform. Below you will find a chart of performance for the different algorithms and APIs. Here are some overall takeaways:
note: all latency numbers are ordered as (50th %ile, 95th %ile, 99th %ile). Tests were run on a F1 AppEngine Standard instance in the us-central region. All Cloud KMS keys are set to global.
| Signer | Signature Length | Sign Latency | Samples |
|---|---|---|---|
| AppEngine | 342 | 9.14 ms, 17.56 ms, 79.15 ms | 100 |
| IAMBlob | 342 | 198.37 ms, 217.42 ms, 244.91 ms | 100 |
| IAMJWT | 342 | 109.03 ms, 208.46 ms, 212.65 ms | 100 |
| KMSES256 | 86 | 31.57 ms, 44.09 ms, 44.54 ms | 50 |
| KMSES384 | 128 | 34.67 ms, 51.16 ms, 59.48 ms | 50 |
| KMSPS256 (2048) | 342 | 38.20 ms, 57.75 ms, 70.47 ms | 50 |
| KMSPS256 (3072) | 512 | 42.77 ms, 58.24 ms, 62.86 ms | 50 |
| KMSPS256 (4096) | 683 | 52.02 ms, 64.70 ms, 92.15 ms | 50 |
| KMSRS256 (2048) | 342 | 37.94 ms, 61.94 ms, 77.33 ms | 50 |
| KMSRS256 (3072) | 512 | 39.85 ms, 50.52 ms, 56.17 ms | 50 |
| KMSRS256 (4096) | 683 | 50.19 ms, 68.48 ms, 86.02 ms | 50 |
| Verifier | Cache | Verify Latency | Samples |
|---|---|---|---|
| AppEngineVerify | false | 6.42 ms, 9.33 ms, 10.86 ms | 50 |
| AppEngineVerify | true | 0.87 ms, 1.05 ms, 25.03 ms | 50 |
| IAMVerify | false | 12.52 ms, 21.45 ms, 30.63 ms | 100 |
| IAMVerify | true | 0.86 ms, 1.01 ms, 53.19 ms | 100 |
| KMSVerify (2048-PS256) | always | 0.88 ms, 1.01 ms, 32.15 ms | 50 |
| KMSVerify (2048-RS256) | always | 0.93 ms, 1.11 ms, 19.96 ms | 50 |
| KMSVerify (3072-PS256) | always | 1.53 ms, 1.71 ms, 43.35 ms | 50 |
| KMSVerify (3072-RS256) | always | 1.61 ms, 2.11 ms, 42.39 ms | 50 |
| KMSVerify (4096-PS256) | always | 2.94 ms, 66.88 ms, 71.60 ms | 50 |
| KMSVerify (4096-RS256) | always | 2.70 ms, 55.25 ms, 72.34 ms | 50 |
| KMSVerify (ES256) | always | 0.15 ms, 0.20 ms, 0.29 ms | 50 |
| KMSVerify (ES384) | always | 181.21 ms, 193.25 ms, 195.08 ms | 50 |
Where cache=false is where we get the most value from these numbers as it shows the time to fetch/parse public certificates, the other cases are just the time to use a cached certificate to validate the JWT.
roles/iam.serviceAccountTokenCreator role to any user/group/serviceaccount you want to be able to sign on behalf of the new service account (resource: projects/-/serviceAccounts/<serviceaccount>). For example, create an api-signer service account, do NOT furnish any keys for it, grant your AppEngine/GCE/etc. default service account the proper role for that serviceAccount, and use the api-signer@... service account address in your configuration.
For example, to setup to use an AppEngine service account to sign on behalf of a service account api-signer (be sure to export PROJECT_ID=your-project-id before executing the below):# First, create the api-signer service account
gcloud beta iam service-accounts create api-signer --description="Tokens must be signed by this service account in order to authenticate to the API" --display-name="API Signer" --project=$PROJECT_ID
# Grant the AppEngine service account proper permissions to sign tokens on behalf of the service account we just created
gcloud beta iam service-accounts add-iam-policy-binding api-signer@$PROJECT_ID.iam.gserviceaccount.com --member=serviceAccount:$PROJECT_ID@appspot.gserviceaccount.com --role=roles/iam.serviceAccountTokenCreator --project=$PROJECT_ID
Understand this process by reading this article.
FAQs
Package gcpjwt has Google Cloud Platform (Cloud KMS, IAM API, & AppEngine App Identity API) jwt-go implementations. Should work across virtually all environments, on or off of Google's Cloud Platform. It is highly recommended that you override the default algorithm implementations that you want to leverage a GCP service for in dgrijalva/jwt-go. You otherwise will have to manually pick the verification method for your JWTs and they will place non-standard headers in the rendered JWT (with the exception of signJwt from the IAM API which overwrites the header with its own). You should only need to override the algorithm(s) you plan to use. It is also incorrect to override overlapping, algorithms such as `gcpjwt.SigningMethodKMSRS256.Override()` and `gcpjwt.SigningMethodIAMJWT.Override()` Example: As long as a you override a default algorithm implementation as shown above, using the dgrijalva/jwt-go is mostly unchanged. Token creation is more/less done the same way as in the dgrijalva/jwt-go package. The key that you need to provide is always going to be a context.Context, usuaully with a configuration object loaded in: Example: Finally, the steps to validate a token should be straight forward. This library provides you with helper jwt.Keyfunc implementations to do the heavy lifting around getting the public certificates for verification: Example:
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
A hospital in Mobile, Alabama, agreed to a settlement in a landmark ransomware death lawsuit, but is now reportedly reconsidering the agreement and refusing to pay.
Security News
A new report explores how advancements in LLMs are enhancing cyber threats, including polymorphic malware, personalized spearphishing, and the risk of hijacking customer service bots.
Security News
ESLint has approved an RFC that adds support for TypeScript configuration files, which is aimed at improving the developer experience and recognizing changes in the evolving JavaScript ecosystem.