理解OAuth2.0：安全授权协议详解

oauth2.0

需积分: 10 48 浏览量更新于2024-07-17 收藏 369KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"OAuth2.0.pdf" OAuth2.0 是一个广泛采用的开放标准，用于授权第三方应用在用户许可的情况下访问其存储在其他服务提供商上的个人信息。这个标准由 Internet Engineering Task Force (IETF) 发布，并由 R. Fielding 和 J. Reschke 等人编辑。OAuth2.0 的设计目标是简化授权流程，提高安全性，并提供更加灵活的权限管理。 OAuth2.0 的主要组成部分包括四个角色：资源所有者（Resource Owner）、客户端（Client）、资源服务器（Resource Server）和授权服务器（Authorization Server）。资源所有者是拥有需要保护资源的用户；客户端是需要访问这些资源的应用；资源服务器是存储和管理这些资源的系统；授权服务器负责验证资源所有者的身份并颁发访问令牌（Access Token）给客户端。 OAuth2.0 的授权流程通常分为以下几个步骤： 1. 用户打开第三方应用并请求访问其在服务提供者上的信息。 2. 第三方应用引导用户跳转到授权服务器进行身份验证。 3. 用户登录并授权应用访问特定的资源。 4. 授权服务器返回授权码（Authorization Code）给第三方应用。 5. 第三方应用通过授权码向授权服务器请求访问令牌。 6. 授权服务器验证授权码后，向客户端发放访问令牌。 7. 客户端使用访问令牌向资源服务器请求访问资源。 8. 资源服务器验证访问令牌有效后，提供所请求的资源。 OAuth2.0 提供了几种不同的授权类型（Grant Types），如授权码（Authorization Code Grant）、隐式（Implicit Grant）、资源主密码凭证（Resource Owner Password Credentials Grant）和客户端凭证（Client Credentials Grant），以适应不同场景的安全性和便捷性需求。其中，授权码模式是最安全的，适用于有服务器后台的客户端；隐式模式适用于无服务器后台的浏览器应用，但令牌会直接暴露给用户，因此安全风险较高；资源主密码凭证模式适合于用户信任的客户端；客户端凭证模式则用于客户端直接获取服务的身份验证，适用于服务器之间的通信。 OAuth2.0 的一个重要特性是刷新令牌（Refresh Token），它允许客户端在访问令牌过期后获取新的访问令牌，而无需用户再次授权。这提高了用户体验并减少了用户的参与度。在 HTTP/1.1 协议中，OAuth2.0 的实现通常涉及到在请求头中使用 Authorization 字段，携带访问令牌或者在 URL 查询参数中携带隐式授权模式下的访问令牌。同时，OAuth2.0 还与其他标准如 JSON Web Tokens (JWT) 结合，用于创建自包含、可验证的访问令牌，进一步增强了安全性。 OAuth2.0 为互联网应用提供了安全、灵活的用户授权机制，广泛应用于社交网络、云存储、在线支付等多个领域。它通过分离认证和授权，使得第三方应用可以访问用户数据，而无需获取用户的敏感信息，极大地推动了开放平台的发展。

资源详情

资源推荐

RFC 7231

HTTP/1.1 Semantics and Content June 2014

If Content-Location is included in a 2xx (Successful) response

message and its value refers (after conversion to absolute form) to a

URI that is the same as the effective request URI, then the recipient

MAY consider the payload to be a current representation of that

resource at the time indicated by the message origination date. For

a GET (

Section 4.3.1) or HEAD (Section 4.3.2) request, this is the

same as the default semantics when no Content-Location is provided by

the server. For a state-changing request like PUT (

Section 4.3.4) or

POST (

Section 4.3.3), it implies that the server’s response contains

the new representation of that resource, thereby distinguishing it

from representations that might only report about the action (e.g.,

"It worked!"). This allows authoring applications to update their

local copies without the need for a subsequent GET request.

If Content-Location is included in a 2xx (Successful) response

message and its field-value refers to a URI that differs from the

effective request URI, then the origin server claims that the URI is

an identifier for a different resource corresponding to the enclosed

representation. Such a claim can only be trusted if both identifiers

share the same resource owner, which cannot be programmatically

determined via HTTP.

o For a response to a GET or HEAD request, this is an indication

that the effective request URI refers to a resource that is

subject to content negotiation and the Content-Location

field-value is a more specific identifier for the selected

representation.

o For a 201 (Created) response to a state-changing method, a

Content-Location field-value that is identical to the Location

field-value indicates that this payload is a current

representation of the newly created resource.

o Otherwise, such a Content-Location indicates that this payload is

a representation reporting on the requested action’s status and

