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] > > > >
