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
     
  • 相关阅读:
    使用CustomValidate自定义验证控件
    C#中金额的大小写转换
    Andriod出错之Unable to build: the file dx.jar was not loaded from the SDK folder!
    VC 编写的打字练习
    机房工作笔记Ping只有单向通
    web服务协同学习笔记(1)
    Dll 学习3 将MDI子窗口封装在DLL中
    机房工作学习文件共享
    Andriod出错之Failed to find an AVD compatible with target 'Android 2.2'
    Andriod出错之wrapper was not properly loaded first
  • 原文地址:https://www.cnblogs.com/lvjianwei/p/12748964.html
Copyright © 2011-2022 走看看