Configuration of spring-addons-starter-oidc to match default spring-boot-starter-oauth2-client behaviour

[Kevinbarre]

Is your feature request related to a problem? Please describe.
Hello,

This is more a question, but I don't know how I can change the label of the issue.

I've followed the tutorial servlet-client and I'm now trying to have a similar configuration using the spring-addons-starter-oidc dependency, but it seems the multiple redirections don't work the same way, and I'm not sure if I'm configuring it correctly.

With the servlet-client tutorial, I have the following behavior on a @RestController with some @GetMapping routes:

1. I call an endpoint in my browser (example : http://localhost:3000/test)
2. /test endpoint responds with a HTTP 302 and redirects to http://localhost:3000/oauth2/authorization/myregistration (where myregistration is the name I configured in application.yaml under property spring.security.oauth2.client.registration )
3. /oauth2/authorization/myregistration endpoint also responds with a HTTP 302 and redirects to the issuer-uri I configured under spring.security.oauth2.client.provider , adding some parameters, and notably the redirect_uri which contains value http://localhost:3000/login/oauth2/code/myregistration )
4. I submit login and consent on the OIDC provider pages
5. OIDC provider redirects to the http://localhost:3000/login/oauth2/code/myregistration described above
6. /login/oauth2/code/myregistration redirects to the initial endpoint but with a continue parameter: http://localhost:3000/test?continue (from what I read, this seems to be related to session cache).

This works whatever the initial endpoint was, as if /login/oauth2/code/myregistration knows what was the initial call it needs to redirect to.

And with the spring-addons-starter-oidc dependency, I have the following behavior on same controller / mapping routes:

1. I call an endpoint in my browser (example : http://localhost:3000/test)
2. /test endpoint responds with a HTTP 302 and redirects to ///login (without any hostname).
   a. I saw that if I manually configure the property com.c4-soft.springaddons.oidc.client.login-uri with /oauth2/authorization/myregistration , I can get the same behavior as above, but I don't understand why this is not the default behavior ? Am I supposed to implement a /login controller ?
3. /oauth2/authorization/myregistration endpoint also responds with a HTTP 302 and redirects to the issuer-uri, but this time redirect_uri parameter contains value /login/oauth2/code/myregistration (without the http://localhost:3000 hostname). As this URI is not configured on my OIDC provider, I get an error.
   a. I saw that if I manually configure the property com.c4-soft.springaddons.oidc.client.client-uri with http://localhost:3000, I can get the same behavior as above, but again I don't understand why this is not the default behavior ?
4. I submit login and consent on the OIDC provider pages
5. OIDC provider redirects to the http://localhost:3000/login/oauth2/code/myregistration described above
6. /login/oauth2/code/myregistration redirects to / (without any hostname, but the browser seems to understand this and tries to access http://localhost:3000/ which returns HTTP 404)
   a. Here I saw I can update my initial call to http://localhost:3000/test?post_login_success_uri=/test to get the final redirection working. But I find it strange to have to duplicate on each API call the endpoint I'm calling.

Describe the solution you'd like
Get the configuration working similarly to what is achieved with the tutorial using spring-boot-starter-oauth2-client, but with the benefits of spring-addons-starter-oidc security configuration

Describe alternatives you've considered
Using login-uri and client-uri for the first redirections to work, and query parameter post_login_success_uri for the last one. But I find it strange I have to override the properties to get back to the default behavior.

Additional context
I'm a beginner with Oauth2 and OIDC, so it's possible that I just completely misunderstood how to use or configure the spring-addons-starter-oidc dependency.

Thanks

[ch4mpy]

Questions are in the Discussions tab.

the redirect_uri which contains value http://localhost:3000/login/oauth2/code/myregistration

How Spring Security builds redirection URIs is not consistent between reactive and servlet apps and causes quite some issues in servlets for historical reasons. So, there is no universal default that spring-addons-starter-oidc can comply with.

I manually configure the property com.c4-soft.springaddons.oidc.client.client-uri

This enables using something else than the internal host name and port and is pretty convenient when using a reverse proxy (high availability, load balancing, sharing the same-origin for several apps, ...). It is recommended to set this property, even if not using a reverse proxy, and if a browser should use the request origin when redirecting to an URI without an authority. I could make this clearer in the docs.

General considerations

Do not answer 302 Redirect to login to unauthorized requests in a REST API

RESTful API response statuses should be meaningful, just as the HTTP verbs and the URIs. The status for Unauthorized is 401, not 302. Spring's default authentication entry point configuration is adapted to server-side rendered applications (Thymeleaf), not to REST APIs.

A decent REST client should handle 4xx responses properly. In the case of a 401, you may create a request interceptor and trigger login automatically if you want.

Such a request interceptor has at least three options to set the post-login route:

• compute it after the flow ended
• save the current route in the user agent's local storage and restore it after the flow ended
• provide it to spring-addons-starter-oidc as request param or header, which will save it in session and use it to redirect the user agent after the code was exchanged for tokens. We should remind that there are addons properties to set default values when the params/headers are not set.

Do not make @RestController stateful

By configuring a security filter chain as an OAuth2 client with oauth2Login, you're making it stateful: request authorization is based on sessions, not on Bearer tokens. This poorly scales. Instead, configure it as a stateless oauth2ResourceServer and, if it is consumed by Single-Page (Angular, React, Vue, ...) or mobile applications, put an OAuth2 BFF in front of it.

[Kevinbarre]

Hello @ch4mpy,

Thanks for answering quickly. I didn't know about the "Discussions" tab, I'll move there as I have further questions.