How-to: Use Spring Authorization server behind Spring Cloud Gateway

[rcbandit111]

Publish a guide on How-to: Implement the core services behind Spring Cloud Gateway:

[sjohnr]

Related #499

[rcbandit111]

When I can expect this guide?

[rcbandit111]

Kind remind guys. I will appreciate it if someone write me some configuration steps before official documentation is ready.

[jgrandja]

@rcbandit111 It will be a while before we get to this as there are a few higher priority tasks we need to work on first.

If someone in the community can help that would be great. cc @spencergibb

[rcbandit111]

@jgrandja Thank you for the response. I will wait further information.

[jacko9et]

No additional configuration is required if it is only used behind a gateway. However, in the case of load balancing, spring session support is required, because the server uses session to associate authentication actions.

[salutonmondo]

Is this suit your needs #807

[sjohnr]

@salutonmondo I believe this issue is addressing using Spring Authorization Server behind Spring Cloud Gateway, whereas the sample you submitted treats SAS as an identity provider but does not route the requests to it. When we look more deeply at this issue, we'll have to think about what use cases make sense for putting SAS behind the gateway. One that I can think of, for example, is rate limiting to protect the authorization server or specific endpoints from malicious clients.

[uniquejava]

@salutonmondo Thanks for your demo, I added some comments there in your #807, could you shed some light?

[zhoyq-work]

use database to share data between auth servers, this can reslove load balancing problem.

[zhenhe]

any update recently?

[maradanasai]

Hi, any update?

[uniquejava]

I once needed this, after some research, I found what I really need is how to use spring cloud gateway as resource server and verify token from this single point. Finally I managed to do this, and I don't think I need the auth server sit behind spring cloud gateway now. Here is my current demo architecture.

The benefit: I just verify token from spring cloud gateway and pass the resolved user id as http header to my downstream micro-services and all my microservices now don't even have a dependency on spring security.

I once used spring cloud gateway as oauth2 client, --- almost each tutorial on the internet do this, and I think that is too academic/complex and not feasible at all in a real large application.

[zhenhe]

I once needed this, after some research, I found what I really need is how to use spring cloud gateway as resource server and verify token from this single point. Finally I managed to do this, and I don't think I need the auth server sit behind spring cloud gateway now. Here is my current demo architecture.

The benefit: I just verify token from spring cloud gateway and pass the resolved user id as http header to my downstream micro-services and all my microservices now don't even have a dependency on spring security.

I once used spring cloud gateway as oauth2 client, --- almost each tutorial on the internet do this, and I think that is too academic/complex and not feasible at all in a real large application.

good advice，how scg do both verify token and then pass request ？ use filter？

[uniquejava]

@zhenhe Yes, a single UserHeaderFilter will do the job, and here is an example: https://stackoverflow.com/a/71485398/2497876

[daphdev]

I once needed this, after some research, I found what I really need is how to use spring cloud gateway as resource server and verify token from this single point. Finally I managed to do this, and I don't think I need the auth server sit behind spring cloud gateway now. Here is my current demo architecture.

The benefit: I just verify token from spring cloud gateway and pass the resolved user id as http header to my downstream micro-services and all my microservices now don't even have a dependency on spring security.

I once used spring cloud gateway as oauth2 client, --- almost each tutorial on the internet do this, and I think that is too academic/complex and not feasible at all in a real large application.

Hi. Can you make a sample repo? Many thanks.

[Crain-32]

Hey @jgrandja, I've encountered this issue myself at work, and would be willing to write up the documentation if I could get some help getting it working in a Spring Preferred way.

I know it was declined, but since I haven't contributed to Spring Authorization before, I have written documentation for Validation in Spring Boot.

The issues I'm seeing are that Spring Authorization Server currently holds the client information within a Session Context. This is fine (and the preferred security option), however for the Token to be passed through the Gateway that Session either needs to be shared between the Authorization Server and the Gateway (Spring Session likely works, just unsure the proper configuration/dependencies), or some changes to the flow so that the gateway has the Session -> Token link instead.

The flow works as expected when the Authorization Server is the Identity Provider and the Gateway is the client. But that isn't always possible.

Some thoughts I've had are that you put the Authorization Server into the Gateway Application, so that way the Gateway/Authorization are in the same place. This works for when you're using a 3rd Party Identity Provider. However isn't really a preferred "Microservice" pattern. For example in the flow I'm aiming for (which is vague enough I can share) I would like to do the following.

• Unauthenticated User hits Spring Gateway
• Redirect /login, routes to Spring Authorization Server
• Authorization Server flows through one of several Identity Providers
• On getting the Access Token, Adjust Claims (Documented already here, and is why I'm not just having the Gateway be a direct client to the Provider)
• Access/Refresh Token gets passed to the Gateway, which will convert the Session Cookie into the Token (Using the TokenRelay Filter)
• Request is forwarded to the proper location with the Access Token
• Token Refresh is handled by the Gateway.

I'd also be fine if the flow was using Spring Session to Distribute the information between the Authorization Server and Gateway.

If you'd like, I can share a repository with an example setup. Being Eureka, a Gateway, Authorization Server, and Dummy API.

[Crain-32]

Example Setup can be found here.

[Crain-32]

Minor update.
I've attempted Distribution of information with Spring Session and a backer like Redis. It didn't work.

I've attempted using a ProxyExchange Approach instead of the typical links, it appears without some level of Special handling in the gateway putting the Authorization Server behind it just isn't possible.

[jgrandja]

@Crain-32 To be honest, I'm still finding it difficult to understand a use case on why an application would need to integrate Spring Authorization Server "behind" Spring Cloud Gateway. It makes perfect sense to me to integrate an OAuth2 Client within Spring Cloud Gateway, however, not the former.

The issues I'm seeing are that Spring Authorization Server currently holds the client information within a Session Context. This is fine (and the preferred security option), however for the Token to be passed through the Gateway that Session either needs to be shared between the Authorization Server and the Gateway

Why do you need to share the Spring Authorization Server session with Spring Cloud Gateway? Please provide more details and specifically the data you need shared.

[sjohnr]

@Crain-32 In an effort to keep this issue focused, I'm going to mark a number of comments in our recent discussion as off-topic. GitHub will maintain the comments as hidden in case you want to revisit them and use them for opening up new issues. Thank you for understanding as we work to keep the issue tracker accessible and useful for everyone.

To re-cap, the two primary use cases I'm aware of for Spring Cloud Gateway and Spring Authorization Server are as follows:

1. Proxy the auth server behind the gateway - This could be useful for adding features like rate limiting (see comment), load balancing and high availability to the auth server. In this scenario, only the gateway is public facing.
2. Proxy resource servers behind the gateway and use the gateway as an OAuth2 Client with the TokenRelay filter to adapt from sessions to access tokens - In this scenario, the auth server and the gateway are both public facing. This is the BFF (backend-for-frontend) use case.

This issue addresses (1) above. I will open a new issue for (2).