Steve Riesenberg

Hi @CrazyParanoid, thanks for providing those details. Generally, device code provides an OAuth2 flow for devices that are input constrained, meaning there's no keyboard or it is not convenient to...

Thanks for the additional details, @CrazyParanoid. I think it's important for cases like this to identify one or two solid use cases to understand how this support might be used...

@CrazyParanoid as you may know, we generally prioritize features based on community upvotes on issues. Currently, this issue only has one upvote (👍) after being opened over a year, which...

No updates at this time, @colin-riddell. If you get to the point where you have a clearly defined need for the device flow in your client, it would be extremely...

Hey @colin-riddell. > This wouldn't be to support a Spring Application based client at all. Ok. So it sounds like you would only have use for the Spring Authorization Server...

I apologize for the delay in responding, @cmark. Thanks for reaching out and for providing a reproducer! > **Expected behavior** > Setting `Cache-Control`/`Expires`/`Pragma` headers in async request processing context should...

@lowcasz thanks for reaching out! > Customizing this behaviour is problematic now. > > jwtCustomizer should allow add custom JwtGrantedAuthoritiesConverter, or additional logic to obtain extra authorities. The docs already...

@lowcasz thanks for your reply. > The most important and make life easier is I would use default converter logic, but add additional authorities using custom logic. It sounds like...

Thanks for the report @DaceKonn! I'm not sure I agree with classifying this as a bug, and instead feel this might make a good enhancement request. I don't find anywhere...

Hi @MammosGeorgios. I'm mainly filing this issue now so we have it on the radar in time to begin the cycle on 7.0.x in May or June (whenever we switch...