一個成功的App背後肯定有一堆後端服務提供支撐，認證授權服務（Authentication and Authorization Service，以下稱AAS）就是其中之一，它是約束App、保障資源安全的必備元件。現在也有第三方平臺提供此類服務，但萬事不求人，自己擼才是我們的風格。
本文假設讀者有一定的OAuth2知識，若沒有可先閱讀博主以前寫的一篇博文，或其它資料。
Why PKCE?
當我們開發一個App（本文指的是Native App），選擇何種AAS協議或模式是必須要謹慎考慮的問題。這就需要決策者對目前主流的AA協議有較深理解，若是隨手套用、流於形式，就可能埋下嚴重的安全隱患。我們以OAuth2為例進行說明。
對於Client和AAS同屬一個機構的情況，一般最簡單能想到的就是在App中畫個登入框，直連登入介面成功後返回AccessToken，這便是Username&Password Flow。其實，這種模式在Web領域流傳已久（返回的cookie或JWT可以認為就是AccessToken），但是App卻不適用。Why?有兩個問題需要解決：
- 使用者如何鑑別client是否合法。
- AAS如何鑑別登入請求是否來自於合法client。
針對這兩個問題，Web應用程式依靠多年來各大廠大V對Web安全的重視和發展，已經有相當完備的應對手段。比如在使用者側，瀏覽器位址列上的域名和CA（瀏覽器常以鎖頭圖示顯示）可以給到使用者提醒；同時依靠資料隔離（瀏覽器沙盒、cookie等）能讓AAS判斷請求是否來自同域。
而對於App來說，使用者側沒有一個標準識別資訊能給到使用者，這要求使用者須要憑藉自身經驗判斷App是否為釣魚App；而本文所涉及的各類授權模式也無法保證百分之百的安全，只能做一些簡單的防範（其實使用者側App防偽本身就不屬於AAS的職責範圍）。所幸各大應用商店的稽核機制、手機自帶的掃毒程式、App自身的後端防範（e.g.雙因素認證two-factor authentication）等等手段讓做一個釣魚App相當困難。當然，對於小App來說，剛說的這些手段可能都沒法覆蓋到，特別是Android系統Apk隨意下載安裝，使用者其實是很容易中招的，只是仿製一款沒多少人用的App更加沒意義。
我們把關注點放到後端，看看OAuth2的幾種模式是否可行。
Username&Password Flow：適用於AAS高度信任請求的場景，既AAS認為所有請求肯定來自於合法的客戶端———這種情況一般會出現在請求來自於信任域或內網系統———否則別人很容易通過外網系統抓包構建非法請求，就算每次請求的使用者名稱密碼錯誤也能讓AAS浪費大量資源；或者以正確的使用者名稱密碼拿到token後，去Resource端呼風喚雨。所以，此模式不適用於App應用。
Client Credentials Flow：對於外部請求的身份識別，現在較廣泛的解決方案是AAS給App頒發一個事先約定的身份證明（如client_id和client_secret對），App將它們織入請求（如簽名），AAS以此確定請求合法。然而新的問題又出現了，就是如何保證該身份證明本身的安全性。這個問題在移動端並沒有完美的解決方案。以Android為例，儲存在Sharedpreferences需要在執行時寫入，這就給了不法分子可趁之機；即使儲存在最安全的KeyStore裡，使用時還要傳入外部金鑰獲取，那這個外部金鑰的安全如何保障呢：）。
既然如此，那乾脆不開放介面，而是要求App嵌入AAS自己的登入介面，類似於Authorization Code Flow和Implicit Flow。因為Implicit Flow可看作Authorization Code Flow的“低配版”，我們先來論證Authorization Code Flow的可行性。
Authorization Code Flow中關鍵的一步是client獲取code，是AAS傳送重定向狀態碼（30X）到瀏覽器告知瀏覽器重定向到預先指定的URI，並將code附加到query。對Web應用程式來說，重定向的URI是屬於client域的URL，而瀏覽器的安全級別也防止了其它程式對code的截獲，且就算截獲了，由於惡意程式不知道Client Credentials（存於client後端），也無法拿去交換AccessToken。而對於App，情況又變得錯漏百出，如前所述，Client Credentials無法得到安全保障，而且code被攔截的風險也比Web端高了很多——
首先，重定向的URI的作用改變了，它起到一個類似“喚起”的作用，系統根據URI的scheme喚起相應App，如果惡意App註冊了相同的scheme就能輕易拿到code；其次，URI從系統瀏覽器傳遞到App的過程走的基本都是不安全通道，這也增加了傳遞過程中被截獲的風險。
於是Authorization Code Flow也被我們否了，那Implicit Flow自然更不用說，而且Implicit Flow無法提供RefreshToken，這對App來說可不能忍。
另外，使用者側也不推薦在App中嵌入Web頁面，一個是增加使用者識別的難度，另一個給了App訪問Web隱私資料的機會。現在很多三方登入並不會提供嵌入式的頁面，都是直接開啟它們自己的App的單獨登入介面，應該就是主要避免這個問題。
看來在App場景下，OAuth2的其中四個授權模式多少都有安全隱患，那還有什麼協議能支援App的認證授權呢？難道這麼多年的移動網際網路，大家都是在裡面裸奔嗎？現實情況雖然沒有如此糟糕，但筆者所接觸到的專案和開發人員，普遍對所使用的協議是否真的安全缺少認知，多年執行良好很可能是因為你的App還不起眼：）
偉大的萊布尼茨·牛頓說過，地球毀滅與普通人無關，因為總會有其他人去解決。有一部分人注意到了App的授權安全問題，這其中又有一小撮人各種改造了自己的專案，最後有幾個人提出了一個規範並收錄在RFC檔案中，這個規範就是Proof Key for Code Exchange(即PKCE)。官方說法PKCE是Authorization Code Flow的擴充套件[和增強]，It is primarily used by mobile and JavaScript apps, but the technique can be applied to any client as well.
之後我們走完一遍授權流程就會清楚，PKCE和Authorization Code Flow確實無本質不同，差別在對CSRF的防範手段上。因為App沒有瀏覽器那樣的cookie支援，AAS沒有session這樣的東西來儲存state引數從而防止CSRF，所以轉而使用PKCE的code_verifier和code_challenge，順便解決了無client_secret驗證身份的問題。
PKCE擴充套件不會新增任何新響應，因此即使授權伺服器不支援，客戶端也可以始終使用PKCE擴充套件。
確定好授權模式，接下來就是要實現或者尋找一個合適的框架，以前用過的DotNetOpenAuth已經很久沒更新了，是否支援PKCE尚不清楚。本著與時俱進的想法，為ASP.NET Core量身定製的IdentityServer4進入了視線。它是一款基於OpenID Connect的AAS框架。
Java開發的Keycloak在7.0版本也加入了對PKCE的支援
OIDC(OpenID Connect)
OpenID Connect是OpenID發展到第三代的產物，它其實是原來OpenID和OAuth的集合體。本人當年在研究OAuth的時候就被OpenID搞了一頭霧水，總感覺OpenID和AccessToken雖然語義不同，但兩者完全可以歸為一個。多年之後OpenID Connect姍姍來遲，但細究之後發現還是換湯不換藥，只不過原本的OpenID現在變成了IDToken（一般使用JWT格式來包裝。得益於JWT的自包含性，緊湊性以及防篡改機制，使得ID-Token可以安全的傳遞給第三方客戶端程式並且容易被驗證。），區別於AccessToken。為什麼不乾脆合併成一個Token呢？其實從名稱上就能看出來它們各自的職責不同，從職責及歷史角度看，如此這般也是合理。
IDToken只是用於標識使用者，側重於使用者資訊，可用於單點登入等會話相關場景，Client也可以把使用者資訊儲存下來便於使用者行為統計分析。它的標準流程中使用者參與是必須的。AccessToken解決的問題是授權[給Client]，而授權可能是使用者授權也可能是AAS直接授權，使用者認證並不是不可或缺的條件，所以授權過程中並不一定需要使用者參與。在任何模式下，Client也不需要知道使用者資訊就能無障礙訪問授權過的API。現在看來，AccessToken當然可以在某些模式下包含IDToken，但若沒有IDToken，若只是為了標識使用者使用AccessToken就顯得不那麼恰當了。另外，就算有使用者參與，IDToken就一個，但對於不同的Client，AccessToken肯定是不一樣的。
實戰
Talk is cheap, show you the code. 我們的目標很簡單，就是實現App的登入授權，通過後可以拿著token呼叫資源Api。使用者對背後的邏輯是無感知的，對他們來說就和普通的登入一樣。為了達到這個目的，我們還需要把登入介面嵌入到App中——細心的讀者會發現這似乎違背了上一節的提醒，但是上面的建議主要面向的場景是AAS作為第三方登入平臺，服務的App不受完全信任——由於我們這個App也是自己從頭開始擼的，所以不用考慮這個問題。
下面分別就AAS、App、Resource Server列出關鍵步驟和程式碼。
AAS
為簡單起見，我們直接使用ASP.NET Core Identity作為使用者體系。
# 1.建立一個空的mvc專案
dotnet new mvc -o AAS
# 2.新增ASP.NET Core Identity相關依賴包
dotnet add package Microsoft.Extensions.Identity.Stores
dotnet add package Microsoft.AspNetCore.Identity.EntityFrameworkCore
# 3.新增IdentityServer4依賴包
dotnet add package IdentityServer4
dotnet add package IdentityServer4.EntityFramework
dotnet add package IdentityServer4.AspNetIdentity
- 定義一個繼承自
IdentityDbContext<ApplicationUser>的DbContext——ApplicationDbContext，其中ApplicationUser繼承須自IdentityUser。 Startup.ConfigureServices，主要是將一些服務注入到IOC容器中。
public void ConfigureServices(IServiceCollection services)
{
//Other code...
//DbContext
services.AddDbContext<ApplicationDbContext>(options =>
options.UseMySql(Configuration.GetConnectionString("DefaultConnection")));
//ASP.NET Core Identity
services.AddIdentity<ApplicationUser, IdentityRole>()
.AddEntityFrameworkStores<ApplicationDbContext>()
.AddDefaultTokenProviders();
//IdentityServer
string migrationsAssembly = typeof(Startup).Assembly.GetName().Name;
var builder = services.AddIdentityServer(options =>
{
options.Events.RaiseErrorEvents = true;
options.Events.RaiseInformationEvents = true;
options.Events.RaiseFailureEvents = true;
options.Events.RaiseSuccessEvents = true;
// see https://identityserver4.readthedocs.io/en/latest/topics/resources.html
options.EmitStaticAudienceClaim = true;
})
.AddConfigurationStore(options =>
{
options.ConfigureDbContext = builder =>
builder.UseMySql(Configuration.GetConnectionString("DefaultConnection"),
sql => sql.MigrationsAssembly(migrationsAssembly));
})
.AddOperationalStore(options =>
{
options.ConfigureDbContext = builder =>
builder.UseMySql(Configuration.GetConnectionString("DefaultConnection"),
sql => sql.MigrationsAssembly(migrationsAssembly));
})
.AddAspNetIdentity<ApplicationUser>()
.AddProfileService<ApplicationProfileService>();
builder.AddDeveloperSigningCredential();
}
其中AddDefaultTokenProviders和本文所指的Token沒關係，它主要提供了手機號驗證、郵箱驗證等Api，如何使用可參看ASP.NET CORE IDENTITY TOKEN PROVIDERS – UNDER THE HOOD。
options.Events.RaiseXXXXEvents表示什麼級別的事件會被監聽到，可以自定義事件和監聽器，可參看官方文件Events。這種模式比到處log應該要稍好一點。
我們使用MySql持久化資料，AddConfigurationStore表示儲存一些預配置資料如clients、resources等等，AddOperationalStore儲存授權過程中產生的資料如codes、tokens等等。
AddProfileService<T>用於新增自定義claim，泛型引數類需要實現IProfileService。
- 配置IdentityServer到請求處理管道，在
Startup.Configure中增加app.UseIdentityServer()（它間接呼叫了app.UseAuthentication()），注意它在管道中和其它處理器的順序。 - 在資料庫中新增client。由於資料表中非關鍵欄位太多，我們一般使用管理後臺或編寫CRUD介面進行維護。以PKCE客戶端為例，我們只需構建帶必要屬性的如下client：
// interactive client using code flow + pkce
new Client
{
ClientId = "interactive",
RequireClientSecret = false,
AllowedGrantTypes = GrantTypes.Code,
RedirectUris = { "https://localhost:44300/signin-oidc" },
AllowOfflineAccess = true,
AllowedScopes = { "openid", "profile", "scope2" }
},
其中RequireClientSecret設為false表示互動時不需要client_secret參與；AllowOfflineAccess設為true表示需要獲取Refresh token；RedirectUris是與client約定好的重定向地址；is4預設開啟對client的PKCE互動的支援（RequirePkce），當然首先要AllowedGrantTypes = GrantTypes.Code。
-
畫一個登入頁面
-
使用者點選登入按鈕時執行：
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Login(LoginInput model)
{
// 關鍵，check if we are in the context of an authorization request
var context = await _interaction.GetAuthorizationContextAsync(model.ReturnUrl);
if (ModelState.IsValid)
{
//toetb isPersistent設為false，應該跟AccessToken的有效時間不相干
var result = await _signInManager.PasswordSignInAsync(model.PhoneNumber, model.Password, false, lockoutOnFailure: true);
if (result.Succeeded)
{
var user = await _userManager.FindByNameAsync(model.PhoneNumber);
await _events.RaiseAsync(new UserLoginSuccessEvent(user.UserName, user.Id, user.UserName, clientId: context?.Client.ClientId));
if (context != null)
{
// we can trust model.ReturnUrl since GetAuthorizationContextAsync returned non-null
return Redirect(model.ReturnUrl);
}
}
await _events.RaiseAsync(new UserLoginFailureEvent(model.Password, "invalid credentials", clientId: context?.Client.ClientId));
ModelState.AddModelError(string.Empty, _localizer["Invalid username or password"]);
}
// something went wrong, show form with error
return View(model);
}
其中_interaction是IIdentityServerInteractionService型別的物件，呼叫它的GetAuthorizationContextAsync能區分使用者操作是處於授權過程還是普通登入。
App
- LoginActivity
class LoginActivity : BaseActivity() {
private val vm by lazy {
this.getViewModel(LoginViewModel::class.java)
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_login)
login_page.webViewClient = object : WebViewClient() {
override fun shouldOverrideUrlLoading(
view: WebView?,
request: WebResourceRequest?
): Boolean {
val url = request?.url
if (OIDC.REDIRECT_URL.indexOf(url?.host!!) > -1) {
val code = url!!.getQueryParameter("code")
vm.getToken(code!!)
return true
}
return super.shouldOverrideUrlLoading(view, request)
}
}
login_page.loadUrl(vm.loginUrl)
}
}
使用WebViewClient嵌入AAS登入頁面，並重寫shouldOverrideUrlLoading方法，當發現瀏覽器redirect約定的URL時即知使用者已登入成功，此時攔截跳轉，併發起token請求。
- 互動的流程主要在
LoginViewModel中
class LoginViewModel @Inject constructor() : ViewModel() {
@Inject
lateinit var authService: AuthorizationService
var code_verifier: String = getRandomStr(
64,
Alphabet.PUREDIG.plus(Alphabet.LOWERCASE).plus(Alphabet.CAPITAL).plus(Alphabet.SPECIAL)
)
val redirectUrl = URLEncoder.encode(OIDC.REDIRECT_URL, "UTF-8")
lateinit var code_challenge: String
lateinit var loginUrl: String
init {
code_challenge = getChallengeCode(code_verifier)
loginUrl = """
${OIDC.AUTHORIZATION_ENDPOINT}
?response_type=code&client_id=${OIDC.CLIENT_ID}&code_challenge=$code_challenge&code_challenge_method=S256
&redirect_uri=$redirectUrl&scope=openid%20profile%20offline_access
""".trimIndent()
}
fun getToken(code: String) {
viewModelScope.launch(Dispatchers.IO) {
//取access_token
val rsp = authService.authorize(
mapOf(
"code_verifier" to code_verifier,
"code" to code,
"redirect_uri" to OIDC.REDIRECT_URL,
"client_id" to OIDC.CLIENT_ID,
"grant_type" to "authorization_code"
)
)
rsp.apply {
val token = Token(
idToken,
accessToken,
refreshToken,
getCurrentTimeStamp() + expiresIn,
scope
)
Session.storeToken(token)
}
}
}
private fun getChallengeCode(code_verifier: String): String {
val bytes = code_verifier.toByteArray(Charset.forName("US-ASCII"))
val md = MessageDigest.getInstance("SHA-256")
md.update(bytes, 0, bytes.size)
val digest = md.digest()
val challenge =
Base64.encodeToString(digest, Base64.URL_SAFE or Base64.NO_WRAP or Base64.NO_PADDING)
return challenge
}
override fun onCleared() {
viewModelScope.coroutineContext.cancelChildren()
super.onCleared()
}
}
loginUrl查詢字串各引數的意義可參看RFC文件，重點關注code_challenge。
使用者登入成功後，就可以用code換token了，重點關注code_verifier，AAS會拿著這個和上一步的code_challenge進行比對校驗。這裡使用Retrofit2封裝了Http請求，注意獲取token時，content-type要設定為application/x-www-form-urlencoded。
@POST(TOKEN_ENDPOINT)
@FormUrlEncoded
suspend fun authorize(@FieldMap maps: Map<String, String>): TokenRsp
- 獲取了token之後，就可以訪問Resource Server的資源了。在每次請求時新增請求頭如下：
reqBuilder.addHeader(
"Authorization",
"Bearer ${Session.getAccessToken()}"
)
Resource Server
依舊以ASP.NET Core為例。
- 新增依賴包
Microsoft.AspNetCore.Authentication.JwtBearer - 在Startup.ConfigureServices註冊token校驗服務：
services.AddAuthentication("Bearer")
.AddJwtBearer("Bearer", options =>
{
options.Authority = "https://localhost:5001";
});
options.Authority設定為AAS地址。
由於AAS頒發的AccessToken預設是JWT格式，所以這裡我們使用JWT校驗。AccessToken還可設定為Reference Token格式，具體可參看IdentityServer4之JWT簽名(RSA加密證照)及驗籤
- 保證Startup.Configure中有
app.UseAuthentication();
app.UseAuthorization();
- 在Api上增加
[Authorize]特性。
That's all ! 如果想要更精細的控制，比如控制Api只開放給符合特定要求的AccessToken，那麼就要宣告Policy了，如：
services.AddAuthorization(options =>
{
options.AddPolicy("ApiScope", policy =>
{
policy.RequireAuthenticatedUser();
policy.RequireClaim("scope", "api1");
});
});
可查閱其它資料獲取更多資訊，這裡不再贅述。
參考資料
OAuth 2.0 for Native Apps
Asp.Net Core 中IdentityServer4 實戰之 Claim詳解
淺談SAML, OAuth, OpenID和SSO, JWT和Session