OpenID Connect

[lsmag]

Hello,

I was waiting for the approval of the OpenID Connect spec, and now it's approved, I wonder if you would like a pull request with that feature (the "OpenID connector" part on your roadmap refers to that, right?)

I'm already learning the Core spec to figure out how it can be implemented. It seems like a thin layer on top of OAuth2, for example the authentication part is done by a request to /o/authorize with "openid" as one of the scopes, and the token exchange now returns one more parameter, the ID Token.

There's two more (optional) specs, but my intent is implement the core on top of django-oauth-toolkit, since it seems enough to be an OpenID provider. I'm already reading django-oauth-toolkit's source code, but any tips are welcome.

So, what do you think?

[theloi]

Hi Ismag, I will definitely help you. I already had part of it working with django-oauth2-provider but then I realized that this oauth2 implementation has no support for the implicit flow yet. Now I wanted to start here or seperately using oauthlib directly. I am not sure yet if it would be a better idea to implement openid connect in the oauthlib itself. I guess not.

Anyways! Let's team up!

[synasius]

Hi @lsmag @theloi

I'm glad to hear that you would like to help improve DOT. We can use this issue to discuss about implementation details or you if need our support while surfing the code.

I guess you can start working on a draft in subpackage of oauth2_provider (a nested django app)

I am not sure yet if it would be a better idea to implement openid connect in the oauthlib itself. I guess not.

DOT itself is a thin layer built on top of oauthlib. It is mainly an adapter, which forwards requests to oauthlib and handles the response. So, what concerns the implementation and validation of the flow (e.g. a new flow, a new token type) should be in the latter.

[theloi]

Hi @synasius OK thanks! Yes, I guess the best way to go is to add a thin layer between oauthlib and DOT. This way we can leave oauthlib as is but can add support for the new ID_Token and tweak the flows as needed. After this we have to provide the appropriate hooks/triggers so that DOT can make use of it. In a subpackage of oauth2_provider we could then implement everything that does not belong do OIDC core like discovery and dynamic registration etc.

BTW: for the JSON Web Token handling I recommend pyjwkest which is available on pypi as of today (Thanks @rohe) and does unlike all other python jwt libriaries also support encryption of jwts. Short, it is complete!

@lsmag @synasius what do you think?

[lsmag]

Hi @theloi and @synasius ,

Great! I started hacking something today, just to get used to the source code. I already have a fork and will try implementing the first parts of the core spec, namely the authentication request (trigerred by the "openid" scope) and the Authorization Code Flow, what do you guys think?

[rohe]

7 mar 2014 kl. 17:50 skrev lsmag notifications@github.com:

Hi @theloi and @synasius ,

Great! I started hacking something today, just to get used to the source code. I already have a fork and will try implementing the first parts of the core spec, namely the authentication request (trigerred by the "openid" scope) and the Authorization Code Flow, what do you guys think?

OK, whenever you guys have something you think works we can test it against my code. https://github.com/rohe/pyoidc and https://github.com/rohe/oictest .

My oictest code is going to be the basis for the OpenID Consortiums verification tool. A tool that will be used to verify implementations of the OpenID Connect specification.

-- Roland "Education is the path from cocky ignorance to miserable uncertainty.” - Mark Twain

[theloi]

Thanks @rohe ! We will come back to you for testing.

Hei @lsmag,

I tried to make myself a picture of what we need to change or create to make this work. Here my thoughts that might help you to get going as well:

I think there has to be an on/off switch for openid connect (oidc) in the DOT settings.

If oidc is turned on then we have to add the following scopes „openid email, profile, address, phone, offline_access“ to the list of allowed scopes.

In oauthlib: Then we need to create a new server instance similar to 'Server' in oauthlib/oauthlib/oauth2/rfc6749/endpoints/pre_configured.py

For this new Server we need to extend possible response types to: “id_token“, “token id_token“, “code“. Maybe even more later on according to http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

Back in DOT: If oidc is enabled we need to use this new Server instead of the default one: django-oauth-toolkit/oauth2_provider/oauth2_backends.py: get_oauthlib_core and also in django-oauth-toolkit/oauth2_provider/views/base.py: class AuthorizationView

==> @synasius : Why is the 'Server' defined in two or even three places?

Again in oauthlib: For the new server we maybe(!) also need to write a new Authorization Endpoint as in: oauthlib/oauthlib/oauth2/rfc6749/endpoints/authorization.py

as well as new endpoints for response types „id_token“, “token id_token““. I think it is the easiest way to write new endpoints for the beginning. In later stages we might be able to reuse code… we will see.

Then we need to create a new token type e.g. BearerTokenWithIdToken or simply extend the existing: oauthlib / oauthlib / oauth2 / rfc6749 / tokens.py: class BearerToken

Back in DOT: there has to be a model for saving IDtokens and also a interface method in the validator class for saving it.

This is just a very brief overview of things that have to be changed... but we might find ourselfs on a totally different path after some time.

