最近集成oauth2,原系统用户和管理员是分开存的,不同的表,不同的角色权限,不同的登陆入口
现在要集成进oauth2,登陆授权怎么处理?配置两个oauth2?
扩展grantType类型
没明白楼主的意思。你到要表达是:
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()时,可以去查不同的表
思路是有了,就是不知道怎么去实现
扩展grantType类型
没明白楼主的意思。你到要表达是:
1.授权。
你是类似于QQ,微信这样的大用户基数所有者,申请方是小网站,申请人希望通过你这边用户授权访问这个小网站,而不用注册。则你这边需要加一关系表,原来的表结构不变。下面是profile表结构:
具体流程是这样的:
你的网站的名字叫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的原理要弄清楚,这样才能做出好东西出来。
同有此疑惑,不知楼主弄明白了么,方便继续分享一下后续么
引用来自“前端大师傅”的评论
没明白楼主的意思。你到要表达是:
1.授权。
你是类似于QQ,微信这样的大用户基数所有者,申请方是小网站,申请人希望通过你这边用户授权访问这个小网站,而不用注册。则你这边需要加一关系表,原来的表结构不变。下面是profile表结构:
具体流程是这样的:
你的网站的名字叫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()时,可以去查不同的表
引用来自“telami”的评论
引用来自“前端大师傅”的评论
没明白楼主的意思。你到要表达是:
1.授权。
你是类似于QQ,微信这样的大用户基数所有者,申请方是小网站,申请人希望通过你这边用户授权访问这个小网站,而不用注册。则你这边需要加一关系表,原来的表结构不变。下面是profile表结构:
具体流程是这样的:
你的网站的名字叫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()时,可以去查不同的表
思路是有了,就是不知道怎么去实现