Add a question and answer section in this repo

[jessgoldq4]

Why is there no where to have a discussion for clarification on the often-times unclear documentation, or the intended functionality of certain parts of the package? (i.e, why aren't access tokens stored in a redis store when using the example redis adapter; reading the code didn't make it clear either)

I think it would be beneficial to have a place that's part of this repo to have these discussions or post issues

Thoughts?

[panva]

I think it would be beneficial to have a place that's part of this repo to have these discussions or post issues

I do not have the time or energy to do Q&A support for this module. Once upon a time the issue / discussions tracker was open for questions and free support. This only welcomed developers who, in my humble opinion, shouldn't attempt to do an identity provider of their own. As such, use the module as-is or don't, the goal of this module at this time is not to be a low barrier entry open source replacement for the plethora of feature-complete identity provider solutions that are available.

why aren't access tokens stored in a redis store when using the example redis adapter;

Opaque Access Tokens are stored in the adapter, where else would they be? Structured Access Tokens OTOH don't need to be stored.

[jessgoldq4]

Hi @Tiieb, thanks for the reply. That aligns with my understanding. Still curious on how it's handled when the session is expired

[panva]

Just one correcting point: this particular IdP module does not accept its own JWT structured tokens for any purpose. A structured JWT AT is always issued for a particular resource server which is not the IdP itself. So the JWT AT is either signed by the IdP and verifiable by the resource server it's accepted at, or it's encrypted for the resource server. Either way, there's no use for the AT at this IdP.

Hi @Tiieb, thanks for the reply. That aligns with my understanding. Still curious on how it's handled when the session is expired

It isn't. JWT structured tokens are self contained. Their status doesn't change throughout their lifetime.

[jessgoldq4]

Huh, curious. So even if the session is invalidated, the JWT is still alive... curious. I wonder if there's common strategies for revoking the token in that case. I can look into that on my own. Thanks @panva, appreciate it

[panva]

The point of a JWT AT is so that the resource server does not need to query the IdP for the status or contents of its authorization. Having the ability to do so would completely void the point of the JWT AT, at that point, use an opaque AT.

[JonasDoe]

Regarding the original topic: while I personally wished there was some Q&A section, I understand why it's not. That said, since this oidc-provider is most likely an enterprise solution, it's fair that you ask your company to support it. With that, you'll receive a more professional support.
I think we all know github projects of committed individuals which went down at some point b/c the maintainer suffered a breakdown from working 24/7 for it, for free. If this sponsoring is the most viable approach to prevent that - so be it 🤷‍♂️.