一個成功的App背後肯定有一堆後端服務提供支撐，認證授權服務（Authentication and Authorization Service，以下稱`AAS`）就是其中之一，它是約束App、保障資源安全的必備元件。現在也有第三方平臺提供此類服務，但萬事不求人，自己擼才是我們的風格。 *本文假設讀者有一定的OAuth2知識，若沒有可先閱讀博主以前寫的[一篇博文](https://www.cnblogs.com/newton/p/3409984.html)，或其它資料。* ## Why PKCE? 當我們開發一個App（本文指的是Native App），選擇何種AAS協議或模式是必須要謹慎考慮的問題。這就需要決策者對目前主流的AA協議有較深理解，若是隨手套用、流於形式，就可能埋下嚴重的安全隱患。我們以`OAuth2`為例進行說明。 對於`Client`和AAS同屬一個機構的情況，一般最簡單能想到的就是在App中畫個登入框，直連登入介面成功後返回`AccessToken`，這便是`Username&Password Flow`。其實，這種模式在Web領域流傳已久（返回的cookie或JWT可以認為就是AccessToken），但是App卻不適用。Why?有兩個問題需要解決： 1. 使用者如何鑑別client是否合法。 2. 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檔案](https://tools.ietf.org/html/rfc7636)中，這個規範就是`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`作為使用者體系。 ```bash # 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 ``` 4. 定義一個繼承自`IdentityDbContext`的`DbContext`——`ApplicationDbContext`，其中`ApplicationUser`繼承須自`IdentityUser`。 5. `Startup.ConfigureServices`，主要是將一些服務注入到IOC容器中。 ```c# public void ConfigureServices(IServiceCollection services) { //Other code... //DbContext services.AddDbContext(options => options.UseMySql(Configuration.GetConnectionString("DefaultConnection"))); //ASP.NET Core Identity services.AddIdentity() .AddEntityFrameworkStores() .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() .AddProfileService(); builder.AddDeveloperSigningCredential(); } ``` 其中`AddDefaultTokenProviders`和本文所指的Token沒關係，它主要提供了手機號驗證、郵箱驗證等Api，如何使用可參看[ASP.NET CORE IDENTITY TOKEN PROVIDERS – UNDER THE HOOD](https://www.stevejgordon.co.uk/asp-net-core-identity-token-providers)。 `options.Events.RaiseXXXXEvents`表示什麼級別的事件會被監聽到，可以自定義事件和監聽器，可參看官方文件[Events](https://identityserver4.readthedocs.io/en/latest/topics/events.html)。這種模式比到處log應該要稍好一點。 我們使用MySql持久化資料，`AddConfigurationStore`表示儲存一些預配置資料如clients、resources等等，`AddOperationalStore`儲存授權過程中產生的資料如codes、tokens等等。 `AddProfileService`用於新增自定義`claim`，泛型引數類需要實現`IProfileService`。 6. 配置IdentityServer到請求處理管道，在`Startup.Configure`中增加`app.UseIdentityServer()`（它間接呼叫了`app.UseAuthentication()`），注意它在管道中和其它處理器的順序。 7. 在資料庫中新增client。由於資料表中非關鍵欄位太多，我們一般使用管理後臺或編寫CRUD介面進行維護。以PKCE客戶端為例，我們只需構建帶必要屬性的如下client： ```c# // 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`。 8. 畫一個登入頁面  9. 使用者點選登入按鈕時執行： ```c# [HttpPost] [ValidateAntiForgeryToken] public async Task 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 1. LoginActivity  ```kotlin 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請求。 2. 互動的流程主要在`LoginViewModel`中 ```kotlin 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`。 ```kotlin @POST(TOKEN_ENDPOINT) @FormUrlEncoded suspend fun authorize(@FieldMap maps: Map): TokenRsp ``` 3. 獲取了token之後，就可以訪問Resource Server的資源了。在每次請求時新增請求頭如下： ```kotlin reqBuilder.addHeader( "Authorization", "Bearer ${Session.getAccessToken()}" ) ``` ### Resource Server 依舊以`ASP.NET Core`為例。 1. 新增依賴包`Microsoft.AspNetCore.Authentication.JwtBearer` 2. 在Startup.ConfigureServices註冊token校驗服務： ```c# services.AddAuthentication("Bearer") .AddJwtBearer("Bearer", options => { options.Authority = "https://localhost:5001"; }); ``` `options.Authority`設定為AAS地址。 由於AAS頒發的AccessToken預設是JWT格式，所以這裡我們使用JWT校驗。AccessToken還可設定為`Reference Token`格式，具體可參看[IdentityServer4之JWT簽名(RSA加密證書)及驗籤](https://www.cnblogs.com/guolianyu/p/9872661.html) 3. 保證Startup.Configure中有 ```c# app.UseAuthentication(); app.UseAuthorization(); ``` 4. 在Api上增加`[Authorize]`特性。 That's all ! 如果想要更精細的控制，比如控制Api只開放給符合特定要求的AccessToken，那麼就要宣告`Policy`了，如： ```c# services.AddAuthorization(options => { options.AddPolicy("ApiScope", policy => { policy.RequireAuthenticatedUser(); policy.RequireClaim("scope", "api1"); }); }); ``` 可查閱其它資料獲取更多資訊，這裡不再贅述。 --- ## 參考資料 [OAuth 2.0 for Native Apps](https://tools.ietf.org/html/draft-ietf-oauth-native-apps-05) [Asp.Net Core 中IdentityServer4 實戰之 Claim詳解](https://blog.csdn.net/a312586670/article/details/105039131) [淺談SAML, OAuth, OpenID和SSO, JWT和Session](https://www.jianshu.com/p/ff9d3