当前播放: 39 | Staffjoy安全认证架构和SSO
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
课程目录
第一章:课程介绍和案例需求 (5讲)
01 | 课程介绍
免费
02 | 背景说明
免费
03 | 课程目标和主要内容
免费
04 | 课程案例需求
免费
05 | 课程补充说明
免费
第二章:系统架构设计和技术栈选型 (8讲)
06 | 为何采用微服务架构?
免费
07 | 架构设计和技术栈选型
免费
08 | 数据和接口模型设计:账户服务
09 | 数据和接口模型设计:业务服务
10 | Dubbo、Spring Cloud和Kubernetes该如何选型(上)
11 | Dubbo、Spring Cloud和Kubernetes该如何选型(中)
12 | Dubbo、Spring Cloud和Kubernetes该如何选型(下)
13 | 技术中台到底讲什么?
第三章:服务开发框架设计和实现 (10讲)
14 | Staffjoy项目结构组织
15 | 谷歌为何采用单体仓库(Mono-Repo)?
16 | 微服务接口参数校验为何重要?
17 | 如何实现统一异常处理?
18 | DTO和DMO为什么要互转?
19 | 如何实现基于Feign的强类型接口?
20 | 为什么框架层就要考虑分环境配置?
21 | 异步处理为何要复制线程上下文信息?
22 | 为你的接口添加Swagger文档
23 | 主流微服务框架概览
第四章:可编程网关设计和实践 (9讲)
24 | 网关和BFF是如何演化出来的(上)
25 | 网关和BFF是如何演化出来的(下)
26 | 网关和反向代理是什么关系?
27 | 网关需要分集群部署吗?
28 | 如何设计一个最简网关?
29 | Faraday网关代码解析(上)
30 | Faraday网关代码解析(下)
31 | 生产级网关需要考虑哪些环节?
32 | 主流开源网关概览
第五章:安全框架设计和实践 (10讲)
33 | 安全认证架构演进:单块阶段(上)
34 | 安全认证架构演进:单块阶段(下)
35 | 安全认证架构演进:微服务阶段
36 | 基于JWT令牌的安全认证架构
37 | JWT的原理是什么?
38 | JWT有哪两种主要流程?
39 | Staffjoy安全认证架构和SSO
40 | 用户认证代码剖析
41 | 服务调用鉴权代码剖析
42 | 如何设计用户角色鉴权?
第六章:服务测试设计和实践 (7讲)
43 | Spring Boot微服务测试该如何分类?
44 | 什么是契约驱动测试?
45 | 什么是测试金字塔?
46 | 单元测试案例分析
47 | 集成测试案例分析
48 | 组件测试案例分析
49 | Mock vs Spy
第七章:可运维架构设计和实践 (8讲)
50 | 何谓生产就绪(Production Ready)?
51 | Spring Boot如何实现分环境配置
52 | Apollo vs SpringCloudConfig vs K8s ConfigMap
53 | CAT vs Zipkin vs Skywalking(上)
54 | CAT vs Zipkin vs Skywalking(下)
55 | 结构化日志和业务审计日志
56 | 集中异常监控和Sentry
57 | EFK & Prometheus & Skywalking + Kubernetes 集成架构
第八章:服务容器化和Docker Compose部署 (10讲)
58 | 本地开发部署架构和软件需求
59 | 手工服务部署和测试(上)
60 | 手工服务部署和测试(中)
61 | 手工服务部署和测试(下)
62 | SkyWalking调用链监控实验
63 | Docker和Docker Compose简介
64 | 容器镜像构建Dockerfile解析
65 | Docker Compose服务部署文件剖析
66 | 将Staffjoy部署到本地Docker Compose环境(上)
67 | 将Staffjoy部署到本地Docker Compose环境(下)
第九章:云原生架构和Kubernetes容器云部署 (17讲)
68 | 到底什么是云原生架构?
69 | Kubernetes背景和架构
70 | Kubernetes有哪些基本概念(上)
71 | Kubernetes有哪些基本概念(下)
72 | 理解Kubernetes节点网络和Pod网络
73 | 深入理解Service和ServiceDiscovery
74 | NodePort vs LoadBalancer vs Ingress
75 | 本地测试Kubernetes部署文件剖析
76 | 本地测试Kubernetes环境搭建
77 | 将Staffjoy部署到本地Kubernetes环境(上)
78 | 将Staffjoy部署到本地Kubernetes环境(下)
79 | 生产环境Kubernetes部署文件剖析
80 | 阿里云Kubernetes环境创建
81 | 将Staffjoy部署到阿里云Kubernetes环境
82 | Kubernetes应用动态配置实验
83 | Kubernetes应用金丝雀发布实验
84 | 阿里云资源释放
第十章:项⽬复盘、应用和扩展环节 (2讲)
85 | 课程复盘
86 | 项目扩展和应用
第十一章:附录 Staffjoy 项目源代码解析 (8讲)
87 | Account服务
88 | Company服务
89 | Mail、SMS和Bot服务
90 | Faraday服务
91 | WhoAmI服务
92 | WWW服务
93 | 前端应用
94 | 结束语
39 | Staffjoy安全认证架构和SSO

39 | Staffjoy安全认证架构和SSO

杨波
前携程/拍拍贷技术总监,微服务技术专家
94讲 约900分钟4855
单独订阅¥199
2人成团¥89
4
登录 后留言

