Shulou(Shulou.com)06/01 Report--

This article focuses on "what to do when Spring Security OAuth expires". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what to do when Spring Security OAuth expires"!

When you choose to rely on OAuth3, you may also be confused. There are several places you can choose:

So which one is the right one to rely on? What's the difference between these different dependencies? Today, Brother Song is here to talk to you about the feud about OAuth3 in Spring Security.

Preface

First, let's give an overview of the development of OAuth3 in the Spring framework.

About a decade ago, Spring introduced a community-driven open source project, Spring Security OAuth, and incorporated it into the Spring portfolio. Today, it has grown into a mature project that supports most of the OAuth specifications, including resource servers, clients, and authorization servers.

Now it has become the foundation of UAA (User Account and Authentication Server). The Spring Security OAuth project has become a model project that proves that the Spring community can do a great job.

However, there were some problems with early projects:

OAuth was completed a long time ago, and developers can't predict what will happen in the future and how the code will be used. As a result, many Spring projects provide their own OAuth support, which leads to fragmentation of OAuth3 support.

The earliest OAuth projects supported both OAuth2.0 and OAuth3.0, but now OAuth2.0 is no longer in use and can be abandoned.

Now we have more libraries to choose from and can develop on the basis of these libraries in order to better support new gadgets such as JWT.

For these reasons, officials decided to rewrite Spring Security OAuth based on the success of the community to better coordinate Spring and OAuth, and to simplify the code base to make Spring's OAuth support more flexible.

However, there are many twists and turns in the process of rewriting.

2018.01.30

It starts on January 30, 2018.

On that day, Spring officially issued a notice to phase out existing OAuth3 support and build the next generation of OAuth3.0 support in Spring Security5.

Why are you doing this?

As we all know, OAuth3 is just a protocol, and the Spring framework implements this protocol through code.

At that time, OAuth3's landing plan was chaotic (which still exists today), and the implementation of OAuth3 was provided in Spring Security OAuth, Spring Cloud Security, Spring Boot 1.5.x, and the latest Spring Security5.x at that time.

So that when developers need to use OAuth3, they have to ask, which dependency is the right one? OAuth3 support is already available in three places, which is confusing enough, so why continue to provide implementation in the latest Spring Security5.x?

What a mess!

So Spring officially decided that it was necessary to unify OAuth3.0 support into one project in order to provide users with clear choices and avoid any potential confusion, while OAuth3 development documents should be rewritten to make it easier for developers to learn. All decisions will be made in Spring Security5 to build support for the next generation of OAuth3.0.

Since then, the Spring Security OAuth project has officially been in maintenance mode. The official will provide error / security fixes for at least 1 year, and will consider adding secondary features, but not major features. All the functions in Spring Security OAuth are refactored into Spring Security5.x at the same time.

To be honest, it was a wise decision and did not cause much response at that time. But then things didn't go so well.

2019.11.14

Time is up to 2019.11.14.

On that day, the official issued another notice.

First of all, the process of moving Spring Security OAuth to Spring Security5.x is very smooth. Most of the migration work has been completed. The rest will be completed in version 5.3. Many new features have been added in the process of migration, including support for OpenID Connect1.0.

Next, the conversation changed and said one thing that is difficult for many people to accept, that is, it will no longer provide support for authorized servers (if friends do not know what authorized servers are, you can reply to OAuth3 on the official account Jiangnan Dianyu background, with OAuth3 tutorials written by Brother Song).

The official gave two reasons for not providing:

In 2019, a large number of commercial and open source licensing servers will be available.

The license server uses a library to build the product, and Spring Security, as a framework, is not suitable for doing this.

One stone stirred up thousands of waves, and many developers said it was difficult to accept. The matter has also sparked a heated discussion in the Spring community, but fortunately, Spring officials are willing to listen to the voices of the community.

2020.04.15

On that day, the official issued another notice.

The Spring Authorization Server project was announced this time. This is a community-driven project led by the Spring Security team dedicated to providing Authorization Server support to the Spring community.

Officials listened to the voices of the community and decided to continue to provide authorized servers.

This time it was just an announcement, which calmed the mood of the community, but the project has not yet been developed.

2020.08.21

Spring Authorization Server 0.0.1 is officially released!

At the same time, the source address of the project: https://github.com/spring-projects-experimental/spring-authorization-server

In this version, the following features are mainly provided:

OAuth 2.0 Authorization Code granted to  -RFC 6749

OAuth 2.0 client credentials are granted to  -RFC 6749

JSON Web token (JWT)  -RFC 7519

JSON Web signature (JWS)  -RFC 7515

JSON Web key (JWK)  -RFC 7517

Key management, used to provide keys when signing JWT (JWS)

Other features are still under development.

This is how OAuth3 has changed in recent years.

Back to the question.

Let's go back to the original question.

What if the class expires?

The class expires because the old writing method is no longer supported. Brother Song, to take a simple example, we used to define a resource server like this:

@ Configuration@EnableResourceServerpublic class ResourceServerConfig extends ResourceServerConfigurerAdapter {@ Bean RemoteTokenServices tokenServices () {RemoteTokenServices services = new RemoteTokenServices (); services.setCheckTokenEndpointUrl ("http://localhost:8080/oauth/check_token"); services.setClientId (" javaboy "); services.setClientSecret (" 123"); return services;} @ Override public void configure (ResourceServerSecurityConfigurer resources) throws Exception {resources.resourceId ("res1") .tokenServices (tokenServices ()) } @ Override public void configure (HttpSecurity http) throws Exception {http.authorizeRequests () .antMatch ("/ admin/**") .hasRole ("admin") .anyRequest (). Authenticated ();}}

Now that we have migrated to Spring Security5.x, we define it as follows:

@ Configurationpublic class MyResourceServer extends WebSecurityConfigurerAdapter {@ Override protected void configure (HttpSecurity http) throws Exception {http.authorizeRequests () .anyRequest () .authenticated () .and () .oauth3ResourceServer () .opaqueToken () .introspectionUri ("http://localhost:8080/oauth/check_token") .introspectionClientCredentials (" javaboy "," 123 ") }}

These two pieces of code have the same effect. What follows is the latest way of writing, and there is no problem of expiration.

At this point, I believe you have a deeper understanding of "what to do when Spring Security OAuth expires". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.