What's the current state of Shiro and OAuth2?

[Steinar Bang <sb...@dod.no>]

Something I've been wondering for a while, is "Why isn't OAuth on the
checklist of protocols supported by Shiro?"

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?

And what form should the OAuth support take?

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).

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)


References:
 [1] <https://issues.apache.org/jira/browse/SHIRO-119>
 [2] <https://issues.apache.org/jira/browse/SHIRO-119?focusedCommentId=15046629&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-15046629>
 [3] <https://oltu.apache.org>
 [4] <https://shiro.apache.org/integration.html>
 [5] <https://github.com/FeedTheCoffers/shiro-oauth>
 [6] <https://github.com/casdoor/shiro-casdoor>
 [7] <https://dzone.com/articles/how-to-use-apache-shiro-and-oauth-20-to-build-a-se>
 [8] <>

Re: What's the current state of Shiro and OAuth2?

[Steinar Bang <sb...@dod.no>]

>>>>> Steinar Bang <sb...@public.gmane.org>:

[snip!]
> I have googled a bit and this is what I found:
[snip!]

Missed this one from my first google round:
 https://github.com/bujiio/buji-pac4jn

From the description this seems to be adding OAuth capabilities to Shiro
(among other things).

And it has been recently touched: last commit is 5 days ago (at the time
of writing)

Re: What's the current state of Shiro and OAuth2?

[Brian Demers <bd...@apache.org>]

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 <sb...@dod.no> 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.