NOTE: Please see comment

The initial support for OAuth 2.0 Authorization Server will target the following features:

Comment From: chrylis

I have repeated a particular implementation pattern enough times that I'm planning to develop a modular open-source auth-server solution that covers similar ground as Okta/the old Stormpath but has the control of in-house deployment and customized authentication steps/rules that have caused my clients to need an in-house solution. This is still in the planning stage, but I have a reasonably reliable pattern that I expect to follow.

As part of this, I am interested in working on the rewritten auth-server support in Spring Security 5. I have a good bit of experience with Spring Security OAuth2 and am familiar with the architectural principles as well as the places that work smoothly and the friction points. I'm up for doing as much of this particular module as needed, although I don't have direct experience with OICD or PKCE yet. I'm especially interested in helping to smooth out some of the currently difficult aspects of configuring the workflow such as performing per-user authorization checks.

Comment From: jgrandja

@chrylis Thanks for getting in touch! We certainly can use the help and would welcome your contributions. I'm really interested to learn more about your interest/experience and see if we can work together to start this up. I'm thinking a zoom meeting might be the best bet to introduce ourselves and possibly come up with some sort of plan. What are your thoughts?

Comment From: erbrecht

I've been looking for support for passing JWTs by reference in addition to the default by value type. Is this something that is planned at all? Is it appropriate to ask here? I was going to create an issue when I came across this one and I figured this was probably more appropriate.

Comment From: jgrandja

@erbrecht

looking for support for passing JWTs by reference in addition to the default by value type

Can you provide more details here? It's not clear to me what you're looking for exactly.

Also, given this is a question, please ask on StackOverflow first. We prefer to keep issues for bug reports and new feature requests and/or enhancements.

If you are looking for a new feature or enhancement, please log a new issue and provide as much detail as possible. Thank you.

Comment From: EtachGu

Does the work on Authorization Server PKCE support start ?

Comment From: jgrandja

@EtachGu No it hasn't started yet. This is targeted for 5.3 as indicated in the Milestone of this ticket. We are currently working on the upcoming 5.2 release.

Comment From: Captain-P-Goldfish

Support for OAuth2-authorization-server was targeted for early 2019. What is the current plan for getting finished with the authorization server implementation?

Comment From: rwinch

It's tentatively scheduled for 5.3 Spring Security follows Spring Framework release schedule which has not been set for 5.3 Minor releases, such as 5.3, are typically a year out.

Comment From: jgrandja

The Spring Security team has decided to no longer provide support for Authorization Servers.

Please see the latest announcement on Spring Security OAuth 2.0 Roadmap Update.

Comment From: codependent

RIP Spring Auth Server. This decission makes sense from the point of view of the Spring Team. However it was a nice alternative to other (generally) more complex solutions such as Keycloak.

Comment From: jzheaux

We'd like to thank everyone for your feedback on the decision to not support Authorization Server. Due to this feedback and some internal discussions, we are taking another look at this decision. We'll notify the community on any progress.

Comment From: mlschechter

This is exceptionally useful functionality if you have any need for a custom authentication mechanism; most off-the-shelf solutions like Keycloak limit customization and require you to switch your authentication to them. This is very difficult when they don't support platform-like capabilities (such as multi-level multi-tenancy).

Please keep this in the Spring framework.

Comment From: sindhujasrivastava

In my current project, we are using the Spring Authorisation Server to provide OAuth 2.0 SSO for our products. Having an in house implementation gives us a lot of scope for customization. It will be a huge disappointment if the community is treating it as a legacy and no longer providing the latest standards. I was actually actively following the release plan and waiting to get the support of the PKCE grant in the Spring Auth Server. Please re-consider the decision.

Comment From: nissane

Quick chime here. Please re-consider. Things fit really nicely with authorization support in spring. We would have to rip out tons of tested code if you remove support. Thank you for listening/reconsidering.

Comment From: NealSavant

Please reconsider :)

Comment From: franzfloresjr

This project is really great. Please re-consider. Thank you very much.

Comment From: supertypo

Please reconsider! :)

Comment From: ashulinskiy

Joining the chorus - please reconsider!

Comment From: z0mb1ek

Please reconsider

Comment From: ryl

Yes, please reconsider!

Comment From: lanwen

hey lovely people, please stop the spam, just put emoji

Comment From: Davidoc11

Well, I've been reading all the comments and as many of you, I am a little disappointed. I would like to point out that I'm not as experienced as the majority of developers around here. You can't imagine how many times I've tried to develop a simple application (just for the sake of learning) but I always failed. Now in my first job, I HAD to do it no matter what and with much effort and research, I made it. I was so sad when I saw @EnableAuthorizationServer strikethrough (deprecated).

