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
     
  • 相关阅读:
    python 进程
    python 网络编程
    Tensorflow学习教程------参数保存和提取重利用
    Tensorflow学习教程------利用卷积神经网络对mnist数据集进行分类_利用训练好的模型进行分类
    Tensorflow学习教程------利用卷积神经网络对mnist数据集进行分类_训练模型
    Tensorflow学习教程------tensorboard网络运行和可视化
    Tensorflow学习教程------过拟合
    Spring的@Value注解为静态变量赋值
    Linux使用scp远程拷贝使用ssh免密登录
    Mysql升级5.7.10后GROUP BY语句出错解决方法
  • 原文地址:https://www.cnblogs.com/lvjianwei/p/12748964.html
Copyright © 2011-2022 走看看