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

[Kevinbarre]

Following #244

Hello @ch4mpy ,

As you're suggesting, I'll keep the configuration for the property com.c4-soft.springaddons.oidc.client.client-uri.

What about property com.c4-soft.springaddons.oidc.client.login-uri ? Should I also set it manually to /oauth2/authorization/myregistration , or am I supposed to implement a /login controller ?

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

I saw the documentation about this part. I've been experimenting with the properties :

oauth2-redirections:
  authentication-entry-point: unauthorized
  pre-authorization-code: ok

but I've noticed that for testing login process with the browser it was a bit more difficult, as it didn't handle the redirection automatically. I'll set this back on the final configuration.

And if I understand correctly, it would be the front-end app responsibility to handle the post-login redirection, but only in case the first call answers 401 ?

Do not make @RestController stateful

It's something that I've been wondering lately after experimenting with the tutorials. I'm currently working on a small app with a single monolithic back-end in production. At the moment, authentication with the OIDC provider is done manually directly in the front-end app, which has caused security alerts, and they are now requesting to move this part to the back-end.

I was first thinking about introducing an additional stateful BFF spring boot app, and keeping the current backend as-is, but I noticed an issue here. Current authorization process is done based on a custom field that is returned as part of the ID token (provided by the front-end app), which is then mapped to a SimpleGrantedAuthority('ROLE_XXX') depending on some mapping configuration retrieved from the database, then used as part of the @PreAuthorize("hasRole('XXX')") on the controllers.

I'd like to instead use an access token as recommended for Oauth2, but I noticed that the access token I get is an opaque token, not a JWT, so I don't have access to the custom field in the resource server to generate the SimpleGrantedAuthority. I also tried to generate the SimpleGrantedAuthority in the client, which is working as it gets the ID token, but then I think it's not included in the call to the resource server and is lost.

So I was wondering if it was acceptable to only keep the client as part of the back-end API, and indeed making it stateful and less scalable, but as least more secured that it is currently is ?

Thanks

[ch4mpy]

What about property com.c4-soft.springaddons.oidc.client.login-uri

You shouldn't have to set it, the defaults are fine.

I've noticed that for testing login process with the browser it was a bit more difficult

Without the help of a Single-Page Application framework (Angular, React, Vue, ...), browsers are bad REST clients. Use a tool like Postman instead. You'll be able to send any kind of request in addition to GET (notably POST, PUT, and DELETE). Also, it includes features to get access tokens from an OAuth2 authorization server, and authorize requests to your resource servers with it.

if it was acceptable to only keep the client as part of the back-end API

If the load for this service is low and will always be, yes it could be acceptable. But honestly, a Spring Cloud Gateway packaged as a native image has such a small impact on a production environment, that I'd probably use one in any case, unless the production environment has absolutely nothing to monitor and keep a healthy instance automatically.

Be aware that in this situation, the requests to your REST API will require a cookie for a valid session to be authorized. If using a REST client like Postman, this can be tricky.

a custom field that is returned as part of the ID token (provided by the front-end app), which is then mapped to a SimpleGrantedAuthority('ROLE_XXX') depending on some mapping configuration retrieved from the database

This database loop for each request is a waste of resources. It would be much better if the authorization server did this DB query and added all the data necessary for access control to token claims.

the access token I get is an opaque token

This is bad news for performance: opaque tokens must be introspected, which means a round-trip to the authorization server for each request to a resource server. This adds more latency to requests processing than decoding a JWT. Worse, if the authorization server is shared by many apps and if the global traffic increases, introspection can become a bottleneck (it can sort of DDoS the authorization server).

What is your authorization server?

Why does it issue opaque access tokens? What have you tried to get JWTs instead?

[Kevinbarre]

Hello @ch4mpy,

Is it your Spring OAuth2 client with oauth2Login running on port 3000?

Yes, I had to temporarily reconfigure it on port 3000, as this was the configured redirect_uri on the Authorization server. The new URI has been added, and now I've set it back to client-uri: http://localhost:8080. But I can't figure out what this /login endpoint is, and how it should interact with Spring's /oauth2/authorization/myregistration

When using spring-cloud-starter-gateway-mvc, remove the SaveSession filter (it is specific to spring-cloud-starter-gateway)

