Using Vanilla Authentication for outside apps?

akumpf

Is it possible to use Vanilla to grant/deny access to an outside app?

I have a site with a few major components (the Vanilla community/forum being one of the majors ones), and I'd like to use the account created via Vanilla to enable/deny access to other tools. For example, a user logged in to the site (via Vanilla) could then manage photos, music, etc. in an outside app as that user.

Specifically, Is it possible for a php file in an outside directory to call to Vanilla with a username/password and verify that the login info is correct? I could directly query the database, but that seems suboptimal...

I realize it's not the core mission of Vanilla to be an authenticator for outside apps, but it would be super helpful for integrating to sites that use a community forum as only part of the experience. Thoughts?

Thanks!
Adam

Todd

We've done a tonne of work on SSO, but mostly from using Vanilla as the slave to another system so to speak.

I do want to be able to make Vanilla the master user system for stuff for sure. To me though @ddumont is on the right track with oauth. Why? One is that it's a standard at this point and two is that it works cross-domain and with non-browser systems.

The use case where you want to have Vanilla and another system all on the same server is fine, but not scalable and not what we want in terms of being able to connect different sites/devices together. That's the future to me.

To answer your thoughts specifically @akumpf. If you were already signed on to Vanilla then went to your child site you would not be automatically signed in, but when you click the "Vanilla Connect" style button and you program your other site properly then you don't get another sign in page, but are instead signed right in. This is because you are already cookied on Vanilla.

If I wanted to make the process a bit nicer on a same domain system then I would check for the Vanilla cookie and if it's there, but I'm not signed in then I would redirect to your connect page with an instruction to connect right back once things are synched up.

Single sign on is not easy and we've done a tonne of work with it. The most difficult part is not actually navigating the profiles, but synching the user in your system with the user in the remote system.

ddumont

I've been eagerly awaiting @Todd to free up a bit and discuss having vanilla be an oauth provider

akumpf

Oauth is awesome, but I don't think it really fits the bill for me in this case. There are two scenarios I'd like to accommodate if possible:

1. Server-side communication to authenticate an outside PHP file performing an action. Given that the user inputs their username/password, it'd be great to have the outside tool just include a php file from Vanilla, and then ask if the username/password pair is valid.

2. An outside tool should be able to tell if the user is logged in to Vanilla (on the same domain, different directory) -- probably via a cookie/session variable. If not, they could be redirected to the forum login, and then routed back after authenticated. I'm guessing some kind of php include would be needed here too to ensure the cookie is not a spoof.

garymardell

The second scenario you described is from my understanding what OAuth is. It's the same way you can connect via twitter and login if you are not.

akumpf

But from the user's perspective, I think they would still need to login separately via Oauth for something that is part of the same site (even if they're already logged into the forum).

Am I missing something here with Oauth? If I login to the forum, then go to another part of the site (outside of the forum), will Oauth know I'm already logged in? I'm pretty sure a separate login would be needed, and thus break the seamlessness...

The redirected login I was envisioning for #2 was only in the event that the user isn't logged into the forum.

Todd

We've done a tonne of work on SSO, but mostly from using Vanilla as the slave to another system so to speak.

I do want to be able to make Vanilla the master user system for stuff for sure. To me though @ddumont is on the right track with oauth. Why? One is that it's a standard at this point and two is that it works cross-domain and with non-browser systems.

The use case where you want to have Vanilla and another system all on the same server is fine, but not scalable and not what we want in terms of being able to connect different sites/devices together. That's the future to me.

To answer your thoughts specifically @akumpf. If you were already signed on to Vanilla then went to your child site you would not be automatically signed in, but when you click the "Vanilla Connect" style button and you program your other site properly then you don't get another sign in page, but are instead signed right in. This is because you are already cookied on Vanilla.

If I wanted to make the process a bit nicer on a same domain system then I would check for the Vanilla cookie and if it's there, but I'm not signed in then I would redirect to your connect page with an instruction to connect right back once things are synched up.

Single sign on is not easy and we've done a tonne of work with it. The most difficult part is not actually navigating the profiles, but synching the user in your system with the user in the remote system.

akumpf

Thanks for the response @Todd. I now have a much better understanding of your design choices and suggestions.

judgej

@akumpf I'm not sure the session would be seamless across sites. oauth does provide some authentication functionality, but it is more about providing authorisation to share user data. It could be used with SSO, but would need keys to be pre-shared between the systems that it supports so the user is not stopped each time to authorise the sharing of details. I asked that question to the guy who just released the final spec to oauth 2.0 last week, and that was his answer. Authentication: yes; SSO: not really. However, other protocols work alongside it to provide the SSO part.

Another protocol I've been looking at recently is SAML. http://simplesamlphp.org/ looks like a great library and seems to have plugins for every kind of back-end authentication you can imagine. It might be worth following up.

The basic idea would be that simpleSAMLphp uses a custom script to authenticate users against the Vanilla database (or APIs) and that then serves as an identity provider for other sites. The SAML protocol is all front-side, with all messages passed via the browser with various encryptions.