官方公众号企业安全新浪微博
FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。
FreeBuf+小程序
概述
小和尚念经有口无心，这个歇后语用在认证和授权这两个初学安全架构一定会犯的错误上是最合适不过的。认证和授权这两个名词大部分人是不陌生的，但是在工作中碰到具体的业务问题的时候就无法把这两个概念和具体的业务关联起来，本文我总结分享常见的错类型和带来的问题。
认证和授权合一
对于一直开发固定授权模式的系统，如我们在使用的这个博客系统，由于没有提供用户过多的配置项，我们登陆进来可以使用的业务逻辑已经定局。在感觉上只要登陆了就可以使用，没有授权的业务。我们平时接触的比较多的授权业务是腾讯的QQ空间，我们可以对不同的人开放不同的内容，至少相册的内容我们都会做一些配置。
会带来什么问题？
没有刻意区分认证和授权的架构通常会只有一个用户登录的模块，如果有授权也会在用户登录也就是认证的业务模块中实现，随着业务的发展这种设计会严重影响业务的灵活性，因为授权其实是根据业务变化而变化的，但是用户认证是一个固定的业务模式，甚至对于使用Oauth登录的系统都可以不用自己开发认证系统，使用微信的登录对用户的体验也许更好。
只有认证无授权
这种场景在IoT行业的容易出现。比如说一个设备可以同时被几个用户添加，通常为了业务的简单性，会选择设备只能被一个用户添加，那么碰到需要多个用户使用的业务场景，用户只能选择共用账号的方式来完成业务，但是共用账号是安全审计业务的大忌，一旦出现问题如何最终当时是谁在使用这个账号呢！
会带来什么问题？
为了适应多人使用的场景，会出现一个设备属于多个人的情况，在业务如何定义平等的所有权关系，以及不同账号直接的数据如何做隐私保护与安全隔离。
认证与授权强关联
这种问题通常会出现在以及初步掌握了认证和授权的使用场景的架构师手上。将认证和授权两个合并为一个原子操作来设计业务。
会带来什么问题？
1，架构上不必要的复杂度挑战，认证通常是中心化的技术实现，授权由于与具体业务对应，业务的分布式场景居多，中心化和分布式是两个对立的技术实现思路，要同时满足会极大的提高架构的复杂度，甚至最后都不能满足业务要求。
2，有的业务无法完成，有些业务只需要授权不需要认证，因为授权是可以传递的，云存储的应用场景，云存储的token就只给出了授权，具体谁来使用是颁发token的云租户自行完成认证和授权，对于云存储是不做认证工作的。当出现三元关系的时候，往往会有只要授权不要认证的场景。
总结
认证和授权是两个完全独立的概念，也是安全架构基本概念中的两个，我们在具体完成业务的安全架构设计的时候，明确定义两者的概念是安全业务架构的基础，切记切记！