OAuth 2.0授权框架（RFC6749）：互联网工程任务组标准化授权协议

OAuth

需积分: 23 54 浏览量更新于2024-07-16 收藏 235KB PDF 举报

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

领优惠券(最高得80元）

OAuth 2.0 是一个由 Internet Engineering Task Force (IETF) 发布的重要协议标准，RFC 6749，作者是 D. Hardt，于2012年10月发布，它取代了先前版本的 OAuth 1.0 协议（RFC 5849）。该授权框架的核心目标是允许第三方应用在用户的授权下访问特定的 HTTP 服务，或者通过获取用户许可来代表用户执行操作。这个标准定义了两种主要模式：一是通过协调资源所有者（通常指用户）与 HTTP 服务之间的审批交互来实现授权；二是第三方应用直接获得访问权限。 OAuth 2.0 的设计旨在简化授权过程，提供更高的安全性，并支持各种应用场景，如社交网络集成、API 访问控制等。它引入了新的概念，如访问令牌（Access Tokens）、授权码（Authorization Codes）和刷新令牌（Refresh Tokens），这些都在规范中进行了详细说明。授权流程通常包括以下步骤： 1. **资源所有者的授权请求**：用户在第三方应用的引导下向授权服务器发起授权请求。 2. **授权码流程**：用户授权后，应用会获得一个临时授权码，用以换取访问令牌。 3. **访问令牌请求**：应用使用授权码换取长期有效的访问令牌，可以用来访问受保护的资源。 4. **访问令牌的使用和刷新**：应用使用访问令牌进行服务请求，如果令牌过期，可通过刷新令牌续期。 OAuth 2.0 还注重安全性和隐私保护，规定了安全最佳实践，例如使用HTTPS传输敏感数据、设置过期时间以及对令牌的加密存储。此外，它支持多种授权策略，如授权码模式（Authorization Code Grant）、客户端凭证模式（Client Credentials Grant）和密码模式（Resource Owner Password Credentials Grant）等，以适应不同场景下的需求。作为一项标准化协议，OAuth 2.0 的实施对于现代互联网应用和服务间的交互至关重要，许多知名平台如Google、Facebook和Twitter都采用此标准来授权第三方应用访问其API。遵循 RFC 6749 的规定，开发者可以构建更加安全、灵活和可扩展的应用程序接口（APIs），同时保护用户的数据隐私。

资源详情

资源推荐

RFC 6749

OAuth 2.0 October 2012

these components, clients must be manually and specifically

configured against a specific authorization server and resource

server in order to interoperate.

This framework was designed with the clear expectation that future

work will define prescriptive profiles and extensions necessary to

achieve full web-scale interoperability.

1.9. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

specification are to be interpreted as described in [

RFC2119].

This specification uses the Augmented Backus-Naur Form (ABNF)

notation of [

RFC5234]. Additionally, the rule URI-reference is

included from "Uniform Resource Identifier (URI): Generic Syntax"

[

RFC3986].

Certain security-related terms are to be understood in the sense

defined in [

RFC4949]. These terms include, but are not limited to,

"attack", "authentication", "authorization", "certificate",

"confidentiality", "credential", "encryption", "identity", "sign",

"signature", "trust", "validate", and "verify".

Unless otherwise noted, all the protocol parameter names and values

are case sensitive.

2. Client Registration

Before initiating the protocol, the client registers with the

authorization server. The means through which the client registers

with the authorization server are beyond the scope of this

specification but typically involve end-user interaction with an HTML

registration form.

Client registration does not require a direct interaction between the

client and the authorization server. When supported by the

authorization server, registration can rely on other means for

establishing trust and obtaining the required client properties

(e.g., redirection URI, client type). For example, registration can

be accomplished using a self-issued or third-party-issued assertion,

or by the authorization server performing client discovery using a

trusted channel.

Hardt Standards Track [Page 13]

RFC 6749

OAuth 2.0 October 2012

When registering a client, the client developer SHALL:

o specify the client type as described in Section 2.1,

o provide its client redirection URIs as described in

Section 3.1.2,

and

o include any other information required by the authorization server

(e.g., application name, website, description, logo image, the

acceptance of legal terms).

2.1. Client Types

OAuth defines two client types, based on their ability to

authenticate securely with the authorization server (i.e., ability to

maintain the confidentiality of their client credentials):

confidential

Clients capable of maintaining the confidentiality of their

credentials (e.g., client implemented on a secure server with

restricted access to the client credentials), or capable of secure

client authentication using other means.

public

Clients incapable of maintaining the confidentiality of their

credentials (e.g., clients executing on the device used by the

resource owner, such as an installed native application or a web

browser-based application), and incapable of secure client

authentication via any other means.

The client type designation is based on the authorization server’s

definition of secure authentication and its acceptable exposure

levels of client credentials. The authorization server SHOULD NOT

make assumptions about the client type.

A client may be implemented as a distributed set of components, each

with a different client type and security context (e.g., a

distributed client with both a confidential server-based component

and a public browser-based component). If the authorization server

does not provide support for such clients or does not provide

guidance with regard to their registration, the client SHOULD

Hardt Standards Track [Page 14]

RFC 6749

OAuth 2.0 October 2012

This specification has been designed around the following client

profiles:

web application

A web application is a confidential client running on a web

server. Resource owners access the client via an HTML user

interface rendered in a user-agent on the device used by the

resource owner. The client credentials as well as any access

token issued to the client are stored on the web server and are

not exposed to or accessible by the resource owner.

user-agent-based application

A user-agent-based application is a public client in which the

client code is downloaded from a web server and executes within a

user-agent (e.g., web browser) on the device used by the resource

owner. Protocol data and credentials are easily accessible (and

often visible) to the resource owner. Since such applications

reside within the user-agent, they can make seamless use of the

user-agent capabilities when requesting authorization.

native application

A native application is a public client installed and executed on

the device used by the resource owner. Protocol data and

credentials are accessible to the resource owner. It is assumed

that any client authentication credentials included in the

application can be extracted. On the other hand, dynamically

issued credentials such as access tokens or refresh tokens can

receive an acceptable level of protection. At a minimum, these

credentials are protected from hostile servers with which the

application may interact. On some platforms, these credentials

might be protected from other applications residing on the same

device.

2.2. Client Identifier

The authorization server issues the registered client a client

identifier -- a unique string representing the registration

information provided by the client. The client identifier is not a

secret; it is exposed to the resource owner and MUST NOT be used

alone for client authentication. The client identifier is unique to

the authorization server.

The client identifier string size is left undefined by this

specification. The client should avoid making assumptions about the

identifier size. The authorization server SHOULD document the size

of any identifier it issues.

Hardt Standards Track [Page 15]

RFC 6749

OAuth 2.0 October 2012

2.3. Client Authentication

If the client type is confidential, the client and authorization

server establish a client authentication method suitable for the

security requirements of the authorization server. The authorization

server MAY accept any form of client authentication meeting its

security requirements.

Confidential clients are typically issued (or establish) a set of

client credentials used for authenticating with the authorization

server (e.g., password, public/private key pair).

The authorization server MAY establish a client authentication method

with public clients. However, the authorization server MUST NOT rely

on public client authentication for the purpose of identifying the

client.

The client MUST NOT use more than one authentication method in each

request.

2.3.1. Client Password

Clients in possession of a client password MAY use the HTTP Basic

authentication scheme as defined in [

RFC2617] to authenticate with

the authorization server. The client identifier is encoded using the

"application/x-www-form-urlencoded" encoding algorithm per

Appendix B, and the encoded value is used as the username; the client

password is encoded using the same algorithm and used as the

password. The authorization server MUST support the HTTP Basic

authentication scheme for authenticating clients that were issued a

client password.

For example (with extra line breaks for display purposes only):

Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

Alternatively, the authorization server MAY support including the

client credentials in the request-body using the following

parameters:

client_id

REQUIRED. The client identifier issued to the client during

the registration process described by

Section 2.2.

client_secret

REQUIRED. The client secret. The client MAY omit the

parameter if the client secret is an empty string.

Hardt Standards Track [Page 16]

剩余75页未读，继续阅读

karqical

粉丝: 1
资源: 17

OAuth 2.0授权框架（RFC6749）：互联网工程任务组标准化授权协议

The OAuth 2.0 Authorization Framework

RFC 6749-OAuth 2.0授权框架(中文版).pdf

springsecurity oauth2.0 更改端点路径

oauth2.0的面试题

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

oauth2 @Deprecated

c# oauth2.0

spring-security-oauth2-2.2.3.release.jar

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

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

oauth2.0的优缺点

接入duros oauth2.0

springboot oauth2.0 客户端和服务端

spring security oauth2.0实现

oauth2.0 客户端 用java开发

springSecurity oauth2.0怎么学习

OAuth2.0的应用场景

oauth2.0使用教程

OAuth2.0使用教程

oauth2.0认证javaweb实现

最新资源

oauth2.0 客户端用java开发