OAuth 2.0 & OpenId Connect

OAuth 2.0 vs OpenId Connect

OAuth 2.0

• OAuth 2.0是一个委托协议, 它可以让那些控制资源的人允许某个应用代表他们来访问他们控制的资源, 注意是代表这些人, 而不是假冒或模仿这些人. 这个应用从资源的所有者那里获得到授权(Authorization)和access token, 随后就可以使用这个access token来访问资源. (这里提到的假冒或模仿就是指在客户端复制一份用户名和密码，从而获取相应的权限)。
• 是关于授权(Authorization)的, 客户端应用可以请求access token, 使用这个token就可以访问API资源了
• 让客户端应用可以代表资源所有者(通常是用户)来访问被保护的资源
  
  
  • 资源所有者(Resource Owner), 他拥有访问API资源的权限, 并且他还可以委派权限(delegate)给其他应用来访问API. 资源所有者通常是可以使用浏览器的人.
  • 被保护的资源(Protected Resource)就是资源所有者拥有权限去访问的组件, 它可以是很多种形式的, 但是web API的形式还是最常见的.
  • 客户端(Client)应用就是代表资源所有者访问被保护资源的一个软件. 注意它既不是指浏览器, 也不是指给你钱让你开发软件的人. 在OAuth2里面, 它是指被保护的API资源的消费者.

1. 授权服务器 (Authorization Server, AS)

• 是被受保护的资源所信任的, 它可以发行具有特定目的的安全凭据给客户端应用, 这个凭据叫做OAuth的 access token.

  
  
  
  
  
  

2. 授权种类

• Authorization Code
• mplicit
• Resource Owner Password Credentials, 直接使用密码凭据(用户名和密码)作为授权来获得access token. 只有当资源所有者和客户端之间高度信任的时候并且其它授权方式不可用的时候才可以使用这种授权方式
• Client Credentials, 有时候, 资源或者叫资源服务器并不属于某个最终用户, 也就是没有资源所有者对该资源负责. 但是客户端应用肯定还是要访问这些资源, 这时候就只能使用Client Credentials这种授权方式了.

3. 其它重要角色和组件

• 资源所有者 Resource Owner
• 客户端 Client
• 被保护资源 Protected Resource
• 授权服务器 Authorization Server
• Access Token, 它是用来访问被保护资源的凭据. 授权服务器只是发行token, 被保护资源验证token. 客户端对于access token应该是完全健忘的.
• Scopes, 表示被保护资源那里的一套权限, 具有叠加性.
• Refresh Token, 用来获得Access Token的凭据. 客户端是用refresh token来请求新的access token

4. 通过refresh token来取得新的access token的流程

   
   
   
   
   
   
5. 重要端点

• 授权端点(authorization endpoint)是用来和资源所有者交互的, 资源所有者在这里进行登录(身份认证), 然后通过该端点可以对客户端进行授权(authorization grant). 授权服务器首先要验证资源所有者的身份, 但是验证的方式并不在OAuth2的协议范围内.
• Token端点(token endpoint), 客户端通过向token端点展示它的授权(auhtorization grant)或refresh token来获取access token. 除了implicit之外所有的授权类型都需要使用该端点, 因为implicit的access token是直接发行的.

OpenId Connect

1. 身份认证与授权

   • OAuth 2.0 不是身份认证(Authentication)协议, OpenId Connect 可以进行身份认证(Authentication).
     一个比喻:
     授权: 生牛奶 (多用途原料).
     身份认证: 奶茶 (一个最终产品), 以牛奶为主原料.
   • OAuth 2.0, 生牛奶, 众多web安全架构的一种多用途的基本成分.
   • OIDC, 奶茶, 基于OAuth 2.0的身份认证协议, 添加了一些组件来提供身份认证的能力.

2. 更高级的协议, 扩展并替代了OAuth2

   • OpenID Connect是建立在OAuth2协议上的一个简单的身份标识层, 所以OpenID Connect兼容OAuth2.
   • 使用OpenID Connect, 客户端应用可以请求identity token, 它会和access token一同返回给客户端应用. 这个identity token就可以被用来登录客户端应用程序, 而客户端应用还可以使用access token来访问API资源.
   • UserInfo端点, (OAuth2定义了Authorization端点和Token端点)它允许客户端应用获取用户的额外信息.
   • 定义了不同类型的应用如何从身份识别提供商(IDP)安全的获取这些token

