OAuth 2.0官方文档：授权框架与OAuth 1.0的替代

5星 · 超过95%的资源需积分: 10 116 浏览量更新于2024-07-17 收藏 235KB PDF 举报

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

30元优惠券

资源详情

资源推荐

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

rui_1993

粉丝: 3
资源: 2

OAuth 2.0官方文档：授权框架与OAuth 1.0的替代

OAuth 2.0系列教程

《OAuth 2实战》代码.zip

OAuth2.in.Action.2017.3.pdf

Consider defining a bean of type 'org.springframework.security.oauth2.jwt.ReactiveJwtDecoder' in your configuration.

com.nimbusds.oauth2.sdk 的依赖地址是什么

Java oauth2实现单点登录

Consider defining a bean of type 'org.springframework.security.oauth2.jwt.JwtDecoder' in your configuration.

security.oauth2.ignore.urls

oauth2.provider.NoSuchClientException: No client with requested id: 000001,2,saas-app

jdkserijava.lang.string cannot be cast to springframework.security.oauth2.provider.oauth2authentication

Consider defining a bean of type 'org.springframework.security.oauth2.provider.token.RemoteTokenServices' in your configuration

java.lang.string cannot be cast to springframework.security.oauth2.provider.oauth2authentication

java实现oauth2 客户端

org.springframework.boot.autoconfigure.security.oauth2.client.EnableOAuth2Sso 相关maeve依赖

oauth2 java测试代码

Failed to evaluate expression '#oauth2.throwOnError(#oauth.hasScope('all'))'

spring.security.oauth2.client.provider.test.authorization-uri

springboot 单点登录

oauth2java包 校验密码的代码

springboot 整合oauth2

最新资源

oauth2java包校验密码的代码