Great questions! There are a few things in here, so I'll add some thoughts inline:
On Sat, May 21, 2022 at 4:03 AM Steinar Bang <[email protected]> wrote: > Something I've been wondering for a while, is "Why isn't OAuth on the > checklist of protocols supported by Shiro?" > As with anything, it comes down to time and volunteering. OAuth has been on my personal shortlist for a while. > > Doesn't OAuth fit in with the way Shiro works/is structured? Ie. doesn't > it make sense to pull OAuth in under the Shiro umbrella? > Yes, 100% > > And what form should the OAuth support take? > IMHO, Authorization Grant (the typical OAuth redirect) and Resource Server support (for REST APIs) would be the most useful. And likely OIDC support and related features. > > Should Shiro federate authentication and authorization to OAuth provided > by an outside provider (e.g. github, google, etc)? (I can see that this > would be useful) > > Should a Shiro realm be used to provide authorization and authentication > to OAuth authentiction and authorization providers? (I can see that this > would be useful, as well). > For resource server support, a new Realm would be needed to validate a bearer token rfc6750 (access token) The authorization grant (redirect) would need a servlet filter and a Realm. > I have googled a bit and this is what I found: > 1. A Shiro Jira with the title "OAuth support", pretty old and not > updated since 2015 > 2. The final comment[2] of [1] mentiones an apache library called > Oltu[3]. This was an OAuth library supporting both servers and > clients, but according to its wiki, it was retired in 2016 > 3. The shiro integrations page[4], lists two places that mentions > OAuth, one named OAuth, with a github link that returns 404[5] and > something named Shiro Casdoor[6] which looks like a login platform > that supports OAuth (I.e. the other way around, no OAuth support for > Shiro to be found here) > 4. The first google hit for "shiro oauth" is an article by someone > familiar from this list, called "How to Use Apache Shiro and OAuth > 2.0 to Build a Secure Application"[7] and describes how to secure a > JAX-RS API with authentication from an outside provider, named okta > and it uses something called okta-shiro-plugin[8] that provides a > realm that does OAuth 2 authentication against the provider Okta > (should this be mentioned on Shiro's integration page[4]?) > > And maybe the fact that the plugin is names okta-shiro-plugin, rather > than oauth2-shiro-plugin hints at the reason why SHIRO-119[1] hasn't > progressed further: OAuth differs so much in its implementation that one > basically need a different plugin for each provider? (Note: I don't > *know* this. I'm just guessing here) > The `okta-shiro-plugin` adds JWT validation of OAuth access tokens. Per the OAuth 2.0 spec, access tokens are opaque. However, they are commonly JWTs, which means different IDPs have different suggestions on how they should be validated (standard JWT validation plus specific claim data validation). A newer spec, RFC 9068 aims to fix this, though. Shiro could support both opaque access tokens and JWT access tokens per rfc9068. As you mentioned in a follow-up, there is buji-pac4j which also adds OAuth support, we could probably update the Shiro site with a pointer to that project to help folks find it.