3. 与OAuth 2.0之间的角色映射关系
   身份提供商(Identity Provider, IdP)
   依赖方(Relying Party, RP, 可以理解为客户端)

   • OAuth2里可以分为两部分: 1.资源所有者/客户端应用, 2.授权服务器/被保护资源.
   • 身份认证协议里也是两大部分: 1.依赖方, 2.身份提供商.
   • 映射OAuth 2 ---- OIDC
     • 授权服务器/被保护资源 ---- 身份提供商进行映射
     • 资源所有者 ---- 最终用户

     • 客户端应用 ---- 依赖方(RP).

       
       
       

4. 抽象流程

   • 依赖发(RP)发送请求到OpenID提供商(OP, 也就是身份提供商).
   • OpenID提供商验证最终用户的身份, 并获得了用户委派的授权
   • OpenID提供商返回响应, 里面带着ID Token, 也通常带着Access Token.
   • 依赖方现在可以使用Access Token发送请求到用户信息的端点.

   • 用户信息端点返回用户的声明(claims, 相当于是用户的信息).

     
     
     

身份认证流程

1. Authorization Code Flow
   • 在Authorization Code 流程里, 一个授权码(Authorization Code)会被返回给客户端. 这个授权码可以被直接用来交换ID Token和Access Token. 该流程也可以在客户端使用授权码兑换Access Token之前对其身份认证. 但是该流程要求客户端的身份认证动作在后台使用client id和secret来获得tokens, 这样就不会把tokens暴露给浏览器或其它可访问浏览器的恶意应用了.
   • 要求客户端应用可以安全的在它和授权服务器之间维护客户端的secret, 也就是说只适合这样的客户端应用.
   • 它还适合于长时间的访问(通过refresh token).
   • 授权码来自于授权端点, 而所有的tokens都来自于Token端点.
   • Authorization Code流程的步骤如下:
     • 客户端准备身份认证请求, 请求里包含所需的参数
     • 客户端发送请求到授权服务器
     • 授权服务器对最终用户进行身份认证
     • 授权服务器获得最终用户的同意/授权
     • 授权服务器把最终用户发送回客户端, 同时带着授权码
     • 客户端使用授权码向Token端点请求一个响应
     • 客户端接收到响应, 响应的body里面包含着ID Token 和 Access Token
     • 客户端验证ID Token, 并获得用户的一些身份信息.
2. Implicit Flow(Angular)
   • Implicit Flow在请求token的时候不需要明确的客户端身份认证, 它使用重定向URI的方式来验证客户端的身份. 因为这一点, refresh token也就无法使用了, 这同样也不适合于长时间有效的access token.
   • 所有的tokens都来自于授权端点, 而Token端点并没有用到.
   • 该流程主要用于浏览器内的应用, Access Token和ID Token一同被直接返回给客户端. 因为这个原因, 这些tokens也会暴露于最终用户和可以访问该浏览器的其它应用了.
   • 它并不适合于长时间的访问.
   • Implicit流程的步骤如下:
     • 客户端准备身份认证请求, 请求里包含所需的参数
     • 客户端发送请求到授权服务器
     • 授权服务器对最终用户进行身份认证
     • 授权服务器获得最终用户的同意/授权
     • 授权服务器把最终用户发送回客户端, 同时带着ID Token. 如果也请求了Access Token的话, 那么Access Token也会一同返回.
     • 客户端验证ID Token, 并获得用户的一些身份信息.
3. Hybrid Flow
   • Hybrid Flow是前两者的混合, 在该流程里.
   • 有一些tokens和授权码来自于授权端点, 而另外一些tokens则来自于Token端点.
   • 该流程允许客户端立即使用ID Token, 并且只需要一次往返即可获得授权码.
   • 这种流程也要求客户端应用可以安全的维护secret.
   • 它也适合于长时间的访问.
     Hybrid流程的步骤如下:
     • 客户端准备身份认证请求, 请求里包含所需的参数
     • 客户端发送请求到授权服务器
     • 授权服务器对最终用户进行身份认证
     • 授权服务器获得最终用户的同意/授权
     • 授权服务器把最终用户发送回客户端, 同时带着授权码, 根据响应类型的不同,
     • 也可能还带着一个或者多个其它的参数.
     • 客户端使用授权码向Token端点请求一个响应
     • 客户端接收到响应, 响应的body里面包含着ID Token 和 Access Token
     • 客户端验证ID Token, 并获得用户的一些身份信息.

4. 比较

   
   
   

   vs
   
   
   

   返回类型

Hybrid Flow

根据response_type的不同, 分为:

• response_type=code id_token
• response_type=code token
• response_type=code id_token token
  注意:为了表明是OpenID Connect协议的请求, scope参数里必须包含openid

1. response_type=code id_token
   
   
2. response_type=code token
   
   
3. response_type=code id_token token