您的位置：首页 > 移动开发

【从零开始撸一个App】PKCE

2020-08-28 14:15 1511 查看

一个成功的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?有两个问题需要解决：

  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应用。

15b0 

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只是用于标识用户，侧重于用户信息，可用于单点登录等会话相关场景，Cl ad8 ient也可以把用户信息保存下来便于用户行为统计分析。它的标准流程中用户参与是必须的。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
  1. 定义一个继承自
    IdentityDbContext<ApplicationUser>
    的
    DbContext
    ——
    ApplicationDbContext
    ，其中
    ApplicationUser
    继承须自
    IdentityUser
    。
  2. 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>()

56c
.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));
})

56c
.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
。

  1. 配置IdentityServer到请求处理管道，在
    Startup.Configure
    中增加
    app.UseIdentityServer()
    （它间接调用了
    app.UseAuthentication()
    ），注意它在 25ec 管道中和其它处理器的顺序。
  2. 在数据库中添加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
。

  1. 画一个登录页面

  2. 用户点击登录按钮时执行：

[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

  1. 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请求。

  1. 交互的流程主要在
    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
  1. 获取了token之后，就可以访问Resource Server的资源了。在每次请求时添加请求头如下：
reqBuilder.addHeader(
"Authorization",
"Bearer ${Session.getAccessToken()}"
)

Resource Server

依旧以

ASP.NET Core
为例。

  1. 添加依赖包
    Microsoft.AspNetCore.Authentication.JwtBearer
  2. 在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加密证书)及验签

  1. 保证Startup.Configure中有
app.UseAuthentication();
app.UseAuthorization();
  1. 在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

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
标签： 
相关文章推荐
新的分享
章节导航