that the same report is available (for future access with GET) at

the given URI. For example, a purchase transaction made via a

POST request might include a receipt document as the payload of

the 200 (OK) response; the Content-Location field-value provides

an identifier for retrieving a copy of that same receipt in the

future.

A user agent that sends Content-Location in a request message is

stating that its value refers to where the user agent originally

obtained the content of the enclosed representation (prior to any

modifications made by that user agent). In other words, the user

agent is providing a back link to the source of the original

representation.

Fielding & Reschke Standards Track [Page 16]

RFC 7231

HTTP/1.1 Semantics and Content June 2014

An origin server that receives a Content-Location field in a request

message MUST treat the information as transitory request context

rather than as metadata to be saved verbatim as part of the

representation. An origin server MAY use that context to guide in

processing the request or to save it for other uses, such as within

source links or versioning metadata. However, an origin server MUST

NOT use such context information to alter the request semantics.

For example, if a client makes a PUT request on a negotiated resource

and the origin server accepts that PUT (without redirection), then

the new state of that resource is expected to be consistent with the

one representation supplied in that PUT; the Content-Location cannot

be used as a form of reverse content selection identifier to update

only one of the negotiated representations. If the user agent had

wanted the latter semantics, it would have applied the PUT directly

to the Content-Location URI.

3.2. Representation Data

The representation data associated with an HTTP message is either

provided as the payload body of the message or referred to by the

message semantics and the effective request URI. The representation

data is in a format and encoding defined by the representation

metadata header fields.

The data type of the representation data is determined via the header

fields Content-Type and Content-Encoding. These define a two-layer,

ordered encoding model:

representation-data := Content-Encoding( Content-Type( bits ) )

3.3. Payload Semantics

Some HTTP messages transfer a complete or partial representation as

the message "payload". In some cases, a payload might contain only

the associated representation’s header fields (e.g., responses to

HEAD) or only some part(s) of the representation data (e.g., the 206

(Partial Content) status code).

The purpose of a payload in a request is defined by the method

semantics. For example, a representation in the payload of a PUT

request (Section 4.3.4) represents the desired state of the target

resource if the request is successfully applied, whereas a

representation in the payload of a POST request (

Section 4.3.3)

represents information to be processed by the target resource.

Fielding & Reschke Standards Track [Page 17]

RFC 7231

HTTP/1.1 Semantics and Content June 2014

In a response, the payload’s purpose is defined by both the request

method and the response status code. For example, the payload of a

200 (OK) response to GET (Section 4.3.1) represents the current state

of the target resource, as observed at the time of the message

origination date (

Section 7.1.1.2), whereas the payload of the same

status code in a response to POST might represent either the

processing result or the new state of the target resource after

applying the processing. Response messages with an error status code

usually contain a payload that represents the error condition, such

that it describes the error state and what next steps are suggested

for resolving it.

Header fields that specifically describe the payload, rather than the

associated representation, are referred to as "payload header

fields". Payload header fields are defined in other parts of this

specification, due to their impact on message parsing.

+-------------------+----------------------------+

| Header Field Name | Defined in... |

+-------------------+----------------------------+

| Content-Length |

Section 3.3.2 of [RFC7230] |

| Content-Range |

Section 4.2 of [RFC7233] |

| Trailer |

Section 4.4 of [RFC7230] |

| Transfer-Encoding |

Section 3.3.1 of [RFC7230] |

+-------------------+----------------------------+

3.4. Content Negotiation

When responses convey payload information, whether indicating a

success or an error, the origin server often has different ways of

representing that information; for example, in different formats,

languages, or encodings. Likewise, different users or user agents

might have differing capabilities, characteristics, or preferences

that could influence which representation, among those available,

would be best to deliver. For this reason, HTTP provides mechanisms

for content negotiation.

This specification defines two patterns of content negotiation that

can be made visible within the protocol: "proactive", where the

server selects the representation based upon the user agent’s stated

preferences, and "reactive" negotiation, where the server provides a

list of representations for the user agent to choose from. Other

patterns of content negotiation include "conditional content", where

the representation consists of multiple parts that are selectively

rendered based on user agent parameters, "active content", where the

representation contains a script that makes additional (more

specific) requests based on the user agent characteristics, and

"Transparent Content Negotiation" ([

RFC2295]), where content

Fielding & Reschke Standards Track [Page 18]

RFC 7231

HTTP/1.1 Semantics and Content June 2014

selection is performed by an intermediary. These patterns are not

mutually exclusive, and each has trade-offs in applicability and

practicality.

Note that, in all cases, HTTP is not aware of the resource semantics.

The consistency with which an origin server responds to requests,

