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