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