11
votes

In my current project I use in a full scope the Spring Security OAuth (http://projects.spring.io/spring-security-oauth/) project to protect our resources (Web API). Everything works fine till now.

I'm now working on the development of the clients and I'm looking for a good support for the authentication scenarios (as OAuth is an authorization protocol). After long, long internet search I'm quite sure I should take the OpenID Connect (http://openid.net/connect/) to fulfill this requirement, as it is "a simple identity layer on top of OAuth 2.0" (I know however, there is no "simple" in case of security topics).

Sad but true I'm not able to find any good resources about the support for OpenID Connect (not to confuse with "pure" OpenID) in Spring Security. There is a OpenID Connect reference implementation at https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server but I have expected something similar direct in/from Spring Security with comprehensive documentation and so on. I have found about 2 years old discussion about it here https://github.com/spring-projects/spring-security-oauth/issues/220 but what is the current status? Looking for "Spring Security support for OpenID Connect" does not deliver any "tangible" results.

Do you have any infos, documentation and/or experience regarding implementation of the OpenID Connect with the help of Spring Security?

1

1 Answers

3
votes

Before OpenID Connect emerged, it was practically okay to assume that the value of the request parameter response_type be either code (for authorization code flow) or token (for implicit flow). However, now an authorization server implementation must be able to handle any combination of (code, token, id_token), and none. Details are described in "OpenID Connect Core 1.0, 3. Authentication" and "OAuth 2.0 Multiple Response Type Encoding Practices".

As the first step to support OpenID Connect, Spring Security OAuth has to become flexible for response_type. You can find a request for it at "Issue 619: Handling additional response_types". However, it is hard to change an existing code that expects only either code or token to a new one that can accept multiple values at a time. As of this writing, the lastest comment of Issue 619 made on Dec. 12, 2015 ends with a sentence as excerpted below.

Any comments are more than welcome as this turned out to be (as I predicted) a large refactor exercise.

If Spring Security OAuth is purely a voluntary project without any support from commercial bodies, such a big change would be unlikely to happen.

My experience: About two years ago, I wrote an OAuth 2.0 server from scratch. It was after it that I knew of the existence of OpenID Connect. After reading specifications related to OpenID Connect, I finally reached a conclusion to dump the existing implementation and re-write the server from scratch again.

As you guessed, OpenID Connect is not simple at all.

See also "5. Response Type" in "Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings".


Update

Authorization Server and OpenID Provider on Spring Framework
https://github.com/authlete/spring-oauth-server

Resource Server on Spring Framework
https://github.com/authlete/spring-resource-server

spring-oauth-server supports OAuth 2.0 and OpenID Connect. spring-resource-server has an implementation of UserInfo Endpoint which is defined in "OpenID Connect 1.0, 5.3. UserInfo Endpoint". Both implementations don't use Spring Security OAuth but use Spring Boot and Authlete.

Blog: Spring + OAuth 2.0 + OpenID Connect