If I use Spring Security 5.x my main question is what should I use to authenticate my users (via password grant type) with records that come from our DB (UserDetailService), what should I use if I add extra parameters to my token response with a TokenEnhancer?

As I mentioned before, I'm not as experienced as I would like to be but I want to join the discussion and ask the team not to abandon the Authorization Server.

Comment From: aliallawy1068

Please bring it back, we too have implemented a custom authorization server and cannot migrate to another solution. This is very disappointing..

Comment From: dalirouissi

Disappointing decision!! Please reconsider. Even oauth referes to Spring.

Comment From: akuma8

After that decision and hard working for 2 months, I finally migrated 10 applications from Spring Security OAuth2 to Spring Security 5.2 with Keycloak as authorization server. I sum up some of issues I met: - I had to learn Keycloak, I am still learning it while with Spring Security OAuth2(SSO2) everything was transparent. I was also surprised to see how cumbersome it is to customize Keycloak. - Having Keycloak means another server to manage and maintain while with SSO2 my authorization server was included in my app codebase. - We have to take care about clock syncing between Keycloak and protected apps. During development, container running Keycloak was delay (it’s a Docker issue on Windows) so all access tokens were expired. - Don’t use the Keycloak Spring Security Adapter with Spring Security 5.2(or further), I lost almost a week because the Keycloak security base class KeycloakWebSecurityConfigurerAdapter is misconfigured and my apps failed to start. Thanks to @jzheaux I removed all Keycloak dependencies from my application and use only Spring Security 5.2 with its oauth2 support to protect my apps. Since the Keycloak github repo doesn’t allow opening issue I didn’t tell them about that problem. - It seems difficult to have Keycloak behind a gateway. I use Spring Cloud Gateway. When configuring Spring Security the issuer-uri is set statically, at start up Spring Security calls that uri +.well-known/openid-configuration and verify that the response well contains our issuer-uri, if not the application fails. In my case if I set the issuer-uri using the gateway the application fails since the Keycloak’s response does not include my gateway. We have to do other tricks to enable that. - Deleting all my old codes hurt me! But having less classes and packages to maintain is cool! I was disappointed like many SSO2 developers but finally it’s not too bad to have only one Spring Security dependency. The codebase is clearer, less polluted by annotations. If I had a blog I would detailed a lot the migration guide.

Comment From: nissane

@akuma8 thanks for sharing. We wound up using Auth0's service, so we would not have to manage a keycloak server,etc. I know that is not a solution for everyone, but wanted to share that as an alternative. It took some time as well, working thru their API's and best practices, but got it working eventually.

Comment From: tb94

We'd like to thank everyone for your feedback on the decision to not support Authorization Server. Due to this feedback and some internal discussions, we are taking another look at this decision. We'll notify the community on any progress.

@jzheaux without any word in the last few months, can we assume Authorization Server is dead and gone?

Comment From: up-87

@tb94 Well there was a comment announcing an update on this topic in the near future: https://github.com/spring-projects/spring-security-oauth/issues/1832#issuecomment-590879604

Comment From: githengi

Please reconsider and provide support for Authorization server.

Comment From: vborcea

Hi, The SpringSecurity team has done a hell of a job starting with migration of acegi-security. Letting go the Authorization Server is like delivering a car without it's engine or transmission. Please reconsider and integrate it in future SpringSecurity.

Comment From: rigofunc

I waiting for long time. Please reconsider and provide support for Authorization server.

Comment From: dmurat

@rwinch Thank you so much :-D

Comment From: allurx

Now spring-security provides client and resource-server support, and lacks the most important Authorization server, as @vborcea said. At this time, spring-security providing oauth2 support is like a car without an engine. It's incredible. At the same time, using an Authorization server like Keycloak brings additional learning costs and must also convince other members of the team, so I hope spring-security can reconsider providing support for Authorization server.

Comment From: mmuth

Same here, please please please provide the support for Authorization Server.

We have build a nice authentication solution on top of the current Spring libraries, which fits perfect for our needs and our customers are so happy... At the moment we plan to extend functionality around, and we are struggling now with the uncertainty if we should completely switch to another solution... but we still love the current Auth Server implementation of Spring - please reconsider to provide support for the Auth Server!

Comment From: rwinch

For everyone providing feedback. Thank you! We are listening and working on a formal updated response (we will post an update here once we have it) but it is taking some time. Thank you for your patience and thank you again for the feedback!

Comment From: mziari

Please reconsider and provide support for Authorization server tnx

Comment From: lucasmenezesaurea

+1 for having authz server back on roadmap! hopefully before Spring Security OAuth EOL!

Comment From: tudorgrig

Guys, seriously, please reconsider. The Authorization server is an actor in the OAuth 2 protocol, you can't just remove it. I've looked through the documentation on how to implement an Authorization server using Keycloack (in my case I want to enable username/pass and social login as well) and it's a mess. Please offer support so that we can go back to loving Spring Security 👍

