Loomio
Tue 7 May 2013 8:08PM

An authentication model for third party apps

AH Aruna Herath Public Seen by 188

I give a flow of things that'll happen in the model I propose.

1 User provides Diaspora ID to the app.

2 App contacts the user pod, provides the username, access scopes necessary, and developer (author) id (Diaspora ID of the developer) . Redirect user to login page.

3 User gives her username and password and agrees to allow the application to access her data. Access scopes the app requested are displayed to the user.

4 Application is granted an refresh token which is sent to the developer's pod encrypted for the developer. app must have the ability to securely retrieve the token from the developers pod.

This model uses the developer ID as the trust anchor, refresh tokens (which are temporal, lasting for a limited time) are used to get access tokens.
Use access scopes to define what apps are allowed to do on users data.

AI

Akila Iroshan Fri 21 Mar 2014 3:38AM

Here is the current implementation of above discussed authentication model. We are waiting for code review and comments to move forwards. Please share your opinions to improve this authentication model

Thanks :)

D

diasp_eu Fri 21 Mar 2014 12:41PM

@akilairoshan Wow thanks +1

G

goob Fri 21 Mar 2014 12:53PM

@akilairoshan it might be worth posting a reminder that you're waiting for code review on that Github issue in the hope that someone competent to do so (which, I'm afraid, I'm not) can look at it.

JR

Jason Robinson Thu 9 Apr 2015 7:36PM

Now that there is a $400 dollar bounty on implementing an API, I think it would be a good idea to decide on what would be an acceptable implementation for creating an API. As everyone knows, the tricky part is not making the API itself, but getting the authentication system done.

The previous work here specced out by @jhass and worked on by @arunaherath didn't complete, so I guess we are looking at other options - or would we still want this spec to be the baseline for an implementation?

Personally, I think we should keep it as simple as possible. I'm not sure we need to tackle scopes and manifests and so on in the first version. Just a simple "full or none" access to the account. The API feature set is likely to be very limited anyway to start with. Build tiny things, then iterate.

Anyway, I think @jhass was also looking into OpenID at some point? How would that work, I assume the idea is that each pod becomes an OpenID Connect provider? Here is the most recent Rails gem I found: https://github.com/nov/openid_connect

Would it be possible for us to lock some "would be accepted" spec regarding the API authorization model so that we can say at least "hey here is the issue feel free to work on it". Right now it's "hey here is an issue but please don't work on it even though people have paid $400 since we don't have a spec" :)

JH

Jonne Haß Thu 9 Apr 2015 10:26PM

Yes, back when I wrote the above up, OpenID Connect was not released yet, these days we should just implement it.

ST

Sean Tilley Sun 12 Apr 2015 2:17AM

Yeah, I definitely think OpenID Connect is likely the best way to go at the moment. It might be worth taking a look at the Ruby OpenID Connect gem.

DU

Deleted account Sat 6 Jun 2015 6:33PM

Hi guys. Just providing some informations to keep the community in touch. I've started to play with the OpenID Connect gem inside a mock project. For now, I managed to go through the beginning of the OpenID classic handshake, that is, the 2 first steps on the following official diagramm:

I also took a look at the way to integrate smoothly with the existing management system which is Devise. If I'm not wrong, Devise uses OmniAuth, which has an OpenID plugin. So, things are going the right way.

Anyway, I'll continue to give informations regularly on that post.