OAuth2.0 ：
1.OAuth2.0是一个委托协议，它可以让那些控制资源的人允许【某个应用以代表他们】来访问他们控制的资源
这个应用从资源的所有者那里获得到授权（Authorization）and access token
然后就可以使用这个access token来访问资源
2.OAuth2.0 关于授权的协议
3.OpenID connect 身份认证协议（其实是在Oauth2.0上加了一层）
4.该协议中有三种角色：
1）Resource Owner
2) Client(OAuth2.0 称之为：被保护资源消费者)
3) Protected Resource(一般WebApi形式)
Authoriaztion Server：
授权服务器做中介流程图：
授权 Authorization Grant
授权 (authorization grant) 是一个代表着资源所有者权限的凭据, 它可以被客户端应用来获取access token. OAuth2里面定义了4种类型的授权, 分别是: auhtorization code, implicit, resource owner password credentials, client credentials. OAuth2还定义了一个扩展机制以便定义其它的授权类型.
授权(Authorization Grant)就是获取token的方法.
- Authorization Code
Authorization Code是使用授权服务器作为客户端和资源所有者的中介来获取的. 所以这里不是采用直接从资源所有者获得授权的方式, 而是采用授权服务器作为中介的方式. 在授权服务器把资源所有者送回到(重定向)客户端的时候带着这个临时的凭据: authorization code,它就代表着资源所有者委托给客户端应用的权限.
Authorization code在安全方面有一些重要的优点: 可以对客户端应用进行身份认证; access token是直接发送到客户端应用的, 不经过资源所有者的浏览器, 所以不会暴露access token给外界, 包括资源所有者.
- Implicit
Implicit, 隐式授权吧. 它是Authorization Code的一个简化版本, 它针对浏览器内的客户端应用(例如js, angular的应用)进行了优化. 在implicit流程里, 没有给客户端发送授权码(authorization code), 而是直接给它发送了access token. 之所以叫这种授权类型implicit, 是因为流程里并没有发行任何中间凭据.
在implicit流程里发行access token的时候, 授权服务器并没有对客户端应用进行身份认证. 某些情况下, 客户端的身份可以通过带着access token重定向回客户端的URI来验证. acces token可能会暴露给任何使用该浏览器的人或者应用.
Implicit授权确实可以提高浏览器内应用的响应性和效率, 毕竟它减少了来回往返的次数. 但是方便可能会带来风险, 建议如果可以的话尽量使用Authorization Code, 当然这个需要自己去权衡.
- Resource Owner Password Credentials
Resource Owner Password Credentials, 资源所有者密码凭据. 顾名思义, 可以直接使用密码凭据(用户名和密码)作为授权来获得access token. 只有当资源所有者和客户端之间高度信任的时候并且其它授权方式不可用的时候才可以使用这种授权方式.
这里资源所有者的凭据只应该用于一次请求并用于交换access token. 这种授权方式可以让客户端免于存储资源所有者的凭据(如果以后还需要使用的话), 通过交换一个长期有效的access token或refresh token都可以达到这种效果.
- Client Credentials
Client Credentials. 有时候, 资源或者叫资源服务器并不属于某个最终用户, 也就是没有资源所有者对该资源负责. 但是客户端应用肯定还是要访问这些资源, 这时候就只能使用Client Credentials这种授权方式了.
OAuth 2.0 的角色和组件
OAuth2的4个角色前面已经介绍过, 分别是: 资源所有者 Resource Owner, 客户端 Client, 被保护资源 Protected Resource, 和 授权服务器 Authorization Server.
OAuth2组件: Access Token, Refresh Token 和 Scope (范围).
Access Token: 有时候只被叫做token, 它是用来访问被保护资源的凭据. 它是一个字符串, 它代表了给客户颁发的授权, 也就是委托给客户的权限. OAuth2本身并没有对access token的格式或内容进行定义. 但是access token里面要描述出资源所有者授予的访问权限的范围和持续时间.
Access Token 通常对客户端应用是不透明的, 也就是说客户端无需去查看access token. 客户端的任务就是把它展示给被保护的资源. 其实access token在整个OAuth2系统里对任何角色都是不透明的, 授权服务器的任务只是发行token, 而被保护资源的任务是验证token. 但是它们都必须理解access token的构成, 并知道access token代表了什么. 而客户端对于access token应该是完全健忘的.
Scopes: OAuth2的scope表示被保护资源那里的一套权限. 在OAuth2里面, scope用区分大小写的字符串表示, 可以用空格作为分隔符来表示多个scope. 这些字符串由授权服务器来定义. 而scope字符串的格式和结构在OAuth2里并没有定义.
Scope对于限制客户端应用的访问权限有很重要的作用. 客户端应用可以请求一些scopes, 而授权服务器可以允许资源所有者授权或者拒绝特定的scopes. Scope还具有叠加性.
Refresh Token: Refresh Token是用来获得Access Token的凭据. 和acces token差不多, refresh token也是由授权服务器发行给客户端应用的, 客户端不知道也不关心refresh token里面有啥. 但与access token不同的是, refresh token不会被发送给被保护的资源. 客户端是用refresh token来请求新的access token (尤其是当现在的access token过期或者失效时), 但这个过程就不需要资源所有者的参与了. Refresh Token是可选的, 授权服务器会酌情发行refresh token, 如果需要的话, refresh token是在发行access token一同返回的.
此外refresh token还具备让客户端应用逐渐降低访问权限的能力.
通过refresh token来取得新的access token的流程如下:
就这些吧~后续还会补充
