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/
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 <brian.dem...@gmail.com> 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 <bobbot...@gmail.com> 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 < rich...@researchspace.com> 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 timeOn 05 April 2020 at 12:32 Brian Demers < brian.dem...@gmail.com> 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 < lhazlew...@apache.org> 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 < brian.dem...@gmail.com> 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 < francois.pa...@openobject.fr> 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çois fpa...@apache.org
--
