Benjamin, No worries we are on the same page :)
I absolutely agree with the cache issue between authc and authz. I've had to work around that a couple times. On Mon, Apr 6, 2020 at 10:42 AM Benjamin Marwell <[email protected]> wrote: > Agreed, no oauth server - I was just talking about validating bearer > tokens anyway. Didn't mention this, though. Sorry. > > Am Mo., 6. Apr. 2020 um 16:40 Uhr schrieb Brian Demers < > [email protected]>: > >> Personally I don't think Shiro should implement an Authorization Server, >> I think there is room for another project to implement on using Shiro (and >> Shiro would likely benefit from this). This is actually a major >> undertaking. The Spring Security folks tried to drop support for this >> recently: >> https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update >> IIRC, >> they are still supporting this use case though. >> >> I have a bias opinion on this topic, so someone else please chime in. In >> most cases, you probably wouldn't want to run your own >> authorization server, but instead, use a different one KeyCloak if you want >> to run it yourself, Okta, Microsoft, Google, etc if you don't. >> >> I could be in the minority here, what do others think? >> >> >> >> On Mon, Apr 6, 2020 at 4:21 AM Richard Adams <[email protected]> >> wrote: >> >>> A framework or implementation of standard authorisation server endpoints >>> such as /oauth/token for >>> standard grant types such as refresh_token, password, authorisation_code >>> etc. e.g described here https://aaronparecki.com/oauth-2-simplified/ >>> <https://aaronparecki.com/oauth-2-simplified/#authorization> >>> Could be a servlet filter, but if so should delegate to a handler which >>> can be used in other places e.g. Spring Interceptors, Controllers, >>> standalone applications etc. The Shiro approach of a standard >>> out-of-the-box implementation with lots of configurable /overridable >>> functionality would work well here, along with reference classes for the >>> various types of token. >>> E.g. anyone returning JSON of an OAuth token probably has a class >>> similar to this, simple enough but why reinvent the wheel every time. >>> >>> >>> >>> /** >>> * Represents the JSON response returned when refreshing / adding a new >>> OAuth token >>> */ >>> @Data >>> *public* *class* NewOAuthTokenResponse { >>> >>> @JsonProperty("access_token") >>> *private* String accessToken; >>> >>> @JsonProperty("refresh_token") >>> *private* String refreshToken; >>> >>> @JsonIgnore >>> *private* Instant expiryTime; >>> *private* String scope; >>> >>> @JsonProperty("token_type") >>> *private* *static* String *TOKEN_TYPE* = "bearer"; >>> >>> @JsonProperty("expires_in") >>> *public* Long expiresIn() { >>> *return* Duration. *between*(Instant. *now*(), >>> expiryTime).getSeconds(); >>> } >>> >>> } >>> >>> >>> On 05 April 2020 at 14:11 Brian Demers <[email protected]> wrote: >>> >>> OAuth support has been on the top of my list for a while too! We added a >>> bearer token filter in 1.5, but that is only part of the way there for just >>> one flow. >>> >>> Anything specific you are looking for? Resource Server? A standard >>> redirect (auth code flow)? OIDC support? etc >>> >>> -Brian >>> >>> On Apr 5, 2020, at 7:59 AM, Rob Young <[email protected]> wrote: >>> >>> Our org uses pac4j for doing oauth and I'd love to drop it, it's one too >>> many security libraries. It would be fantastic if shiro could provide this >>> natively. >>> >>> On Sun, Apr 5, 2020 at 7:47 AM Richard Adams < [email protected]> >>> wrote: >>> >>> I don't know if this is out of scope, or has been talked about already, >>> but providing some boiler-plate, best-practice standard OAuth2 flows would >>> be good, either for a client getting tokens, or an authorisation server >>> generating tokens. We've been implementing this sort of thing quite a bit >>> ourselves lately, we are no experts but there surely is a need not to >>> reinvent the wheel every time >>> >>> On 05 April 2020 at 12:32 Brian Demers < [email protected]> wrote: >>> >>> This one? >>> >>> >>> https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md >>> >>> -Brian >>> >>> On Apr 4, 2020, at 8:28 PM, Les Hazlewood < [email protected]> >>> wrote: >>> >>> I wrote a whole wiki page on 2.0 design changes, but I can't find it now >>> 🤔 >>> >>> On Sat, Apr 4, 2020, 5:17 PM Brian Demers < [email protected]> >>> wrote: >>> >>> +1 >>> >>> Off the top of my head we have (I'm sure there is more, but ): >>> >>> * Package name / artifact structure cleanup (breaking change, but minor >>> impact) >>> * Remove CAS modules >>> * Replace deprecated code (or move to an implementation/private package, >>> for anything still needed) >>> * Support javax.annotation.security annotations (or whatever they are >>> now under Eclipse). These annotations work a little different from the >>> Shiro ones. >>> >>> * Update to Jakarta dependencies (or figure out a way to work with both, >>> abstracting the HTTP logic), bigger lift (or maybe two different 'web' >>> packages?) >>> >>> The Jakarta ones have me a little worried though, I think many of the >>> current Shiro users would have a hard time making the switch anytime soon. >>> Which could kill the adoption of a 2.0. >>> We could (and probably should) abstract the web specifics out in order >>> to support the _current_ API, Jakarta EE, and other non-servlet stacks >>> (reactive). >>> That said, it's a likely a bunch of work (and again, I'm guessing most >>> of the user base would use the current API), so this _could_ be a 3.0 item. >>> >>> Thoughts? >>> >>> >>> >>> >>> >>> >>> On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < >>> [email protected]> wrote: >>> >>> Hi, >>> >>> I would like to start a thread about the next major release: 2.0.0. >>> I think we should move forward on it and only fix bug on the 1.x branches. >>> >>> There is always some issues related to the version in Jira: >>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455 >>> >>> We can move also the issues list from the 1.6.0 to the 2.0.0: >>> https://issues.apache.org/jira/projects/SHIRO/versions/12346916 >>> >>> I noticed an existing branch about api changes on github: >>> https://github.com/apache/shiro/tree/2.0-api-design-changes >>> >>> I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x branch (from >>> tag shiro-root-1.5.2) for maintenance. >>> >>> Because of some api break, package refactor, deprecated modules or >>> components, we also should start a migration guide in the website. >>> >>> It's also time for anyone to bring some ideas about the next Shiro >>> features/improvements, feel free to share :) >>> >>> We could start a formal vote to validate the plan. >>> >>> Feedback are welcome! >>> >>> regards, >>> >>> -- >>> Franç[email protected] >>> >>> >>> >>> >>> >>> >>> -- >>> Rob Young >>> [email protected] >>> >>> >>> >>> >>