over time and over the varying dimensions of content negotiation, and

thus the "sameness" of a resource’s observed representations over

time, is determined entirely by whatever entity or algorithm selects

or generates those responses. HTTP pays no attention to the man

behind the curtain.

3.4.1. Proactive Negotiation

When content negotiation preferences are sent by the user agent in a

request to encourage an algorithm located at the server to select the

preferred representation, it is called proactive negotiation (a.k.a.,

server-driven negotiation). Selection is based on the available

representations for a response (the dimensions over which it might

vary, such as language, content-coding, etc.) compared to various

information supplied in the request, including both the explicit

negotiation fields of

Section 5.3 and implicit characteristics, such

as the client’s network address or parts of the User-Agent field.

Proactive negotiation is advantageous when the algorithm for

selecting from among the available representations is difficult to

describe to a user agent, or when the server desires to send its

"best guess" to the user agent along with the first response (hoping

to avoid the round trip delay of a subsequent request if the "best

guess" is good enough for the user). In order to improve the

server’s guess, a user agent MAY send request header fields that

describe its preferences.

Proactive negotiation has serious disadvantages:

o It is impossible for the server to accurately determine what might

be "best" for any given user, since that would require complete

knowledge of both the capabilities of the user agent and the

intended use for the response (e.g., does the user want to view it

on screen or print it on paper?);

o Having the user agent describe its capabilities in every request

can be both very inefficient (given that only a small percentage

of responses have multiple representations) and a potential risk

to the user’s privacy;

o It complicates the implementation of an origin server and the

algorithms for generating responses to a request; and,

Fielding & Reschke Standards Track [Page 19]

RFC 7231

HTTP/1.1 Semantics and Content June 2014

o It limits the reusability of responses for shared caching.

A user agent cannot rely on proactive negotiation preferences being

consistently honored, since the origin server might not implement

proactive negotiation for the requested resource or might decide that

sending a response that doesn’t conform to the user agent’s

preferences is better than sending a 406 (Not Acceptable) response.

A Vary header field (

Section 7.1.4) is often sent in a response

subject to proactive negotiation to indicate what parts of the

request information were used in the selection algorithm.

3.4.2. Reactive Negotiation

With reactive negotiation (a.k.a., agent-driven negotiation),

selection of the best response representation (regardless of the

status code) is performed by the user agent after receiving an

initial response from the origin server that contains a list of

resources for alternative representations. If the user agent is not

satisfied by the initial response representation, it can perform a

GET request on one or more of the alternative resources, selected

based on metadata included in the list, to obtain a different form of

representation for that response. Selection of alternatives might be

performed automatically by the user agent or manually by the user

selecting from a generated (possibly hypertext) menu.

Note that the above refers to representations of the response, in

general, not representations of the resource. The alternative

representations are only considered representations of the target

resource if the response in which those alternatives are provided has

the semantics of being a representation of the target resource (e.g.,

a 200 (OK) response to a GET request) or has the semantics of

providing links to alternative representations for the target

resource (e.g., a 300 (Multiple Choices) response to a GET request).

A server might choose not to send an initial representation, other

than the list of alternatives, and thereby indicate that reactive

negotiation by the user agent is preferred. For example, the

alternatives listed in responses with the 300 (Multiple Choices) and

406 (Not Acceptable) status codes include information about the

available representations so that the user or user agent can react by

making a selection.

Reactive negotiation is advantageous when the response would vary

over commonly used dimensions (such as type, language, or encoding),

when the origin server is unable to determine a user agent’s

capabilities from examining the request, and generally when public

caches are used to distribute server load and reduce network usage.

Fielding & Reschke Standards Track [Page 20]

剩余100页未读，继续阅读

zmy012

粉丝: 1
资源: 3

理解OAuth2.0：安全授权协议详解

Master OAuth 2.0

Mastering Identity and Access Management with Microsoft Azure 无水印pdf

Mastering OAuth 2.0.pdf

oauth-2.0.jar

java实现oauth2.0_Java的oauth2.0 服务端与客户端的实现

oauth2.0的面试题

springSecurity oauth2.0怎么学习

springboot oauth2.0 客户端和服务端

oauth2.0使用教程

OAuth2.0使用教程

springsecurity oauth2.0 更改端点路径

spring security oauth2.0实现

oauth2.0的优缺点

spring security+jwt+oauth2.0 pdf

springboot整合springsecurity+oauth2.0实现token认证

OAuth2.0的应用场景

oauth2.0认证javaweb实现

sa-token和oauth2.0集成最佳实践

vue单点登录结合oauth2.0

shiro与oauth2.0

最新资源