OAuth2实战：授权机制详解

5星 · 超过95%的资源需积分: 49 97 浏览量更新于2024-07-20 4 收藏 13.52MB PDF 举报

"OAuth2.in.Action.2017.3.pdf" OAuth2是一个授权框架，它被广泛用于实现安全的第三方应用访问用户资源。在《OAuth2 in Action》这本书中，作者Justin Richer和Antonio Sanso深入探讨了OAuth2的原理、实施和最佳实践。这本书由Manning Publications于2017年出版，旨在帮助开发者和安全专家理解并有效地应用OAuth2。 OAuth2的主要目标是提供一种机制，允许用户授权第三方应用访问其存储在服务提供商（如Google或Facebook）上的个人数据，而无需分享他们的用户名和密码。这通过授权码流程、隐式流程、密码凭据流程和客户端凭据流程等不同授权类型来实现。书中的内容可能涵盖了这些流程的详细解释和示例。在OAuth2的授权码流程中，用户首先被重定向到服务提供商进行身份验证，然后授权第三方应用访问特定的资源。服务提供商返回一个授权码，这个授权码随后被第三方应用用来获取访问令牌。访问令牌用于后续与服务提供商的API交互，以获取用户的数据。书中可能还讨论了OAuth2的安全考虑，包括如何防止重放攻击、如何保护令牌以及如何处理令牌的生命周期管理。此外，作者可能还提到了与OAuth2相关的其他安全标准，如OpenID Connect，它是在OAuth2基础上添加了身份验证层，提供了用户身份验证的能力。作者Justin Richer和Antonio Sanso的贡献在于将复杂的OAuth2概念和实施细节以易懂的方式呈现出来，适合初学者和有经验的开发者阅读。书中的实战例子和代码示例将有助于读者更好地理解和应用OAuth2。特别值得一提的是，Manning Publications对于版权的重视，强调未经许可不得复制或传播书中的内容。同时，书中可能会尊重制造商和销售商的商标权益，对商标名称进行适当的处理。《OAuth2 in Action》是一本全面介绍OAuth2框架的实用指南，对于任何需要在应用中集成安全授权功能的开发者来说，都是一份宝贵的参考资料。通过阅读此书，读者可以学习到如何在实际项目中安全、有效地利用OAuth2授权机制。

preface xv

on a wide variety of systems. I’d taught classes, given lectures, and written a handful of

articles about the subject.

So when Antonio Sanso, a well-respected security researcher in his own right,

approached me to write this book together, it made sense for me to jump in. We looked

around at what books were available on OAuth 2.0, and were unimpressed. Most of the

material we found was specific to a service: How to write an OAuth client to talk to Facebook

or Google, for instance. Or How to authorize your native application to GitHub’s API. And if

that’s all you care about, there’s plenty of material out there. But what we didn’t see

was something that would take the reader through the entire OAuth system, explain-

ing why it is designed the way that it is, pointing out its flaws and limitations as well as

its strengths. We decided that there was a need for a more comprehensive approach,

and we decided to make it the best that we could. Consequently, this book doesn’t talk

to any specific real-world OAuth provider, nor does it get into detail on a particular API

or vertical domain. Instead, this book focuses on doing OAuth for its own sake, so that

you can see how all the gears mesh together when you turn the cranks.

We built out a code framework that, we hoped, would allow readers to focus on the

core aspects of OAuth without getting overly caught up in the implementation plat-

form details. After all, we didn’t want a book that was “How to implement OAuth 2.0

on Platform Du Jour,” but rather, “How the nuts and bolts of OAuth 2.0 work so you

can use whatever platform you want.” So we went with a relatively simple Node.js

framework, built on Express.js, and liberally used library code to abstract away the

platform-specific weirdness as much as possible. Still, it’s JavaScript, so some of that

weirdness crept in from time to time, as it would on any platform. But it’s our hope that

you will be able to apply the methods and themes used here to your chosen language,

platform, and architecture.

Speaking of histories, how did we even get here? The story starts in 2006, when

several web service companies, including Twitter and Ma.Gnolia, had complementary

applications and wanted their users to be able to connect them together. At the time,

this type of connection was typically accomplished by asking the user for their creden-

tials on the remote system and sending those credentials to the API. However, the web-

sites in question used a distributed identity technology, OpenID, to facilitate login. As

a consequence, there were no usernames or passwords that could be used for the API.

To overcome this, the developers sought to create a protocol that would allow their

users to delegate access to the API. They based their new protocol on several propri-

etary implementations of this same concept, including Google’s AuthSub and Yahoo!’s

BBAuth. In all of these, a client application is authorized by a user and receives a token

that can then be used to access a remote API. These tokens were all issued with a public

and private portion, and this protocol used a novel (if in retrospect fragile) crypto-

graphic signing mechanism so that it could be used over non-TLS HTTP connections.

They called their protocol OAuth 1.0 and published it as an open standard on the web.

xvi preface

It quickly gained traction, and free implementations in several languages were made

available alongside the specification itself. It worked so well and developers liked it so

much that even the large internet companies soon deprecated their own proprietary

mechanisms that had inspired OAuth in the first place.

As happens with many new security protocols, a flaw was found early on in OAuth

