Instead of using OAuth and access tokens, AWS uses request signatures to authenticate API requests. Typically, we can let libraries do the request signing for us – but sometimes we have to do it ourselves. Continue »
By using workload identity federation, we can let applications use Azure credentials to authenticate to Google Cloud. That’s useful if we have an application that runs on Azure and needs access to Google APIs. But what if we are in the opposite situation, where we have an application on Google Cloud that needs access to Azure APIs? Continue »
When an application running on Azure needs access to Google APIs, we can use workload identity federation to let the application use its Azure credentials to authenticate to Google APIs. Unfortunately, the C# client library doesn’t support that yet, but we can fill that gap. Continue »
On Azure, we can use managed identities and AzureAD applications to authenticate service-to-service authentication. But how can we ensure that only certain managed identities can obtain access tokens for an application? Continue »
Last time, we looked at how we can use a Cloud KMS asymmetric signing key to create a self-signed X.509 certificate. But we’re not limited to self-signed certificates. We can use Cloud KMS to sign other certificate signing requests too, just like a certificate authority (CA). Continue »
After you create an asymmetric signing key in Cloud KMS, you can download the key pair’s public key. The key is provided in PEM format – that’s pretty standard and all you need in many use cases. But especially when dealing with third party services, you sometimes need an X.509 certificate instead of a plain public key. Continue »
Service accounts play a key role in Google Cloud IAM, and there are multiple ways how service accounts can authenticate. One of them is by using a service account key – but service account keys turn into a security risk if they aren’t managed carefully. Continue »
When you create a service account key, Google Cloud doesn’t let you specify an expiry date. The key stays valid until you either delete the key or the entire service account. But there’s a way to limit the validity of a service account key. Continue »
Last time, we looked at how you can use a CryptoAPI-backed key as a service account and use it to authenticate. Now let’s see how you can do the same with CNG. Continue »
Using service account keys to authenticate a service account is generally discouraged on Google Cloud, but sometimes difficult to avoid. The most common way to use service account keys is to create a new key by using the Cloud Console or gcloud, but you can also upload existing keys, including CryptoAPI-based keys. Continue »
Service accounts play a key role in Google Cloud IAM, but they are easy to get wrong. If you’re not careful, you quickly end up with over-permissioned service accounts, accounts that are used across multiple applications, and service account keys being spread all across your environment. Continue »
When you authenticate a user by using OpenID Connect and request the
email_verified, what does this claim indicate and how does Google populate it?
If your plan is to develop a tool or desktop app instead of a server-side application, the benefits of application default credentials are less obvious and reusing the user’s personal gcloud credentials instead might seem attractive. But there are some pitfalls. Continue »
gcloud manages two sets of credentials, your personal credentials and application default credentials. Having two separate credentials might seem redundant and can cause surprises the first time you use one of the Google Cloud client libraries. But the two credentials serve different purposes. Continue »
Google APIs use OAuth 2.0 for authentication and authorization. To call an API, you first have to obtain an access token for the right scope and then pass it to the respective API by using the
Authorization HTTP header.
But the trouble with access tokens is that they are short-lived, and you somehow have to deal with expiring tokens…
Once you’ve signed in on google.com, the Cloud Console, or any other Google site, your browser session remains valid for multiple days. Not being prompted to sign in over and over again is convenient and at least in typical consumer scenarios, the risk that comes along with keeping the session is limited.
Things can look different in a corporate scenario where users might have access to sensitive data. Keeping sessions alive for 14 days (which is the default) might seem a little risky and might not be in line with an enterprise’s idea of security. G Suite Business and Cloud Identity Premium therefore allow you to change the default session length to a different period such as 8 hours. This setting applies to all Google services, not only GCP.
Recently, Google introduced another way to control session lifetime by allowing you to control the session length for Cloud Console and gcloud sessions.Continue »