Mike replied to a comment about JWT's on the blog. Figured I'd also add it here for good measure.

Feel free to continue the discussion in the comments section of our blog.[1]

" JWT's are great. That's why they are used extensively in the OpenID Connect spec. The question is what's in that JWT? What are the claims? How do you know that the JWT that you got back in the response relates to the request you sent (i.e. Connect defines the nonce)? How do you know that the access token has not been modified (i.e. Connect defines the at_hash)? How do you know the code has not been modified (i.e. Connect defines the c_hash). How do you securely send the request? How does your client register and obtain tokens?

So yes, the puck is going towards JWT... but that's like saying the puck is going to JSON/REST... If you are using OAuth2 to authenticate a person, and you are using JWT, then you will have to define a lot of details to do so securely. Instead of making up your own recipe (which you probably don't have the time to do...), leverage the best practices defined by the experts at Google and Microsoft. "

[1] https://www.gluu.org/blog/oauth-vs-saml-vs-openid-connect/#c...

I totally agree with the lack of libraries!!! That's why we're working on oxd at Gluu: https://oxd.gluu.org

If you need a license, just email [email protected] It's not free open source, but it will be very inexpensive. It reduces OpenID Connect to a simple three step process (with three corresponding method calls):

1. Get code 2. Get tokens 3. Get user_info

There are two more supporting methods:

4. Register client 5. Logout

I wrote a sample cgi-bin application (and there is also a sample Flask application) that shows how to use it. https://github.com/GluuFederation/oxd-python/tree/master/dem...

Have a look at: https://github.com/juanifioren/django-oidc-provider

I know several Gov projects using it that are quite happy.

This project is a great OIDC provider, but a not-so-great OAuth 2.0 provider. For example, it doesn't support the client credentials grant type.

There's also Hydra, which looks pretty easy to deploy (fyi: I haven't used it): https://github.com/ory-am/hydra).

There's also an apache module (https://github.com/pingidentity/mod_auth_openidc) and some Lua you can plug into nginx (https://github.com/pingidentity/lua-resty-openidc) if you are going the reverse proxy approach.

Ah... so that must have been you on this issue: https://github.com/evonove/django-oauth-toolkit/issues/110

I think the main reason for that is that its not a simple thing to do and there's just not enough expertise out there.

Yes, that is me. I have the expertise, having maintained a fork of django-oauth2-provider for over a year; however, the issue with django-oauth-toolkit seems to be the lack of responsiveness on the part of the maintainers. We at edX are willing to contribute these features; but, we'd prefer not to maintain a long-term fork of the project.

We deal with supporting a range of languages by dropping a go proxy infront of the app.

https://github.com/gambol99/keycloak-proxy