OAuth2授权框架详解与应用示例

需积分: 10 14 浏览量更新于2024-07-22 收藏 233KB PDF 举报

OAuth 2.0是一种开放标准协议，由Internet Engineering Task Force (IETF)的David Hardt等人制定，于2012年10月发布的RFC 6749中详述。它旨在解决OAuth 1.0协议的局限性，提供一个更安全、灵活的授权框架，以便第三方应用能够获得对HTTP服务的有限访问权限。OAuth 2.0的核心概念是基于资源所有者（Resource Owner）的授权，允许第三方应用在用户明确许可的情况下，代表用户与服务交互，或者通过用户授权获取服务的访问权限。在OAuth 2.0流程中，主要包括以下几个关键步骤： 1. **资源服务器**：提供被请求的服务或数据，如社交媒体账户或在线支付系统。 2. **授权服务器**：存储资源服务器的令牌和用户的授权信息，负责处理授权请求和管理权限。 3. **客户端应用**：第三方应用试图访问资源服务器的服务，需要通过授权服务器获取访问令牌。 4. **授权过程**： - 用户被重定向到授权服务器，显示一个授权界面，询问是否允许第三方应用访问其资源。 - 用户同意后，授权服务器会生成一个临时的授权码（code）发送回客户端。 - 客户端应用使用授权码换取长期访问令牌（access token），可能还需要客户端的密钥（client ID）和秘密（client secret）。 5. **访问控制**：有了访问令牌，客户端应用可以使用它来向资源服务器请求特定的服务或数据，但权限通常受到严格的限制，以保护用户隐私。 6. **刷新机制**：长期令牌有时会有有效期，当令牌过期时，客户端应用可以使用刷新令牌（refresh token）请求新的长期令牌，而无需重新进行整个授权流程。 OAuth 2.0版本的发布，不仅提升了安全性（比如使用JWT令牌和JSON Web Token），还引入了更多的授权类型（如授权码模式、客户端凭据模式和隐式模式），以适应不同的应用场景需求。此外，它还考虑到了移动设备和Web应用程序的快速发展，支持多种身份验证方法和跨域资源共享（Cross-Origin Resource Sharing, CORS）。 OAuth 2.0是一个强大的工具，广泛应用于现代互联网服务中，用于管理和控制用户对第三方应用的访问权限，确保数据的安全共享。它的成功在于其灵活性和可扩展性，使得开发者能方便地实现应用间的数据交换，同时保持用户数据的安全。

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页未读，继续阅读

mypromising

粉丝: 0
资源: 3

OAuth2授权框架详解与应用示例

oauth2 +spring

oauth2authorizationserverjackson2module作用

java实现oauth2 客户端

springboot oauth2 client

spring-security-oauth2 和spring-cloud-starter-oauth2

java实现oauth2

simple-oauth2

springboot 整合oauth2

Koa2 oauth2

java 调用oauth2接口

最新资源