使用oauth2时,用户和管理员是分开存的,不同的表,oauth2怎么配置

jack_jones 发布于 04/24 17:31
阅读 576
收藏 4

最近集成oauth2,原系统用户和管理员是分开存的,不同的表,不同的角色权限,不同的登陆入口

现在要集成进oauth2,登陆授权怎么处理?配置两个oauth2? 

加载中
0
e
edwin456
给你提供一个思路,oauth2里面也也客户端的认证,你可以不同的登录入库绑定不同的clientID,然后后台以此区分。
0
Joyzhou
Joyzhou

扩展grantType类型

0
前端大师傅
前端大师傅

没明白楼主的意思。你到要表达是:

1.授权。

你是类似于QQ,微信这样的大用户基数所有者,申请方是小网站,申请人希望通过你这边用户授权访问这个小网站,而不用注册。则你这边需要加一关系表,原来的表结构不变。下面是profile表结构:

用户编号(管理员或用户编号)  openid clientId

具体流程是这样的:

你的网站的名字叫A网,而且要有一个action接口。

那麽申请者的网站上会制作一个A网登录的入口。

这时有用户从申请者的网站上点击A网登录链接, 此时会调用你制作的Action,请传递你的clientId,returnUrl

这时用户看到的界面就是A网站登录页包含了申请者的ClientId,然后输入用户名密码以后,会找到其用户ID或管理员ID,然后把id和clientid到profile表里查询,如果存在这条记录直接返回即调用returnUrl跳转。如果不存在则多跳一个授权页面点确认后再returnUrl,再然后就是申请方根据返回的openId处理。

2.被授权。也就是楼主是一般的网站,这个网站的用户直接用QQ,微信这登录后就不用再在楼主的网站中注册。

流程正好反过来,这时需要在本地同样建一个表用来存储openId,即别人通过楼主的网站打开点击QQ第三方登录,这时是由楼主的网站向腾讯的接口发一条get请求,这时界面变成腾讯的登录界面,在这里输入完用户和密码后返回returnUrl返回,并返回访问令牌,以后楼主再用令牌accesstoken来访问许可的资源。

两种作为都需要增加关系表,至于用户和管理员是否分开的,这个并不重要。Oauth2的原理要弄清楚,这样才能做出好东西出来。

0
telami
telami

同有此疑惑,不知楼主弄明白了么,方便继续分享一下后续么

0
telami
telami

引用来自“前端大师傅”的评论

没明白楼主的意思。你到要表达是:

1.授权。

你是类似于QQ,微信这样的大用户基数所有者,申请方是小网站,申请人希望通过你这边用户授权访问这个小网站,而不用注册。则你这边需要加一关系表,原来的表结构不变。下面是profile表结构:

用户编号(管理员或用户编号)  openid clientId

具体流程是这样的:

你的网站的名字叫A网,而且要有一个action接口。

那麽申请者的网站上会制作一个A网登录的入口。

这时有用户从申请者的网站上点击A网登录链接, 此时会调用你制作的Action,请传递你的clientId,returnUrl

这时用户看到的界面就是A网站登录页包含了申请者的ClientId,然后输入用户名密码以后,会找到其用户ID或管理员ID,然后把id和clientid到profile表里查询,如果存在这条记录直接返回即调用returnUrl跳转。如果不存在则多跳一个授权页面点确认后再returnUrl,再然后就是申请方根据返回的openId处理。

2.被授权。也就是楼主是一般的网站,这个网站的用户直接用QQ,微信这登录后就不用再在楼主的网站中注册。

流程正好反过来,这时需要在本地同样建一个表用来存储openId,即别人通过楼主的网站打开点击QQ第三方登录,这时是由楼主的网站向腾讯的接口发一条get请求,这时界面变成腾讯的登录界面,在这里输入完用户和密码后返回returnUrl返回,并返回访问令牌,以后楼主再用令牌accesstoken来访问许可的资源。

两种作为都需要增加关系表,至于用户和管理员是否分开的,这个并不重要。Oauth2的原理要弄清楚,这样才能做出好东西出来。

Ouath2.0设计理念就是解决第三方系统的信任问题,你说的这种情况仅是oauth2解决的一个问题,类似微博、微信授权登录。在微服务架构流行以来,oauth2开始被用于内部认证和授权,楼主遇到的问题就是这个,他的系统现在还没到像微信那样,对外提供第三方登录的程度。
仅仅是对接内部的两个系统,所谓的原系统用户和管理员可以理解为淘宝买家,和淘宝后台的管理端,这是两类人,角色,权限相互独立,可以说没啥联系。
我也在想这个问题,现在有了大概思路,可以用scope来做,而不是grantType,比如 scope=front 、scope=admin,代表淘宝买家和淘宝后台管理人员,这样在实现loadByUsername()时,可以去查不同的表

jack_jones
jack_jones
“用scope来做”具体实现还是不了解
0
米饭军
米饭军

引用来自“telami”的评论

引用来自“前端大师傅”的评论

没明白楼主的意思。你到要表达是:

1.授权。

你是类似于QQ,微信这样的大用户基数所有者,申请方是小网站,申请人希望通过你这边用户授权访问这个小网站,而不用注册。则你这边需要加一关系表,原来的表结构不变。下面是profile表结构:

用户编号(管理员或用户编号)  openid clientId

具体流程是这样的:

你的网站的名字叫A网,而且要有一个action接口。

那麽申请者的网站上会制作一个A网登录的入口。

这时有用户从申请者的网站上点击A网登录链接, 此时会调用你制作的Action,请传递你的clientId,returnUrl

这时用户看到的界面就是A网站登录页包含了申请者的ClientId,然后输入用户名密码以后,会找到其用户ID或管理员ID,然后把id和clientid到profile表里查询,如果存在这条记录直接返回即调用returnUrl跳转。如果不存在则多跳一个授权页面点确认后再returnUrl,再然后就是申请方根据返回的openId处理。

2.被授权。也就是楼主是一般的网站,这个网站的用户直接用QQ,微信这登录后就不用再在楼主的网站中注册。

流程正好反过来,这时需要在本地同样建一个表用来存储openId,即别人通过楼主的网站打开点击QQ第三方登录,这时是由楼主的网站向腾讯的接口发一条get请求,这时界面变成腾讯的登录界面,在这里输入完用户和密码后返回returnUrl返回,并返回访问令牌,以后楼主再用令牌accesstoken来访问许可的资源。

两种作为都需要增加关系表,至于用户和管理员是否分开的,这个并不重要。Oauth2的原理要弄清楚,这样才能做出好东西出来。

Ouath2.0设计理念就是解决第三方系统的信任问题,你说的这种情况仅是oauth2解决的一个问题,类似微博、微信授权登录。在微服务架构流行以来,oauth2开始被用于内部认证和授权,楼主遇到的问题就是这个,他的系统现在还没到像微信那样,对外提供第三方登录的程度。
仅仅是对接内部的两个系统,所谓的原系统用户和管理员可以理解为淘宝买家,和淘宝后台的管理端,这是两类人,角色,权限相互独立,可以说没啥联系。
我也在想这个问题,现在有了大概思路,可以用scope来做,而不是grantType,比如 scope=front 、scope=admin,代表淘宝买家和淘宝后台管理人员,这样在实现loadByUsername()时,可以去查不同的表

思路是有了,就是不知道怎么去实现

返回顶部
顶部