In my opinion this project should be split into two components: 1) oidclib which extends oauthlib for the needed functionality 2) DOT-oidc which contains all adaptions to DOT needed to make oidc work. If possible we should try to make it a subproject of DOT.

What do you think?

[lsmag]

Hey @theloi , sorry for taking too long to answer you.

I've been coding the Authorization Code Flow in my own branch of DOT, but now I think the best is just implement OIDC on OAuthlib instead, since it's not a Django-specific thing. Most of my code is OAuthlib related code, not DOT, anyway.

About your points on oauthlib's code: I think the current endpoint's implementation are generic enough, because they're mostly delegating to the grant_types and the request_validator, so maybe we need to just implement a new Server and new grant_types, (and, maybe, a new validator).

Shortly: I agree with 1), creating "oidclib", but inside oauthlib (I'll check if they agree with this).

[theloi]

@lsmag, you are awesome! this is exactly what I meant. You already lost me with your code.. so I guess I'll wait until you have something DOT like to test and I'll hook in again then. Let me know if I can help you with anything you in the meantime. I mean it!

[juanifioren]

Hi everyone ... I'm interesting in this. Anyone know the state of a possible implementation?. Thanks

[clintonb]

@lsmag What is the status of the OIDC integration?

[juanifioren]

@clintonb I follow both oauthlib and this project about their OIDC implementations but they seem to be stuck. Also was trying to implement it by my self but I ended up with a mess in oauthlib.

So I started from the ground up building a provider on top of Django. Check it out if u are interested:

https://github.com/juanifioren/django-oidc-provider

I recently test it with the OpenID Connect Drupal Module (with a fresh drupal installation) and the user logged in perfectly (also the account was created in drupal).

Theres a lot of things to improve and to add.

Greetings.

[clintonb]

Thanks @juanifiorien. We also built our own (https://github.com/edx/edx-oauth2-provider) atop django-oauth2-provider. That project, however, seems to have stalled. I was hoping to transition to toolkit and take advantage of other features (e.g. client registration views) instead of starting from scratch.

[clintonb]

@juanifioren ^

[juanifioren]

I'll check it out, thanks @clintonb

[clintonb]

Has anyone made any progress on adding OIDC support to this project?

[markslwong]

This feature would certainly help me :+1: I would volunteer to help, but when it comes to framework code... I'm not sure you want a primarily C# and C++ developer making pull requests.

[ntcong]

There's some process lately in order to support openid connect in oauthlib: https://github.com/idan/oauthlib/pull/416

[joelstevenson]

Hello DOT-ers, FWIW I have a fork of DOT that integrates at a basic level with the oauthlib PR #416 @ntcong mentioned. This is a minimal implementation I needed to get the basic Authorization Code flow completed. I'd appreciate any feedback you all might have and any ideas for improvements or different approaches.

[ntcong]

@joelstevenson Now that oauthlib's openid connect implement was merged, I think it's a good time to make a PR request ?

[pichlou]

@juanifioren @clintonb which one of the OIDC provider and the edX OAuth2 Provider is better for using in Django application on edx-platform?(please write reasons of your choice)

[clintonb]

@pichlou we are planning to abandon usage of OIDC. The limited library support, and lack of time/resources on our part to add support to DOT, makes it difficult to continue using OIDC. That being said, our two years of using it have taught us a lot. Particularly, OIDC at is core is just OAuth with a short-lived JWT access token. Given that we already plan to switch to JWT access tokens, we are already partially where we want to be.

I'm happy to share more in the edX architecture Slack channel.

[pichlou]

Thanks @clintonb ! So you recommend using edX OAuth2 Provider in this case?

[juanifioren]

@pichlou It depends on your needs. django-oidc-provider is an active project which provides a robust platform for SSO based on OIDC and OAuth2.

Cool features of DOP:

• Session management support.
• Manage your clients easily using django admin (choose id_token alg, automatic secret and id).
• PKCE support for mobile implementations (you can use AppAuth-iOS and AppAuth-Android).
• You can create your custom scopes and claims.
• Add custom data inside ID Tokens to fit your needs.
• Refresh token flow support.
• A lot more things, just read our docs http://django-oidc-provider.readthedocs.io/

Any other question please contact me. Regards!

[pichlou]

Many thanks @juanifioren ! I wish you luck ...

[wiliamsouza]

Maybe someone have interest on this PR https://github.com/idan/oauthlib/pull/484

[jleclanche]

@juanifioren How similar is django-oidc-provider to django-oauth-toolkit? Would it make sense to merge the two libs? (I'm up for helping in that regard, or at least making our APIs more consistent across one another)

[juanifioren]

@jleclanche libs have differents approaches. DOP is a django-app for easily implement OIDC in your project. DOT is for developers and you need to put some code to make it works. That's what I think.

[jleclanche]

The reason I was asking is because DOP has PKCE support, which DOT should really support as well. Hmm...

[wiliamsouza]

Work in progress https://github.com/evonove/django-oauth-toolkit/pull/545 would be great to have some inputs.

[n2ygk]

Target is to reintegrate reverted PR #859