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:
An OAuth client initiates a request with an authorization server and receives an access token.
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
OAuth 2.0 (3LO) (also known as "three-legged OAuth" or "authorization code grants") apps. OAuth 2.0 (3LO) allows external applications and services to access Atlassian product APIs on a user's behalf. OAuth 2.0 (3LO) apps are created and managed in the developer console.
OAuth 2.0 (3LO) involves three parties:
An Atlassian site (resource)
A user (resource owner)
An external application/service (client).
For example, a Jira or Confluence site (resource), an Atlassian user (resource owner), and Gmail (client). Underlying the authorization interactions between these three parties is an authorization server.
references
https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/
No comments:
Post a Comment