Comment From: tudorgrig

After that decision and hard working for 2 months, I finally migrated 10 applications from Spring Security OAuth2 to Spring Security 5.2 with Keycloak as authorization server. I sum up some of issues I met:

  • I had to learn Keycloak, I am still learning it while with Spring Security OAuth2(SSO2) everything was transparent. I was also surprised to see how cumbersome it is to customize Keycloak.
  • Having Keycloak means another server to manage and maintain while with SSO2 my authorization server was included in my app codebase.
  • We have to take care about clock syncing between Keycloak and protected apps. During development, container running Keycloak was delay (it’s a Docker issue on Windows) so all access tokens were expired.
  • Don’t use the Keycloak Spring Security Adapter with Spring Security 5.2(or further), I lost almost a week because the Keycloak security base class KeycloakWebSecurityConfigurerAdapter is misconfigured and my apps failed to start. Thanks to @jzheaux I removed all Keycloak dependencies from my application and use only Spring Security 5.2 with its oauth2 support to protect my apps. Since the Keycloak github repo doesn’t allow opening issue I didn’t tell them about that problem.
  • It seems difficult to have Keycloak behind a gateway. I use Spring Cloud Gateway. When configuring Spring Security the issuer-uri is set statically, at start up Spring Security calls that uri +.well-known/openid-configuration and verify that the response well contains our issuer-uri, if not the application fails. In my case if I set the issuer-uri using the gateway the application fails since the Keycloak’s response does not include my gateway. We have to do other tricks to enable that.
  • Deleting all my old codes hurt me! But having less classes and packages to maintain is cool! I was disappointed like many SSO2 developers but finally it’s not too bad to have only one Spring Security dependency. The codebase is clearer, less polluted by annotations. If I had a blog I would detailed a lot the migration guide.

Can you please share how you did it? Did you implement the Keycloak server as an embedded application inside a spring Boot app?

Comment From: mostafa513

All the time, spring was the best platform that I work with it. because of stability, simplify and reduce worries about everything. And nowadays some of us worry about some decisions in Spring team. I prefer to think about this as a 13 April lie. Please reconsider and provide long time support for the Authorization server and remain my best choice. be happy and be safe

Comment From: akuma8

@tudorgrig

Can you please share how you did it? Did you implement the Keycloak server as an embedded application inside a spring Boot app?

No, read my 2nd point, I still have a Keycloak server running inside a container. This is the most annoying thing because we have to be really careful to never have that server down. There are other challenges too like having Keycloak behind a gateway. I am currently working on that point because we don’t want to expose our Keycloak server to internet. I am thinking about writing an article to share how I did my migration, it could help other developers and having feedbacks for some improvements will be very helpful. I just don’t know where I could publish it since I don’t have a blog.

Comment From: konstantinblaesi

@akuma8 since spring-security uses the nimbus sdk to implement oidc and oauth2, wouldn't it make sense to use that if we needed to implement authorization servers ourselves?

Comment From: rossbu

Hope Spring team would reconsider this decision, the reason given was: "Spring Security’s Authorization Server support was never a good fit. An Authorization Server requires a library to build a product. Spring Security, being a framework, is not in the business of building libraries or products. " from https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update

So the key is to define the Spring security project scope and definition, I agree that spring security is a framework, so if you would consider the oauth2 servers as standalone app servers ( resource, client, and auth) instead of part of the Spring security framework, and regarding "An Authorization Server requires a library to build a product" when the library is referred ( instead of the whole framework). I would suggest to branch out / or create a new supporting auth LIB instead of depending on the ones from Spring Security framework, that would make the less coupled and on its own path.
the last but not the least, is about the product, in some sense. spring components are products themselves. ( supporting/wrapper product to compose other impl libs).

Comment From: OrangeDog

@rossbu from the very same post

Due to this feedback and some internal discussions, we are taking another look at this decision.

and above

We are listening and working on a formal updated response (we will post an update here once we have it) but it is taking some time.

Comment From: OrangeDog

@rwinch @jgrandja it is perhaps overdue to lock this issue for the moment, and hide the off-topic stuff.

Comment From: jgrandja

@OrangeDog Stay tuned for the blog announcement tomorrow.

Comment From: jgrandja

We are very excited to announce the Spring Authorization Server !

The ultimate goal of this community-driven project, led by the Spring Security team, is to replace the Authorization Server support provided by Spring Security OAuth.

The project will start in Spring’s experimental projects as an independent project so that it can evolve more rapidly.

The success of this project will heavily depend on contributions from the community. We are very excited to work with the community on this very important initiative. So please don't hold back and we look forward to your contributions! @OrangeDog @philsttr

Going forward, please direct all communication to the Spring Authorization Server repository.