OAuth 2.1的状态与主要特征

经过多年的OAuth 2.0协议的发展,最新版本的 OAuth 2.1 协议已经在进行中,可访问 https://oauth.net/2.1/ 获取最新的相关信息。

2.1版本相比2.0版本的优化或不同点有:

OAuth 2.1

简单点说就是:

  • PKCE变成必须的了
  • Redrect URI的检查更严格
  • grant_type中的password, implicit都不再推荐使用(甚至不再支持)
  • 不再允许通过URL查询参数传递access_token(甚至不再支持)
  • 刷新token增加约束限制(如一次性刷新)

OAuth2.1将变得更加安全,从流程定义与各个端(endpoint)来讲;这也符合网络环境越来越复杂,安全问题越来越高的实际场景。相比传统的client端浏览器与APP来讲,未来的client端会更多样,如智能家居设备,穿戴设备,工业互联设备等。

从另一个方面来说,认证凭证(如常见的 密码)将趋于在授权服务(Authorization Server)中统一进行管理,认证的操作收归到授权服务器端来管控,不再放由client端可知晓(想想grant_type=password中可通过API传递用户凭证是多么的信任client端啊)。

OIDC中的术语介绍与示例

 

以下对OIDC主要的术语进行说明,并与OAuth2作相关对比。

  • EU End-User, 指用户(一般指有账号的个体,资源的拥有者)
  • RP Relying Party, 信任方(一般是一个软件应用), 理解为OAuth2中的客户端(client)即可, 需要在OP中注册
  • OP OpenID Provider, 能提供对EU进行认证的服务端(可理解为OAuth2中授权服务端),
    提供RP的注册(或管理)能力,EU管理,ID Token的签发与管理等。OIDC中的核心组件。
    OIDC-Server 就是一个OP的参考实现
  • ID Token 格式为JSON Web Token(JWT),
    包含EU认证授权信息等. 有关JWT请访问 https://jwt.io/除了JWT, 知道以下概念对掌握OIDC会很有帮助
    JSON Web Key(JWK),
    JSON Web Encryption(JWE),
    JSON Web Algorithm(JWA),
    JSON Web Signature(JWS)
  • UserInfo Endpoint EU信息接口(OAuth2保护), 在RP获取到access_token后,可调用此接口获取EU的详细信息.
    OIDC要求此接口必须使用https访问(更安全);一般在OP中提供的Discovery中获取
  • Claim EU信息的载体, 可在id_token中获取,主要包括认证信息与授权信息,可根据实际扩展
  • 查看完整术语定义请访问 https://openid.net/specs/openid-connect-core-1_0.html#Terminology

OIDC协议中抽象了一个主要的操作步骤与流程示意图,如下:

20200920150958

下面以AWS提供的OIDC服务来举例说明。 假设你现在有一个应用A想集成使用AWS的OIDC服务,在实现OIDC之前需要先做几件事

  1. 应用A(RP)先去AWS(OP)中注册一个应用并获取对应的client_id, client_secret,public key等信息( 一般这步骤是开发者去完成)。注册时一般需要提供应用名称,redirect_uri等信息。
  2. 根据AWS提供的实现文档进行应用A(RP)的集成(也是开发者完成)。

OIDC流程在此示例中的关系图如下:

20200920151748

结束。

 

详细完整的使用请访问 MyOIDC: https://gitee.com/mkk/MyOIDC

 

是否已经在远离了开源?

淌过全身的冷水,突然发现,多久没在写过开源的代码了.

那些开源的项目 spring-oauth-server, oauth2-shiro, HeartBeat 等多久没再更新过版本了.

查看着过去的提交记录, 我是否已经在远离了开源,远离了开源精神与 开源代码…

猛然发现,2017快过一半, 我却尚未那怕更新一个小版本, 没有, 都没有.

翻看着过去的日子, 时间都去哪了, 上班,工作,加班,继续不断的上班,工作,….

没有的开源码代码的精神了????

看着大家的捐助, 不断增大的技术交流微信群(OAuth-OIDC),; 我去在干些什么去了;;

 

没有进步, 没有开源的进步, 只在流逝的日子中渐渐远离.远离….

不断更新的技术, 我却在有了些停止不前,不在路上.

曾经把一个简单的事做成开源的小程序(HeartBeat), 是更需要更多的继续….

你现在的生活还有激情吗?你心中的火焰还在燃烧吗?    疑问着自己

 

请将身体更新, 请将代码更新, 请继续开源精神, …

人生最重要的不是索取,人生最重要的是奉献…

my_keyboard