OK thanks, indeed it is now working. As the tutorial was saying it was the most important part, I didn't thought about removing it !

As a side note, I'll be in metropolitan France in April (I'm usually in French Polynesia). If your team is interested, we could plan an on-site training session about users' authentication and authorization with OAuth2/OpenID, and maybe with some tips for writing REST APIs with Spring

Thanks for the offer. I'm leaving the company in March, so I won't be able to attend, but I forwarded your message to my team.

[ch4mpy]

About the SaveSession filter, the tutorial was created two years ago, at a time when spring-cloud-starter-gateway-mvc did not exist. If you have a close look at dependencies, you'll see that it is using spring-cloud-starter-gateway ;)

I can't figure out what this /login endpoint is

It is a login page rendered by MVC @Controller. If you keep defaults, a template is provided by Spring and, if there is only one registration with oauth2Login, the controller redirects to /oauth2/authorization/myregistration instead of rendering the template.

In the BFF tutorial, it is not desired that UI elements are rendered on the server. So, the BFF exposes a REST endpoint with all the /oauth2/authorization/{registrationId} (one per registration with oauth2Login, so usually only one). When needing to log a user in, the frontends call this endpoint and redirect to /oauth2/authorization/{registrationId}. So, the /login endpoint is never called (and as the tutorial is configured with only one oauth2Login registration, the page wouldn't be rendered, it would just be an unnecessary redirection).

[Kevinbarre]

It is a login page rendered by MVC @controller. If you keep defaults, a template is provided by Spring and, if there is only one registration with oauth2Login, the controller redirects to /oauth2/authorization/myregistration instead of rendering the template.

OK, there's probably some configuration I'm missing then, as this default /login template is not rendered by the application. Instead, I get an infinite loop of HTTP 302, redirecting to itself, causing a ERR_TOO_MANY_REDIRECTS on the browser.

[ch4mpy]

Access to /login should be allowed for anonymous requests (added to permitAll). But again, this is something you should need only when building a server-side rendered application (Thymeleaf, JSP, etc.).

If using spring-addons-starter-oidc, spring-boot-starter-oauth2-client, and spring-boot-starter-oauth2-resource-server, be careful that you have two SecurityFilterChain beans. As you probably want this /login endpoint to be processed by the "client" filter chain, make sure that it is added to the security-matchers and permit-all properties under com.c4-soft.springaddons.oidc.client.

Last the default template is provided by Spring only if no explicit configuration is provided for the login-uri. Leave it empty if you want the default template to be available. If you set this property, you must provide a @Controller to handle the endpoint.

[Kevinbarre]

Hello @ch4mpy,

Access to /login should be allowed for anonymous requests (added to permitAll). But again, this is something you should need only when building a server-side rendered application (Thymeleaf, JSP, etc.).

I agree, I'd prefer not to have this redirection to /login, but it seems to be configured by default, unless I set the login-uri property (which I'll probably end up doing I guess, as I can't find any other way to bypass this /login endpoint). But I understand that this is only for testing, and the definitive way is to return a HTTP 401, so the front-end can perform its redirection by itself.

If using spring-addons-starter-oidc, spring-boot-starter-oauth2-client, and spring-boot-starter-oauth2-resource-server, be careful that you have two SecurityFilterChain beans. As you probably want this /login endpoint to be processed by the "client" filter chain, make sure that it is added to the security-matchers and permit-all properties under com.c4-soft.springaddons.oidc.client.

I didn't add spring-boot-starter-oauth2-resource-server dependency to the back-end application, only spring-addons-starter-oidc and spring-boot-starter-oauth2-client, so I guess I only have a single SecurityFilterChain bean. Currently, security-matchers is configured with /** (so I think all requests go through it), and permit-all is configured with /login/** (I also tried adding /login with no more success) and /oauth2/**, so I guess it should work, but /login goes to this infinite loop and I don't understand why.

Last the default template is provided by Spring only if no explicit configuration is provided for the login-uri. Leave it empty if you want the default template to be available. If you set this property, you must provide a @controller to handle the endpoint.

I get the issue when I don't provide value for login-uri. That's why for now I set it to /oauth2/authorization/myregistration, but I'd like to avoid overriding this if possible