微服务实践分享(7)认证受权中心

认证机制：

OAuth (Facebook, Twitter, Google...) - SAML - CAS - OpenID Connect - HTTP - OpenID - Google App Engine
LDAP - SQL - JWT - MongoDB - CouchDB - IP address - Kerberos (SPNEGO) - REST API

1.四种方案

　　单点登陆（SSO）

这种方案意味着每一个面向用户的服务都必须与认证服务交互，这会产生大量很是琐碎的网络流量和重复的工做，当动辄数十个微应用时，这种方案的弊端会更加明显。

　　分布式 Session 方案

分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中，且一般由用户会话做为 key 来实现的简单分布式哈希映射。当用户访问微服务时，用户数据能够从共享存储中获取。在某些场景下，这种方案很不错，用户登陆状态是不透明的。同时也是一个高可用且可扩展的解决方案。这种方案的缺点在于共享存储须要必定保护机制，所以须要经过安全连接来访问，这时解决方案的实现就一般具备至关高的复杂性了。

　　客户端 Token 方案

令牌在客户端生成，由身份验证服务进行签名，而且必须包含足够的信息，以即可以在全部微服务中创建用户身份。令牌会附加到每一个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种状况的方法可使用短时间令牌和频繁检查认证服务等。对于客户端令牌的编码方案，Borsos 更喜欢使用 JSON Web Tokens（JWT），它足够简单且库支持程度也比较好。

　　客户端 Token 与 API 网关结合

 

2.开源

 

3.业界