zoukankan      html  css  js  c++  java
  • two legged and three legged OAuth flow

    Two-legged OAuth processing involves three parties: OAuth client, authorization server, and resource server. The OAuth client can be either the resource owner or the trusted entity that knows about the credentials of the resource owner. In other words, two-legged OAuth processing does not involve additional resource owner interaction.

    Two-legged OAuth processing requires a grant type of resource owner password credential or client credentials.

    The typical flow for two-legged OAuth processing involves the following activities:

    1. An OAuth client initiates a request with an authorization server and receives an access token.
    2. The OAuth client uses the access token to access protected resources on the resource server.
    The following figure shows the two-legged OAuth processing flow.Figure 1. Two-legged OAuth processing flow
     
    Illustration showing previously described flow.
     
     

    Three-legged OAuth processing involves four parties: resource owner, OAuth client, authorization server, and resource server. In other words, three-legged OAuth is a traditional pattern with resource owner interaction. In this case, a resource owner wants to give a client access to a server without sharing credentials.

    Three-legged OAuth processing requires a grant type of authorization code.

    In the three-legged OAuth flow, the client ID is a unique identifier for an OAuth client. The OAuth client uses its client ID and client secret or its client ID and client certificate to provide identity and optionally the credentials. In the specification, the client ID is client_id and client secret is client_secret. When you define an OAuth client profile for DataPower® integration, the configured name is the client ID.

    The typical flow for three-legged OAuth processing involves the following activities:

    1. A user, as the resource owner, initiates a request to the OAuth client.
    2. The OAuth client sends the resource owner a redirection to the authorization server.
    3. The resource owner authenticates and optionally authorizes with the authorization server.
    4. The authorization server presents a form to the resource owner to grant access.
    5. The resource owner submits the form to allow or to deny access.
    6. Based on the response from the resource owner, the following processing occurs:
      • If the resource owner allows access, the authorization server sends the OAuth client a redirection with the authorization grant code or the access token.
      • If the resource owner denies access, the request is redirected to the OAuth client but no grant is provided.
    7. The OAuth client sends the following information to the token endpoint (authorization server).
      • Authorization grant code
      • Client ID
      • Client secret or client certificate
    8. If verified, the authorization server sends the OAuth client an access token and optionally a refresh token.
    9. The OAuth client sends the access token to the resource server to request protected resources.
    10. If the access token is valid for the requested resources, the OAuth client can access the protected resources.
    The following figure shows the three-legged OAuth processing flow.Figure 1. Three-legged OAuth processing flow
     
  • 相关阅读:
    自动登录跳板机->开发机
    关于写代码的一下规范
    vscode 配置 GOPATH
    thinkphp6.0 nginx 配置
    vue-cli 3.x 构建项目,webpack没有了?
    Laravel6.0 使用 Jwt-auth 实现多用户接口认证
    怎么在 localhost 下访问多个 Laravel 项目,通过一个IP访问多个项目(不仅仅是改变端口哦)
    laravel 5.8 实现消息推送
    vs code 设置 保存自动格式化vue代码
    项目开发规范(编码规范、命名规范、安全规范、前端优化、源码提交规范、代码维护规范、产品发布规范)
  • 原文地址:https://www.cnblogs.com/lvjianwei/p/12748964.html
Copyright © 2011-2022 走看看