登录科普(一)CAS与Oauth

涉及内容:CAS、SSO、Oauth2.0,token、XSS、CSRF。

名词科普

  • Oauth2.0:Oauth是一个关于授权的开放标准网络协议,目前的版本是2.0。
  • CAS(Central Authentication Service) 中心认证服务。
  • SSO(Single Sign On) 单点登录。
  • token:一个主服务允许第三方访问特定资源的令牌。
  • CSRF(Cross-site request forgery)跨站请求伪造。
  • XSS(Cross Site Scripting)跨站脚本攻击。

在使用任何登录框架或者传输标准时,如果想安全,都要基于HTTPS协议!

Oauth2.0

原理解释

场景:你在(登录后)浏览某论坛时,遇到了一篇好文章,想要分享给大家时,你需要登录(扫码或者登录用户名密码)第三方账户来完成分享。
基本流程:

  1. 在点击分享链接时,主服务器会直接(接口)请求第三方服务器,第三方服务器会校验主服务器上的用户此时是否授权给自己(第三方);
  2. 没有授权信息,用户登录(扫描或者密码)。
  3. 主服务器拿着用户的登录信息去第三方确认认证授权(密码是否正确、是否授权)。
  4. 认证失败,密码错误。(重新登录)
  5. 认证成功(确认授权),第三方认证服务会返回的授权码。
  6. 主服务器带着授权码请求第三方资源服务器,第三方资源服务器会返回指定的URI(分享界面)。
  7. 用户操作分享操作(填写自己的话语),点击分享按钮完成。

在整个流程中,涉及的角色有:Resource Owner(用户)、Resource Server、Client、Authorization Server。其中:
  认证的登录界面是主服务器提供;
  用户的最终操作界面(本例中为分享页面),为第三方服务提供的界面(接口)。

【此处缺图】

针对于用户的授权,Oauth2.0提供了四种方式:

  • 授权码模式(authorization code)
  • 简化模式(implicit)
  • 密码模式(resource owner password credentials)
  • 客户端模式(client credentials)

因考虑到authorization code方式是最严谨、最广泛、最贴近于服务器端的一种认证方式,所以只介绍着一种认证方式。

authorization code
适用场景:此类型可用于有服务端的应用,是最贴近老版本的方式。
【此处缺图】

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

(A)用户打开客户端以后,客户端要求用户给予授权。
(B)用户同意给予客户端授权。
(C)客户端使用上一步获得的授权,向认证服务器申请令牌。
(D)认证服务器对客户端进行认证以后,确认无误,同意发放令牌。
(E)客户端使用令牌,向资源服务器申请获取资源。
(F)资源服务器确认令牌无误,同意向客户端开放资源。

说明:
Client Identifier是需要在第三方审核通过所得。
Redirection URI是成功之后,客户端希望认证服务器跳转到的页面,一般来说,该页面由客户端提供。整个流程一共传递了两次Redirection URI,是为了防止Authorization Code被别人获取,而从第三方服务器端直接重定向。
其中access token是访问调用第三方应用的凭证。因考虑到access token 的有效时长短,会有使用refresh token来(调用自定义接口)进行刷新并获取新的access token。refresh token也可以有时效,一般设置为一个月。生成也很简单,唯一的信息自定义转码方式即可生成。
state用于保持请求和回调的状态,授权请求后原样带回给第三方。该参数可用于防止csrf攻击(跨站请求伪造攻击),建议第三方带上该参数,可设置为简单的随机数加session进行校验。
登录操作是在第二步来完成的。认证服务器检测到用户未登录,会跳转到登录页面。


CAS讲解

CAS只支持HTTPS协议。

共涉及角色有:CAS Client(下文提到的系统A等)、User、CAS Server(认证中心)。

【此处缺图】

流程:
1)用户访问系统A;
2)系统A发现用户没有登录,也没有ticket,重定向到认证中心;有ticket跳转 第7)步
3)认证中心发现用户并未登录,展示登录页面;
4)用户登录;
5)认证中心登录成功,带着生成的ticket,重定向到之前的系统A页面;
6)系统A检查登录,还是未登录,但存在ticket。系统A带着ticket和认证中心进行校验;
7)认证中心返回对应的用户名;
8)系统A检查返回的用户名是否只有一个且不为空,若是,则返回给用户指定的资源信息;若不是,则跳转 第2)步

注意事项:

  1. 登录状态的判断:子系统不可能每次都和认证中心进行校验,所以需要有局部session。而认证中心生成的Session为全局Session。
  2. 登出:局部Session依附于全局Session,当全局Session注销,局部Session也不存在;当局部Session被注销(用户登出),全局Session也不应该存在。
  3. 在重定向的过程中,如后续还需要二次重定向,需要获取前端URL地址作为参数传递给第一次重定向的服务器。
  4. 在登录了A系统后,服务端会存在一个TGT(ticket generated ticked),客户端会存在一个TGC(ticket generated cookie)。TGT是票据生成票据。TGC内存了一个服务器上TGT的id。在登录B系统时,服务器会查询本地是否存在TGC,若存在,直接获取该TGC。

CSRF

攻击者盗用你的名义,执行操作。

image

从上图可以看出,要完成一次CSRF攻击,受害者必须依次完成两个步骤:
1.登录受信任网站A,并在本地生成Cookie。
2.在不登出A的情况下,访问危险网站B。

Spring Security提供的结局方案是:Synchronizer Token Pattern


XSS

在你的页面,(利用script的立即执行,)执行我想要执行的JS代码。

本文中参考地址:
Oath2.0参考:微信API文档OAuth的改变理解OAuth 2.0
CAS参考:CAS与SSO探究SSO CAS单点系列-慕课
CSRF参考:https://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
XSS参考:http://netsecurity.51cto.com/art/201408/448305_all.htm

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,324评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,303评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,192评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,555评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,569评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,566评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,927评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,583评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,827评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,590评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,669评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,365评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,941评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,928评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,159评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,880评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,399评论 2 342