<!– SEO Title

Cấu Hình Google OAuth 2.0 & Cloud Auth Toàn Diện

1. Tổng Quan Giao Diện Google Auth Platform Mới

Trước đây, các nhà phát triển thường truy cập vào mục APIs & Services > OAuth consent screen để cấu hình ứng dụng. Tuy nhiên, trong các bản cập nhật gần nhất, Google Cloud Platform (GCP) đã tái cấu trúc toàn diện và gom toàn bộ quy trình nhận diện vào một trung tâm duy nhất: Google Auth Platform (với bảng điều khiển tổng quan tại https://console.cloud.google.com/auth/overview).

Mục tiêu của sự chuyển đổi này là phân tách rõ ràng giữa quản lý lưu lượng API (API Metrics, Quotas) và quản lý bảo mật định danh người dùng (Identity, Audience, Scopes & Credentials). Trung tâm điều khiển mới được chia thành các phân khu chức năng chuyên biệt:

• Overview (Tổng quan): Nơi hiển thị tóm tắt trạng thái xuất bản (Publishing Status), số lượng người dùng thử nghiệm (Test Users), tổng số ứng dụng client (OAuth Clients) và các cảnh báo tuân thủ chính sách bảo mật dữ liệu người dùng.
• Audience (Đối tượng): Cấu hình loại người dùng tiếp cận ứng dụng (Người dùng nội bộ tổ chức Google Workspace hoặc người dùng công khai bên ngoài) cùng danh sách tài khoản thử nghiệm trước khi xác thực toàn diện.
• Data Access / Scopes (Truy cập dữ liệu): Danh mục các phạm vi cấp quyền mà ứng dụng yêu cầu người dùng ủy quyền (như quyền đọc profile, đọc file Google Drive, gửi email Gmail).
• Branding (Thương hiệu ứng dụng): Hiển thị tên sản phẩm, logo doanh nghiệp, liên kết chính sách bảo mật (Privacy Policy), điều khoản dịch vụ (Terms of Service) và email liên hệ của nhà phát triển.
• Clients (Khách hàng): Nơi tạo và quản lý bộ khóa Client ID và Client Secret tương ứng với các nền tảng Web Application, Desktop Client, Android, iOS hoặc Single Page App (SPA).

2. Bản Chất Kiến Trúc Phân Quyền OAuth 2.0 & OIDC

Trước khi bắt tay vào cấu hình các nút bấm trên giao diện, kỹ sư hệ thống cần phân biệt rạch ròi giữa hai khái niệm: Authentication (Xác thực – Authn) và Authorization (Phân quyền – Authz):

Hệ thống hoạt động theo tiêu chuẩn OpenID Connect (OIDC) xây dựng trên nền tảng OAuth 2.0. Ứng dụng của bạn không bao giờ nhìn thấy hoặc lưu trữ mật khẩu tài khoản Google của người dùng. Thay vào đó, sau khi người dùng đồng ý tại màn hình OAuth Consent Screen, máy chủ ủy quyền của Google sẽ phát hành các mã thông báo (Tokens) được ký số mật mã để ứng dụng thực thi tác vụ.

3. Thiết Lập Audience & Phân Loại User Type (Internal vs External)

Bước đầu tiên khi truy cập bảng điều khiển là cấu hình thẻ Audience. Google phân loại đối tượng sử dụng thành hai nhóm với các yêu cầu bảo mật hoàn toàn khác nhau:

Lưu ý chí mạng: Rất nhiều lập trình viên gặp lỗi token tự động mất hiệu lực sau đúng 7 ngày khiến ứng dụng bị ngắt kết nối. Nguyên nhân bắt nguồn từ việc ứng dụng đang ở chế độ External nhưng trạng thái xuất bản vẫn là Testing. Để token có hiệu lực vĩnh viễn, bạn bắt buộc phải bấm nút Publish App để chuyển sang chế độ In Production.

4. Cấu Hình Scopes Quyền Hạn (Non-sensitive, Sensitive, Restricted)

Trong thẻ Data Access, nhà phát triển phải khai báo tường minh danh sách các Scopes (phạm vi quyền hạn) mà ứng dụng cần truy cập. Google chia các quyền này thành 3 cấp độ rủi ro:

• Non-sensitive Scopes (Quyền cơ bản): Các quyền đọc thông tin hồ sơ cơ bản như openid, .../auth/userinfo.email, và .../auth/userinfo.profile. Các quyền này được phê duyệt tự động ngay lập tức mà không cần xác minh.
• Sensitive Scopes (Quyền nhạy cảm): Các quyền truy cập vào dữ liệu cá nhân riêng tư của người dùng như xem danh bạ (Contacts), lịch làm việc (Google Calendar), hoặc đọc/ghi dữ liệu trên Google Drive (.../auth/drive.file). Đòi hỏi bạn phải cung cấp video demo giải trình lý do sử dụng.
• Restricted Scopes (Quyền bị hạn chế cao độ): Các quyền can thiệp sâu vào dữ liệu nhạy cảm nhất của người dùng như đọc toàn bộ hộp thư Gmail (.../auth/gmail.readonly) hoặc gửi email tự động (.../auth/gmail.send). Yêu cầu kiểm toán an ninh bảo mật bên thứ ba (CASA Tier 2 Assessment) với chi phí từ vài trăm đến hàng ngàn USD mỗi năm.

5. Quản Lý Application Branding & Domain Verification

Khi người dùng đăng nhập bằng Google, màn hình đồng thuận sẽ hiển thị các thông tin thương hiệu mà bạn khai báo trong thẻ Branding:

• App Name & User Support Email: Tên ứng dụng hiển thị và email hỗ trợ khi người dùng có thắc mắc về quyền riêng tư.
• Application Home Page: Trang chủ chính thức của ứng dụng (bắt buộc phải có giao diện thực tế, không chấp nhận trang web trống).
• Privacy Policy & Terms of Service: Hai tài liệu pháp lý bắt buộc phải được công khai trên cùng tên miền chính của ứng dụng.
• Authorized Domains: Tên miền gốc chứa ứng dụng của bạn (ví dụ: yourdomain.com). Lưu ý: Tên miền này phải được xác thực quyền sở hữu thông qua Google Search Console trước khi được chấp thuận trong Google Auth Platform.

6. Khởi Tạo OAuth Client ID (Web, Desktop, Mobile & Redirect URIs)

Tại mục Clients, nhấn vào nút Create Client để khởi tạo cặp khóa tương thích với từng loại kiến trúc phần mềm:

Quy tắc vàng của Redirect URIs: Địa chỉ URL callback được khai báo trên Google Cloud phải trùng khớp 100% từng ký tự với URI mà ứng dụng gửi lên trong request. Bất kỳ sự sai lệch nào về giao thức (http:// vs https://), cổng (port) hoặc dấu gạch chéo cuối dòng (trailing slash) đều sẽ kích hoạt lỗi Error 400: redirect_uri_mismatch.

7. Toàn Bộ Mã Nguồn Triển Khai OAuth 2.0 (Python & Node.js)

Dưới đây là mã nguồn chuẩn hóa hai chiều: Trao đổi mã cấp quyền (Authorization Code) lấy cặp Token và tự động tái cấp quyền bằng Refresh Token khi Access Token hết hạn.

Kịch bản 1: Triển khai trên Python (Sử dụng google-auth và requests)

import requests
import json
from urllib.parse import urlencode

# 1. CẤU HÌNH THÔNG SỐ TỪ GOOGLE AUTH PLATFORM
CLIENT_ID = "YOUR_CLIENT_ID.apps.googleusercontent.com"
CLIENT_SECRET = "GOCSPX-your_client_secret_here"
REDIRECT_URI = "https://yourdomain.com/auth/callback"
TOKEN_ENDPOINT = "https://oauth2.googleapis.com/token"

# 2. HÀM TẠO ĐƯỜNG DẪN XÁC THỰC CHO NGƯỜI DÙNG BẤM VÀO
def get_authorization_url():
    params = {
        "client_id": CLIENT_ID,
        "redirect_uri": REDIRECT_URI,
        "response_type": "code",
        "scope": "openid email profile https://www.googleapis.com/auth/drive.readonly",
        "access_type": "offline",  # BẮT BUỘC: Để Google cấp Refresh Token
        "prompt": "consent"        # BẮT BUỘC: Ép người dùng đồng thuận để lấy Refresh Token
    }
    return f"https://accounts.google.com/o/oauth2/v2/auth?{urlencode(params)}"

# 3. HÀM ĐỔI AUTHORIZATION CODE LẤY TOKENS KHI GOOGLE CHUYỂN HƯỚNG VỀ
def exchange_code_for_tokens(auth_code):
    payload = {
        "client_id": CLIENT_ID,
        "client_secret": CLIENT_SECRET,
        "code": auth_code,
        "grant_type": "authorization_code",
        "redirect_uri": REDIRECT_URI
    }
    response = requests.post(TOKEN_ENDPOINT, data=payload)
    if response.status_code == 200:
        tokens = response.json()
        # Lưu access_token và refresh_token vào cơ sở dữ liệu an toàn
        return tokens
    else:
        raise Exception(f"Lỗi đổi token: {response.status_code} - {response.text}")

# 4. HÀM TỰ ĐỘNG GIA HẠN ACCESS TOKEN KHI HẾT HẠN (SỬ DỤNG REFRESH TOKEN)
def refresh_access_token(stored_refresh_token):
    payload = {
        "client_id": CLIENT_ID,
        "client_secret": CLIENT_SECRET,
        "refresh_token": stored_refresh_token,
        "grant_type": "refresh_token"
    }
    response = requests.post(TOKEN_ENDPOINT, data=payload)
    if response.status_code == 200:
        new_token_data = response.json()
        return new_token_data.get("access_token")
    else:
        raise Exception(f"Lỗi làm mới token: {response.text}")

Kịch bản 2: Triển khai trên Node.js Express (Chuẩn Production)

const express = require('express');
const axios = require('axios');
const app = express();

const CLIENT_ID = process.env.GOOGLE_CLIENT_ID;
const CLIENT_SECRET = process.env.GOOGLE_CLIENT_SECRET;
const REDIRECT_URI = 'http://localhost:3000/auth/google/callback';

// Endpoint chuyển hướng người dùng đến Google Login
app.get('/auth/google', (req, res) => {
    const rootUrl = 'https://accounts.google.com/o/oauth2/v2/auth';
    const options = {
        redirect_uri: REDIRECT_URI,
        client_id: CLIENT_ID,
        access_type: 'offline',
        response_type: 'code',
        prompt: 'consent',
        scope: [
            'https://www.googleapis.com/auth/userinfo.profile',
            'https://www.googleapis.com/auth/userinfo.email',
            'openid'
        ].join(' ')
    };
    const qs = new URLSearchParams(options);
    res.redirect(`${rootUrl}?${qs.toString()}`);
});

// Endpoint tiếp nhận callback từ Google
app.get('/auth/google/callback', async (req, res) => {
    const code = req.query.code;
    try {
        const tokenResponse = await axios.post('https://oauth2.googleapis.com/token', {
            client_id: CLIENT_ID,
            client_secret: CLIENT_SECRET,
            code: code,
            grant_type: 'authorization_code',
            redirect_uri: REDIRECT_URI
        });

        const { access_token, id_token, refresh_token } = tokenResponse.data;

        // Truy xuất thông tin người dùng bằng access token vừa nhận
        const userProfile = await axios.get('https://www.googleapis.com/oauth2/v2/userinfo', {
            headers: { Authorization: `Bearer ${access_token}` }
        });

        res.json({
            message: "Xác thực Google thành công!",
            user: userProfile.data,
            refreshTokenSaved: !!refresh_token
        });
    } catch (error) {
        console.error("OAuth Error:", error.response?.data || error.message);
        res.status(500).send("Xác thực thất bại");
    }
});

app.listen(3000, () => console.log('Auth Server running on port 3000'));

8. Giải Quyết Các Lỗi Kinh Điển: 403 Access Denied, redirect_uri_mismatch

Trong quá trình thiết lập và tích hợp, các nhà phát triển thường xuyên đối mặt với 3 mã lỗi điển hình sau:

9. Quy Trình Kiểm Định Bảo Mật (App Verification) Để Đưa Lên Production

Nếu ứng dụng của bạn yêu cầu quyền nhạy cảm (Sensitive Scopes) và cần phục vụ người dùng thực tế mà không hiển thị màn hình cảnh báo đỏ “Google hasn’t verified this app”, bạn bắt buộc phải thực hiện các thủ tục xác minh theo quy chuẩn:

1. Quay Video Minh Họa (YouTube Unlisted): Quay lại toàn bộ luồng người dùng từ lúc bấm nút đăng nhập, hiển thị URL thanh địa chỉ (có chứa Client ID), màn hình đồng thuận Consent Screen, và cách tính năng ứng dụng sử dụng quyền hạn đó để giải trình cho đội ngũ đánh giá của Google.
2. Xác Thực Tên Miền (Domain Ownership): Xác nhận quyền sở hữu tất cả các miền đã khai báo trong Google Search Console dưới cùng một tài khoản quản trị.
3. Kiểm Tra An Ninh Ứng Dụng Độc Lập (CASA): Nếu ứng dụng truy cập dữ liệu Gmail hoặc Google Drive diện rộng, Google sẽ chuyển tiếp hồ sơ sang đối tác an ninh độc lập để rà soát mã nguồn và kiểm thử lỗ hổng thâm nhập (Penetration Testing).

10. Đề Xuất Phần Cứng Bảo Mật Cho Kỹ Sư Hệ Thống

Để bảo vệ tuyệt đối các khóa bí mật hệ thống (Client Secrets, Private Keys) khỏi nguy cơ rò rỉ mã nguồn hoặc bị đánh cắp thông tin xác thực từ các cuộc tấn công lừa đảo (Phishing), dưới đây là các trang bị phần cứng chuyên dụng được khuyến nghị:

11. Nguồn Tài Liệu Kỹ Thuật Tham Khảo

Toàn bộ quy chuẩn và mã nguồn trong bài viết được đối chiếu trực tiếp từ các cổng thông tin phát triển chính thức của Google (liệt kê dưới dạng văn bản thuần):

• console.cloud.google.com/auth/overview?project=gen-lang-client-0310727020
• developers.google.com/workspace/guides/auth-overview
• developers.google.com/identity/protocols/oauth2
• developers.google.com/identity/protocols/oauth2/scopes
• support.google.com/cloud/answer/15549257
• cloud.google.com/docs/authentication