Web Authentication in Chrome extension 外掛環境的網站授權筆記

這篇筆記主要紀錄在 Google Chrome Extension 環境如何取得使用者 identity 以及使用Google Oauth2 授權。

chrome.identity

在 Google Chrome 想要拿到一個使用者身分最基本的情況只要使用 chrome.identity 就可以了，可以取得 access_token 後丟給 server 取得身分。

1. chrome.identity.getAuthToken 取得 access_token ，這個 token 會被 cache 在 Chrome identity API裡面一陣子，第二次之後取得會很快，相對需要手動 removeCachedAuthToken 來刪除。scope 則是在 plugin 的 manifest.json 中定義。

2. 取得 access_token 後可以在 server 或是 client 使用 'Authorization' header 向 Google API URI 要資料。

在 background page 呼叫 chrome.identity 可以指定 interactive 和登入身分，但是這個登入身分和類似API中的 login_hint 不同，chrome.identity 限制這個身分是當下 Chrome Browser 使用者的身分之一，而且使用者必須要在登入狀態，跟我們常看到的一個頁面給使用者選擇要登入不同身分登入的情況不同，開發者即使知道欲取得的 user email or user ID 也無法提示使用者這個已知，使用者也無法選擇。

Web Server Oauth Process

另一個方法使用 Google Oauth2 的 web process ，引導使用者跳轉或是開啟一個授權頁面，使用者授權後 Google 會把一組 code 丟給 redirect_uri (你的server)，然後再用這組 code 去取得 access_token and/or refresh_token ，這個方法使用者就可以選擇登入的帳號了，如果知道使用者的 email 還可以先提示 login_hint ，這樣使用者可以少一個選帳號的動作，使用者如果授權過同樣的 scope 這個 interactive 過程會直接帶過，而且一個 Chrome Browser 可以取得多組 Google Account 身分和授權，不受限制。

Server 知道身分之後要怎麼給 client 呢？可以透過 session 讓 client 知道使用者登入了等一些資訊，有點被動，還是要用 long polling / websocket 等牛刀，另外 background page 是沒有存 web cookie 的獨立環境，授權流程如果放進 web page 裡面，還要考慮 Content Security Policy ，我就把外掛裝在 business Gmail 的時候可以運作，但是一登入 @gmail.com 的 Gmail 頁面就噴 Content Security Policy Error 了，同樣是 Gmail 介面沒想到 Content Security Policy 官版的比較嚴格。

Mix JSONP Authentication Process

我的網站沒有提供 Google Account 登入，因為估計目標市場只有很少使用人使用 Google Account for work。我在網站提供一組 JSONP 讓，Chrome Extension 來抓，這個抓授權的 javascript 只能放在 content script 裡面，不能放在 web page 或 background page ， web page 可能有 http/https 限制、Content Security Policy。Google Oauth則在需要取得授權的時候才跑 Web Server Oauth Process.

manifest.json 裡面的 content_security_policy 是限制開發者自帶的 script 的環境，如果要配合 gmail.js 把 script 都丟進 web page ，那就要受到 web page 的環境的(web owner 決定) policy 管制。