1.0’s life, leading to the development of OAuth 1.0a to close a session fixation vulner-

ability. This version was later codified in the IETF as RFC 5849. At this point, a commu-

nity was beginning to grow around the OAuth protocol, and new use cases were being

developed and implemented. Some of these pushed OAuth into places that it was

never meant to be used in, but these off-label OAuth uses worked better than any avail-

able alternatives. Still, OAuth 1.0 was a monolithic protocol designed to provide one

mechanism to solve all use cases, and it was venturing into uncomfortable territory.

Soon after the publication of RFC 5849, the Web Resource Access Protocol (WRAP)

was published. This proposed protocol took the core aspects of the OAuth 1.0a pro-

tocol—a client, delegation, and tokens—and expanded them to be used in different

ways. WRAP did away with many of OAuth 1.0’s more confusing and problem-prone

aspects, such as its custom signature calculation mechanism. After much debate in the

community, WRAP was decided on as the basis for the new OAuth 2.0 protocol. Where

OAuth 1.0 was monolithic, OAuth 2.0 was modular. The modularity in OAuth 2.0

allowed it to be a framework that could be deployed and used in all of the ways that

OAuth 1.0 had been in practice, but without twisting core aspects of the protocol.

OAuth 2.0 essentially provided recipes.

In 2012, the core OAuth 2.0 specifications were ratified by the IETF, but the com-

munity was far from done with it. This modularity was further codified by splitting the

specification into two complementary pieces: RFC 6749 details how to get a token,

while RFC 6750 details how to use a particular type of token (the Bearer token) at a

protected resource. Furthermore, the core of RFC6749 details multiple ways to get a

token and provides an extension mechanism. Instead of defining one complex method

to fit different deployment models, OAuth 2.0 defines four different grant types, each

suited to a different application type.

Today, OAuth 2.0 is the premier authorization protocol in use on the web. It’s used

by everything: from large internet companies to small startups, to enterprises, to just

about everything in between and beyond. A whole ecosystem of extensions, profiles,

and entire protocols built on top of OAuth 2.0 has sprung up, with people finding new

and interesting ways to use this foundational technology. It’s our goal that this book

will help you understand not only what OAuth 2.0 is and why it works the way it does,

but how you can best use it to solve your own problems and build your own systems.

JUSTIN RICHER

xviii acknowledgments

chance and preordered the book as a MEAP; the early feedback we got from you was

vital in making this the best book we could make it.

We would also like to thank our peer reviewers who read the manuscript at various

stages of its development and provided invaluable feedback along the way: Alessandro

Campeis, Darko Bozhinovski, Gianluigi Spagnuolo, Gregor Zurowski, John Guthrie,

Jorge Bo, Richard Meinsen, Thomas O’Rourke, and Travis Nelson.

Justin Richer

Incomparable thanks are due to my coauthor, Antonio Sanso. His security and crypto-

graphic expertise far outstrips anything I could dream of achieving, and it’s been an

honor to work with him. Starting the book was his idea in the first place, and the whole

project has been a collaborative effort.

Thanks to my friends Mark Sherman and Dave Shepherd, both of whom success-

fully published tech books before I first set words to the page. Their existence served

to remind me that there was a light at the end of the tunnel, and their experience

in navigating the publishing world was a great help. Thanks to John Brooks, Tristan

Lewis, and Steve Moore, whom I was able to bounce ideas and phrases off of, even if

they didn’t always realize I was doing it at the time.

Many thanks to my clients over the last year for putting up with me disappearing at

random times to go off and write. Thanks are especially due to Debbie Bucci and Paul

Grassi, as their fantastic work programs have helped give me the direct experience

needed to ground this book in the real world.

I can’t possibly express enough thanks to my friend and colleague, Sarah Squire. She

originally turned me on to the Node.js frameworks used in the exercises throughout

the book, and I believe that, thanks to a trip to an office store, she has the distinction

of owning the first printed version of this book. Overall, her encouragement, support,

critique, and enthusiasm for this project has been without compare, and I doubt that

the book would have really happened without her.

Finally, but perhaps most importantly, a sincere and deep thank you to my entire

family. The patience of my wife, Debbie, and my kids, Lucien, Genevieve, and Xavier,

has been incredible. Between late nights and seemingly endless weekends with me

locked up in my office, just out of reach, I’m sure they started to wonder if I’d ever

come out, but now I’m glad to say there should be a whole lot more time to play Legos.

Antonio Sanso

Working on this book has been quite a ride, and it’s with great delight and satisfaction

that I write this part. In the end, as with everything, it’s the journey and not the destina-

tion that matters. My contribution to this book could not be possible without the help

of many people surrounding me.

I would like to thank my employer, Adobe Systems, and my managers Michael Marth

and Philipp Suter for giving me the green light to work on this book.

剩余361页未读，继续阅读

xinconan2

粉丝: 269
资源: 399

OAuth2实战：授权机制详解

《OAuth 2实战》代码.zip

oauth2全套（授权服务器+资源服务器+客户端独立版）

OAuth2.0协议中文版.pdf

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

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

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

security.oauth2.ignore.urls

Java oauth2实现单点登录

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

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

最新资源