Support OAuth 2.0 within Spring Security

[rwinch]

Right now Spring's OAuth story is a bit fragmented. We should provide support within Spring Security proper for OAuth.

This will likely involve a rewrite of many of the pieces of Spring Security OAuth project to ensure that all the Spring Projects align. Some pieces that we must consider:

• Spring Social
• Spring Security OAuth
• Spring Cloud Security
• Spring Boot's Enable SSO support
• UAA

[jgrandja]

A key preliminary step before we proceed to re-write and incorporate OAuth2 into Spring Security proper is to research and evaluate existing OAuth2 java library implementations available in the open source community.

This will allow us to gain the knowledge of what the current libraries are doing well and what types of features are missing.

The ultimate goal is to provide an easy-to-use API for OAuth2 requiring minimal setup/configuration and to build from there to provide further support for the OAuth2 Extensions, for example, OpenID Connect, JWT, etc.

[jgrandja]

Research and evaluation notes on existing OAuth2 java library implementations to follow...

[jgrandja]

Stormpath is an Identity-as-a-Service (IDaaS) providing the end-user the ability to create and manage user accounts in addition to authentication and authorization of those user accounts.

The REST API’s exposed by the Stormpath SDK conform to the following proprietary Data Model.

Relevant Links:

Java Support
Java SDK
JWT SDK

Analysis:

Stormpath provides tight integration to their Identity Service and proprietary data model. They do provide integration to other OAuth Providers, for example Google, however, the SDK always communicates through the Stormpath REST API's in order to obtain an Access Token for use in the Google API’s.

More specifically, you cannot use the Stormpath SDK as a client to directly request an Access Token to a 3rd Party OAuth2 Authorization Server. For this reason alone, Stormpath cannot be considered as an implementation option for the new Spring Security OAuth2 Client initiative.

However, I would like to add that I found the implementation of the SDK and all Spring-related integrations (Boot, Security) very well-designed and quite intuitive. Definitely a solid consideration if there was a need/requirement to integrate with an IDaaS.

Their JWT SDK should also be considered as I found it quite easy to use and it provides extensive JOSE support.

[jgrandja]

Auth0 is an Identity-as-a-Service (IDaaS) providing similar features as Stormpath and can be considered a direct competitor.

Relevant Links:

Java Support
Java SDK
JWT SDK

Analysis:

The same analysis applies as that of Stormpath so won't repeat here.

Their SDK implementation and Spring-related integrations are not quite at the level of Stormpath's implementations.

[jgrandja]

Connect2id provides an open source Java SDK for OAuth 2.0, OpenID Connect and JOSE/JWT.
In addition, it also provides an OpenID Connect and OAuth 2.0 Server implementation, however, it's not open-sourced.

Relevant Links:

OAuth 2.0 and OpenID Connect SDK
Git

JOSE & JWT SDK
Git

Analysis:

As documented, the OAuth 2.0 and OpenID Connect SDK provides a comprehensive Java library for developing OAuth 2.0 and OpenID Connect clients and servers. It provides extensive support of the specs as documented here.

Reviewed the code base and was impressed with the overall design. Very clean, intuitive and extensible.

Based on the analysis, I would highly recommend it as one of the top choices for the internal implementation of Spring Security OAuth2 client and server.

[jgrandja]

Keycloak is an open source Identity and Access Management solution.

Keycloak is not a framework/SDK, rather, a full server solution providing user management, authentication and authorization capabilities.

However, it does provide the ability to extend the platform through it's underlying platform SDK.

It also provides an OAuth2 Client API based on JAX-RS.

Relevant Links:

Supported Features
Git

Analysis:

The OAuth2 Client API which is based on JAX-RS currently only supports the Authorization Code grant. It does not support Implicit, Resource Password or Client Credentials grant flow. Based on this alone, I wouldn't recommend this as a viable implementation option.

Reviewed the code base for server and client side of things and don't feel like the overall design will allow for easy extension and may get complicated.

The reference documentation is light and javadoc is missing. I found it difficult to navigate through things.

[jgrandja]

Apache Oltu is an OAuth protocol implementation in Java.

Relevant Links:

Source

Analysis:

Based on the Change Log, there isn't much activity in this project.

Reviewed the code base and feel the overall design needs updating.

[jgrandja]

oauth2-essentials is an OAuth2 java client implementation.

Relevant Links:

Source

Analysis:

Based on the project stats, this is a fairly new project with not many contributions to date.

Reviewed the code base and feel the project needs more work.

[jgrandja]

MITREid Connect is a reference implementation of the OpenID Connect protocol server and client, built on the Java, Spring, and Spring Security platforms. The server may also be used as a general-purpose OAuth 2.0 Authorization Server.

Relevant Links:

Wiki
Supported Features
Source
OpenID Connect Client

Analysis:

The Client implementation, which is filter-based, only supports the Authorization Code grant. There is no current support for a client supporting Implicit, Resource Password or Client Credentials grant flow. Based on this alone, I wouldn't recommend this as a viable implementation option.

However, I reviewed the code and found the overall design and implementation solid. The server integrates nicely with Spring Security and Spring Security OAuth.

I would strongly encourage collaboration with the core contributors, specifically Justin Richer, as we moved forward with the new OAuth2 initiative.

[jgrandja]

Google OAuth Client Library for Java

Relevant Links:

Source

Analysis:

The Client implementation only supports the Authorization Code grant through a Servlet-based implementation. This implementation has a serious limitation as it only supports the processing of 1 request at a time (a lock is obtained at the start of the service() method and released at the end).

The Implicit, Resource Password and Client Credentials grant flows are not supported by the client.

However, the requests are modelled for these 3 grant flows but are dependent on the Google HTTP client library.

For example, ClientCredentialsTokenRequest indirectly extends GenericData which is part of the Google HTTP client library. See source

Also, based on the project stats, most contributions were between 2012-2014 and have slowed down considerably since.

Based on these findings, I would not recommend this library as a viable implementation option.

[jgrandja]

This repository will temporarily house the new OAuth2 Client abstraction and implementation(s) as well as sample projects.