“没有什么能够阻挡, 你对自由的向往,天马行空的生涯, 你的心了无牵挂, ….  也曾感觉彷徨, 当你低头的瞬间, 才发现脚下的路, ….”

—<蓝莲花> 许巍

http://bd.kuwo.cn/yinyue/203139

 

oauth2-shiro 0.2版本发布

oauth2-shiro 0.2版本正式发布, 在7月完成开发工作,但由于当时发布 http://git.oschina.net/mkk/oauth2-shiro-redis 项目竟然给忘记了. 该版本主要更新如下

1.更新首页UI, 参照spring-oauth-server

2.Add client details overview

3.Add client details testing

4.user add/edit, overview

5.添加API使用说明, 举例各个场景

6.发布到测试服务器

7.resources模块更新UI说明

 

从0.2版本开始可在线测试,测试地址分别为:

authz: https://andaily.com/authz/

resources:https://andaily.com/rs/

0.2版本访问地址: http://git.oschina.net/mkk/oauth2-shiro/tree/0.2/

oauth2-shiro 整合OLTU与SHIRO, 提供一个轻量的OAUTH2应用框架.

grant_type=authorization_code 中 redirect_uri的代码实现参考

OAuth2中grant_type=authorization_code时, 需要填写redirect_uri, 而该uri将如何处理与实现呢, 在此提供具体的讲解与实现参考

redirect_uri在注册ClientDetails时需要提供(当grant_type包含authorization_code时), 且在发起OAUTH2流程时需要在参数中传递redirec_uri, 这两处的值必须一致.

 

在业务中, redirect_uri代码实现主要用于接收返回的code值, 校验state是否合法, 以及通过code换取accessToken操作.

在 spring-oauth-client 项目的 AuthorizationCodeController.java 类中, authorization_code_callback 方法实现了以上的逻辑, 在具体实现是可参考该方法的实现, 代码如下:

@RequestMapping(value = "authorization_code_callback")
public String authorizationCodeCallback(AuthCallbackDto callbackDto, HttpServletRequest request, Model model) throws Exception {

    if (callbackDto.error()) {
        //Server response error
        model.addAttribute("message", callbackDto.getError_description());
        model.addAttribute("error", callbackDto.getError());
        return "redirect:oauth_error";
    } else if (correctState(callbackDto, request)) {
        //Go to retrieve access_token form
        AuthAccessTokenDto accessTokenDto = oauthService.createAuthAccessTokenDto(callbackDto);
        model.addAttribute("accessTokenDto", accessTokenDto);
        model.addAttribute("host", host);
        return "code_access_token";
    } else {
        //illegal state
        model.addAttribute("message", "Illegal \"state\": " + callbackDto.getState());
        model.addAttribute("error", "Invalid state");
        return "redirect:oauth_error";
    }

}

 

这里实现首先检查服务端是否返回error信息,

然后判断state是否正确, 若正确则显示一个页面, 并在code_access_token方法中(同一个类中)使用 httpclient 发起请求(grant_type=authorization_code)通过 code换取access_token.

其它情况则显示error信息.

 

http://git.oschina.net/mkk/spring-oauth-client

传递access_token参数的正确方式

在OAuth中, access_token参数的传递如何才能更安全呢? 不知你有没有具体去研究过, 在此总结传递access_token的正确方式,

(所谓正确方式是指传递方式更安全, 更隐匿, 更不容易被网络拦截,网络攻击的方式)

 

在 spring-oauth-server 与 oauth2-shiro 中均支持以下提到的传递access_token的方式.

 

1. 通过Header传递 access_token; [推荐]

在请求URL的Header中, 添加header -> Authorization: bearer access_token,  示例代码(Java):

postHandler.addHeader("Authorization", "bearer 0fe12a74-e613-4d1b-9785-f96847bad346");

一般在代码中使用httpclient或URLConnection来实现,如Android, IOS客户端, 不适用于浏览器传递access_token

2.若请求URL使用POST方式提交, 将access_token放在请求body中而不是拼接在URL上, 示例代码(HTML):

<form action="db_table_description" method="post">
    <input type="hidden" name="access_token" value="0fe12a74-e613-4d1b-9785-f96847bad346"/>
    <input type="text" name="username"/>
    <button type="submit">Submit</button>
</form>

3.最后的选择, 通过URL拼接参数access_token, 示例代码:

http://monkeyk.com/oauth_test?access_token=0fe12a74-e613-4d1b-9785-f96847bad346

一般使用在GET请求, POST等其他请求方式也支持

以上三种方式, 优先选择第一,第二种, 少用第三种方式.这些方式都是基于HTTP请求下所采用的.
更安全的传递access_token的方式是启用HTTPS连接,保证网络传输安全.