精选留言(3)

  • DDs moving castle
    多谢波波老师的讲解和推荐,fusionauth针对不同应用场景的登录认证流程我看了,真的很细致了,话说您是怎么找到了,我之前也看过fusionauth,但只找到了类似API文档的部分,厉害。

    我说的除了在Auth Service维护集中状态,还维护每个应用的登录状态,其实是从原来公司在单体应用时引入的开源CAS单点登录的思路来的,fusionauth的文章中和这篇的思路是一样的。
    标题:(RECOMMENDED) OAuth 2 authorization code grant using sessions
    https://fusionauth.io/articles/logins/spa/oauth-authorization-code-grant-sessions
    但这种方式的弊端是,SPA在登录时需要跳转到Auth Service的登录页面,由于公司的SPA登录页风格要统一,而且单页应用跳来跳去感觉体验不是很好,虽然硬着头皮做了,但想优化一下。
    不知道上面链接这种方式,波波老师什么看法??

    另外,我在看fusionauth的登录流程中发现,他们推荐一种将OAuth2的JWT格式的accessToken、引用类型的refreshToken放在cookie中返回给客户浏览器的做法,之后将JWT格式的accessToken当做登录凭证的做法,这种做法确实可以实现,从中可以获取到user信息,但我对于是否应该将OAuth的accessToken用于认证持否定态度,或者说最好不要。我从之前找到的一篇ORY的FAQ中看到了和我类似的观点:
    https://www.ory.sh/docs/next/hydra/faq#should-i-use-oauth2-tokens-for-authentication
    网上也有人使用accessToken认证的凭证,也有单独颁发认证凭证再在服务器端与accessToken关联的。请问波波老师对于使用OAuth的accessToken做登录认证是什么看法??

    作者回复: 第一个问题,我的建议是遵循业界规范或最佳实践流程,因为这些流程已经经过行业安全专家论证,也经过工业界踩坑才总结沉淀下来,你没必要重造轮子,如果你绕开,虽然能省事,但是难免留下风险漏洞。

    第二个问题,OAuth2只是一种代理授权(delegated authorization)协议,严格不是身份认证协议,fusionauth的推荐的做法,已经不是纯OAuth2协议,而是一种基于JWT的OIDC(openid connect)协议的变体,OIDC是在OAuth2的基础上增加身份认证层。官方的OIDC也不推荐access token同时用作身份认证,而是有单独的identity token(常用JWT)。fusionauth推荐的做法,可以认为是OIDC的一种变体,对于第一方应用(都是一个企业自己开发的应用),应该是可行的,如果涉及第三方,则需要考虑严格的OIDC协议。

    关于OAuth2和OIDC协议,建议读一下OAuth2 in Action这本书,对协议流程细节,背后原理有详细解释。http://product.dangdang.com/27851751.html

    2019-11-13
  • DDs moving castle
    波波老师,我们公司是做金融相关系统的,还是想考虑有状态的认证架构,而且不想只在Auth Service认证服务这里维护一个集中状态,因为这样如果Auth Service不可用,整个系统无论登录和校验登录状态都做不了了,会导致整个系统不可用,所以除了Auth Service认证服务维护登录状态,在通过Auth Service单点登录后的应用系统微服务也想维护个登录状态,感觉这样只会在单点登录时和Auth Service有交互,其它校验登录状态时在自己应用内部查找登录状态即可,请问如果在微服务架构中要实现这样的有状态架构,有什么项目或者案例可以参考吗??

    另外Auth Service考虑使用OAuth2实现,对于第一方应用想使用password模式,但感觉实现SSO有点麻烦,因为浏览器不会直接与OAuth2服务交互,无法种下OAuth2服务的cookie;
    对于第三方想使用授权码模式,但现在前后端分离的架构下,前端要实现授权码模式的多次重定向且登录页面与应用系统风格统一又比较难;
    请教波波老师有什么建议或者资料案例、架构设计推荐吗??
    多谢。

    作者回复: 我目前经历的两家公司,一家是旅游网携程,另外一家是拍拍贷金融,这两家都是基于令牌的集中状态式认证,集中状态好处是严格安全而且可以集中吊销。一般到这个体量的公司,Auth Service的高可用是必须要做到的。

    除了集中状态认证,目前业界比较流行的就是基于JWT的无状态认证(这个其实也有状态,只是状态被编码在JWT令牌里头)。你讲的既可以集中服务器认证,也可以在集中服务器不可用时,进行本地local认证方式,我暂时还没有经验。

    针对不同应用场景(传统Web/单页SPA/无线)的登录认证流程,这里有一个最全面的链接,里头的流程图很细致,供参考研究:
    https://fusionauth.io/articles/logins/types-of-logins-authentication-workflows


    2019-11-11
  • 海罗沃德
    用户如果登陆后操作了一段时间,JWT过期了但是用户并没有结束使用,要如何实现不需要重新登陆就能更新JWT令牌?

    作者回复: 可以简单搞个算法,如果JWT临近过期(比如过期前10分钟)客户还有不断操作,可以自动刷新令牌,自动延长一个周期。

    2019-09-19
收起评论
看过的人还看
Elasticsearch核心技术与实战

阮一鸣  eBay Pronto平台技术负责人

100讲 | 16921 人已学习

拼团 ¥99 原价 ¥129
从0开始学架构

李运华  资深技术专家

59讲 | 39235 人已学习

¥99
微服务架构实战160讲

杨波  拍拍贷研发总监、资深架构师、微服务技术专家

171讲 | 10069 人已学习

拼团 ¥199 原价 ¥299
MySQL实战45讲

林晓斌  网名丁奇,前阿里资深技术专家

48讲 | 44096 人已学习

拼团 ¥79 原价 ¥99