谈谈自己对于Auth2.0的见解

  Auth的原理网上有很多,我这里就不在赘述了。

  这里有张时序图我个人觉得是比较合理而且直观的,(感谢这篇博文:http://justcoding.iteye.com/blog/1950270)

  参照这个流程,模拟了下部分代码,当然是尽可能的以简单的形式去表达下自己的见解

  模拟了配置文件去掉数据库处理的部分

config.php 定义了公司及对应的操作用户的权限

<?php
return array(
    ‘app‘=>array(
        ‘a1‘=>array(
        ‘accesskey‘=>‘123456‘,//凭证
        ‘type‘=>0,//聚合这里规定type对应的请求权限
        ‘appname‘=>‘gavinjun‘,
        ),
    ),
    ‘type‘=>array(
        array(
            ‘获取用户的信息‘,‘获取用户的金钱‘,
        ),
    ),
);

user_config.php 用户表的模拟

<?php
return array(
    ‘admin‘=>‘123456‘,
);
<?php 

//权限2.0的主程
class Auto{
    private $vession=2.0;
    private $notic=null;
    public function __construct(){
        $notic     =     require ‘config.php‘;
        $this->notic = $notic;
    }
    //校验商户
    public function check($_param=array()){
        if(empty($_param)){
            return false;
        }
        //获取传过来的accesskey appid
        $appid = !empty($_param[‘appid‘])?$_param[‘appid‘]:0;
        $accesskey=!empty($_param[‘accesskey‘])?$_param[‘accesskey‘]:‘‘;
        if(!$appid||!$accesskey)
            return false;
        //校验开始
        $notic  = $this->notic;
        return $notic[‘app‘][$appid]?$notic[‘app‘][$appid][‘accesskey‘]==$accesskey:false;
    }
    //用户发起登录请求
    public function getLoginCallBack($_param){
        if($this->check($_param)){
            //校验通过返回临时的token 以下都是不安全的方式只是模拟auto的流程
            //这里可以用加密 请求时间|请求完成后跳转地址|用户的md5(accesskey)
            return time().‘|‘.$_param[‘redirect‘].‘|‘.md5($_param[‘accesskey‘]).‘|‘.$_param[‘appid‘];
        }else{
            echo ‘商户未注册‘;
            return false;
        }
    }

    //用户输入完用户名和密码之后
    public function inLogin($name,$pwd){
        $user = require("user_config.php");
        return $user[$name]?$user[$name]==$pwd:false;
    }
    //用户登录完成后带着token值来请求我们的令牌
    public function getAceess($_param){
        $token = $_param[‘access_token‘];
        if(!$token)
            return false;
        list($time,$redirect,$authkey,$appid) = explode(‘|‘,$token);
        //请求$appid 获取他的accesskey
        $notic  = $this->notic;
        $accesskey = $notic[‘app‘][$appid][‘accesskey‘];
        if(time()>$time+5*60){
            //超过5分钟才请求默认失败
            return false;
        }
        if(md5($accesskey)!=$authkey){
            //链接不安全
            return false;
        }
        //返回正式的key
        //这个key可以保存在数据库中设置这个key的失效时间 //我这里随便固定了他的accesskey
        //给跳转的页面发送一个key 用post的应该,不过模拟就算了
        $access = ‘success‘;
        return $redirect.‘?access=‘.$access;
    }

    public function doSomeByaccess($access){
        //和数据库中做比对 这里不写了,就全部默认成功
        if($access){
                $appid = ‘a1‘;
        }
        $notic  = $this->notic;
        $type   = $notic[‘app‘][$appid][‘type‘];
        foreach($notic[‘type‘][$type] as $v){
            echo ‘用户权限:‘.$v.‘<br>‘;
        }

    }
}

这里是模拟下这段程序的流程

<?php
//模拟流程
require ‘auth2.php‘;
$auth2= new Auto();

//step 1: 用户点击平台上的登录按钮
//该商户的信息 appid=a1,accesskey=123456
$step1=$auth2->getLoginCallBack(array(‘appid‘=>‘a1‘,‘accesskey‘=>‘123456‘,‘redirect‘=>‘http://www.baidu.com‘));
//系统内部跳转到登录界面拿到临时token 让用户去登录授权
$access_token = $step1;
/**系统内部的处理流程***/
//系统跳到登录地址?access_token=$step1 用户输入用户名和密码
//模拟用户授权
if($auth2->inLogin(‘admin‘,‘123456‘)){
    //用户同意登录返回了一个令牌$access_token是用户登录请求的时候带上的
    $arr[‘access_token‘]=$access_token;
    $url = $auth2->getAceess($arr);
    //这个url会发送给平台,平台拿到这个 令牌可以去访问用户信息
    echo $url;
}
/****系统内部处理结束跳转到用户平台地址,发送post信息****/
//假设平台接到这个信息他保存下来了这个accesskey,去读取一遍用户的信息
$url = parse_url($url);
list($access,$accesskey)=explode(‘=‘,$url[‘query‘]);
$auth2->doSomeByaccess($accesskey);

结果:

时间: 2024-10-24 16:25:12

谈谈自己对于Auth2.0的见解的相关文章

谈谈基于OAuth 2.0的第三方认证 [下篇]

从安全的角度来讲,<中篇> 介绍的Implicit类型的Authorization Grant存在这样的两个问题:其一,授权服务器没有对客户端应用进行认证,因为获取Access Token的请求只提供了客户端应用的ClientID而没有提供其ClientSecret:其二,Access Token是授权服务器单独颁发给客户端应用的,照理说对于其他人(包括拥有被访问资源的授权者)应该是不可见的.Authorization Code类型的Authorization Grant很好地解决了这两个问题

徒手构建auth2.0验证平台(以qq为例)

auth2.0的功用:首先说一下为什么需要auth2.0,auth2.0是开放平台互联协议,可以这样理解,A是行业中的小生,两手空空:B是行业大佬,财大气粗,有一大批人(用户群):这个时候A需要借用B的用户群信息来构建自己的项目中的某项功能,但是出于资源的保护和各方面原因,B不相信A,不会让A接入自己的信任体系里面,A是无法直接获取B那边用户群的用户名和密码的,同时A又想借用B拥有的用户群信息来完善自己项目中的某些功能,这个时候就需要auth2.0来做中介,通过一些业务流程来实现A在没有B的用户

谈谈localhost与127.0.0.1

localhost意为本地主机,指这台计算机,是给回路网络接口的标准主机名,对应的IP地址为127.0.0.1,可访问本地服务器的web项目(http://localhost). 那么它们有什么区别呢? localhost不通过网卡传输,不受防火墙和网卡限制:而127.0.0.1则依赖于网卡,会受到防火墙和网卡的限制. localhost访问时带着本机当前用户的权限:而用IP访问时,是通过网络再去访问主机,涉及到网络用户权限. 因为用localhost访问时不会解析成IP,也就不会占用网络资源,

谈谈基于OAuth 2.0的第三方认证 [上篇]

对于目前大部分Web应用来说,用户认证基本上都由应用自身来完成.具体来说,Web应用利用自身存储的用户凭证(基本上是用户名/密码)与用户提供的凭证进行比较进而确认其真实身份.但是这种由Web应用全权负责的认证方式会带来如下两个问题: 对于用户来说,他们不得不针对不同的访问Web应用提供不同的用户凭证.如果这些凭证具有完全不同的密码,我们没有多少人能够记得住,所以对于大部分整天畅游Internet的网友来说,我想他们在不同的网站注册的帐号都会采用相同的密码.密码的共享必然带来安全隐患,因为我们不能

谈谈基于OAuth 2.0的第三方认证 [中篇]

虽然我们在<上篇>分别讨论了4种预定义的Authorization Grant类型以及它们各自的适用场景的获取Access Token的方式,我想很多之前没有接触过OAuth 2.0的读者朋友们依然会有“不值所云” 之感,所以在介绍的内容中,我们将采用实例演示的方式对Implicit和Authorization Code这两种常用的Authorization Grant作深入介绍.本章着重介绍Implicit Authorization Grant. Implicit Authorizatio

微信Auth2.0授权的时候出现两次回调

在获取用户OpenID的时候 $url="https://open.weixin.qq.com/connect/oauth2/authorize?appid=".WX_APPID."&redirect_uri=http://".SERVERNAME.urlencode($url)."&response_type=code&scope=snsapi_base&state=1#wechat_redirect"; 这样会

(更新中)谈谈个人对java并发编程中(管程模型,死锁,线程生命周期等问题) 见解

之前未曾接触过多线程编程  公司的项目开始用到多线程,所以自己谈谈个人对于并发编程的见解. 并发编程会导致线程不安全,常说的线程不安全指的是  多个线程操作一个共享数据,导致线程之间的读取到的数据不一致. 并发编程导致线程不安全的根源   可见性  原子性    有序性 1 .可见性     cpu缓存导致. 一般cpu缓存中进行操作之后再将数据写到内存,在多核服务器中  每个线程都会分配一个cpu  都会在各自的cpu中进行处理再将数据统一写到内存中.每个cpu缓存中的数据都是不可见的.导致最

Using OAuth 2.0 for Web Server Applications, verifying a user&#39;s Android in-app subscription

在写本文之前先说些题外话. 前段时间游戏急于在GoolePlay上线,明知道如果不加Auth2.0的校验是不安全的还是暂时略过了这一步,果然没几天就发现后台记录与玩家实际付费不太一致,怀疑有玩家盗刷游戏元宝等,并且真实的走过了GooglePlay的所有支付流程完成道具兑换,时间一长严重性可想而知.经过查阅大量google官方文档后把代码补上,并在这里记录下OAuth 2.0 的使用,Google提供了OAuth2.0的好几种使用用途,每种使用方法都有些不同,具体可以看下这篇博客.在这里只写OAu

【实例图文详解】OAuth 2.0 for Web Server Applications

原文链接:http://blog.csdn.net/hjun01/article/details/42032841        OAuth 2.0 for Web Server Applications, verifying a user's Android in-app subscription 在写本文之前先说些题外话. 前段时间游戏急于在GoolePlay上线,明知道如果不加Auth2.0的校验是不安全的还是暂时略过了这一步,果然没几天就发现后台记录与玩家实际付费不太一致,怀疑有玩家盗刷