OAuth

Q) How does actual flow of OAuth look like?

Let’s try to understand how that works with a sample scenario.

The Actors

• User: You
• Client App: “PrintMaster” (The printing service)
• Authorization Server: Google (Issues the keys)
• Resource Server: Google Photos API (Holds the data)

Step 1: The Authorization Request (Browser)

The app needs to send you to Google to ask for permission. This isn’t a background API call yet; it’s a URL your browser visits.

User Action: You click “Connect with Google” on PrintMaster. Browser Request: Redirects you to:

https://accounts.google.com/o/oauth2/v2/auth?
  response_type=code
  &client_id=printmaster-id-123
  &redirect_uri=https://printmaster.com/callback
  &scope=photos.readonly
  &state=xyz123

• response_type=code: Tells Google “Don’t give me the token yet, give me a temporary code.”
• scope=photos.readonly: “I only want to read photos, not delete them.”

Step 2: The Callback (Browser)

If you click “Allow,” Google redirects your browser back to PrintMaster’s redirect_uri with a temporary code attached to the URL.

Browser Redirect:

https://printmaster.com/callback?code=AUTH_CODE_HERE&state=xyz123

PrintMaster’s server captures this AUTH_CODE_HERE. It is not the key yet. It is a temporary ticket valid for only a few minutes.

Step 3: The Token Exchange (Back-Channel REST API)

Now PrintMaster needs to turn that code into a real Access Token (The Valet Key). This happens server-to-server (Back-Channel), so the user never sees it.

Request (Bash/Curl): PrintMaster sends a POST request to Google.

curl -X POST https://oauth2.googleapis.com/token \
     -d client_id=printmaster-id-123 \
     -d client_secret=keep_this_secret_shhh \
     -d code=AUTH_CODE_HERE \
     -d grant_type=authorization_code \
     -d redirect_uri=https://printmaster.com/callback

Response (JSON): Google verifies the code and the secret, then replies:

{
  "access_token": "ya29.a0AfH6...", 
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "1//04..."
}

• access_token: The actual Valet Key.
• refresh_token: A special key to get a new access token when the first one expires (usually after 1 hour).

Step 4: The API Call (Using the Token)

Now PrintMaster wants to download your photos. It calls the Google Photos REST API and attaches the token to the Header.

Request (Bash/Curl):

curl -X GET https://photoslibrary.googleapis.com/v1/albums \
     -H "Authorization: Bearer ya29.a0AfH6..."

Response (JSON):

{
  "albums": [
    {
      "id": "12345",
      "title": "Summer Vacation",
      "productUrl": "https://photos.google.com/..."
    }
  ]
}

In the Terraform code provided down below, there’s an OAuth scope:

resource "google_container_cluster" "main" {
  name               = "${var.cluster_name}-${var.branch}"
  location           = var.location
  initial_node_count = 3

  # Only for prod env it will be deployed, since prod won't accept not-attested images
  dynamic "binary_authorization" {
    for_each = var.branch == "prod" ? [1] : []
    content {
      evaluation_mode = "PROJECT_SINGLETON_POLICY_ENFORCE"
    }
  }

  node_config {
    service_account = local.service_account_email # Retrieving the email of the service account from locals
    disk_size_gb    = 10                          # Setting disk size to 10 GB because of the free account quota limits
    oauth_scopes = [
      # This scope is a Google Cloud OAuth scope that grants the service account full access to all Google Cloud services.
      # It’s a broad scope that allows the application or service account to perform any action across the entire Google Cloud Platform,
      # including managing resources, accessing APIs, and interacting with various services.
      "https://www.googleapis.com/auth/cloud-platform"

    ]
  }
  # Defines how long Terraform should wait for the create and update operations to complete.
  timeouts {
    create = "30m" # Allows up to 30 minutes for the cluster creation process
    update = "40m" # Allows up to 40 minutes for the cluster update process
  }
}

This scope, https://www.googleapis.com/auth/cloud-platform, is a Google Cloud OAuth scope that grants the client full access to all Google Cloud services. It’s a broad scope that allows the application or service account to perform any action across the entire Google Cloud Platform, including managing resources, accessing APIs, and interacting with various services.

• Read-only Access: An application might request a read-only scope for accessing Google Drive files, like https://www.googleapis.com/auth/drive.readonly.
• Limited API Access: An app might request only the ability to read a user’s email address and basic profile information, using scopes like email and profile.
• Cloud Platform Access: As in Terraform example provided above, a service account might need broad access to manage resources across Google Cloud, which would require a scope like https://www.googleapis.com/auth/cloud-platform.

What is the Difference Between IAM Role Assignments and OAuth Scope Access?

• IAM Roles: Control what the service account can do on Google Cloud services. For example, if we assign roles/container.admin role to the service account, it allows for the management of GKE clusters.
• OAuth Scopes: Define what level of API access the service account has when used by a GKE node or an application. Scopes are more about access to APIs rather than defining specific permissions on resources.