ASP .NET Core Web Api + AngularOAuth2

OAuth 2.0 & OpenId Connect

2018-10-24  本文已影响445人  xtddw

OAuth 2.0 vs OpenId Connect

OAuth 2.0

  1. 授权服务器 (Authorization Server, AS)
  1. 授权种类
  1. 其它重要角色和组件
  1. 通过refresh token来取得新的access token的流程



  2. 重要端点

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的不同, 分为:

  1. response_type=code id_token
  2. response_type=code token
  3. response_type=code id_token token
上一篇 下一篇

猜你喜欢

热点阅读