- Moodle will support Oauth2 authentication with a Google and Facebook account. There is a working version that you can test at MDL-34426.
The Oauth2 authentication specifications are there: http://docs.moodle.org/dev/Oauth2_authentication
- Make Moodle an Oauth2 provider.
- we will implement Oauth1 authentication with your twitter account or linked.
- Brainstorming / specification about removing Mnet
- Remove Mnet (in accordance with everyone)
Any plans to replace Mnet with something else?
the idea is, in a first stage, to replace Mnet authentication by Oauth2. I suppose most sites only use Mnet for the SSO feature. Then the migration to Oauth2 should be easy for them. Maybe we can detect site with Mnet setup without enrolment and then automatically switch them to Oauth2.
The tricky bit will be for site using Mnet beyond the SSO. Replacing enrolment features will need a real brainstorming. The idea atm is to use the web service to replace all other Mnet features. We'll specially check with the Mahara team (ps: I don't know who's in the Mahara team atm but I'll look for you if I'm in charge of this change ;)).
Removing Mnet from 2.6 is the earliest possible date - a suggestion I made myself.
I have no idea about the implication on LTI, I suppose LTI is not related to Mnet so it should be no problem.
LTI uses OAuth 1. The only impact that I can see for LTI is if OAuth libraries get included in the Moodle lib directory and/or a different OAuth library is chosen for Moodle, then it would be ported to use that. Or if Moodle gets a wrapper around the OAuth libraries, and a common framework (database tables etc. for tokens, nonces, etc.).
My concern here is that oauth2 is beyond human understanding. There seems to be plenty of examples of how to use it for Facebook and Google but after that you enter the fog of war
I spend a lot of my time coding SSO solutions for various client systems and I've been really keen to develop more standards based solutions. However, the oauth documentation seems to be written by hard-core cryptology devs and is beyond me (and I'm not completely stupid).
Anyhoo, unless I have completely missed the point, oauth2 is an "authorization" system rather than an "authentication" system. So, I'm a bit hazy about what we will be getting in 2.5. What will thie Oauth2 provider actually *do*??
I'm not saying we should not use oauth2, but it will need to be a proper job with docmentation and example clients otherwise it'll just be another MNET. That assumes it is even intended to do the same job which I am very unclear about.
Apparently, the problem with OAuth2 is that it got overrun by the wrong people (as a very bad paraphrase of Eran Hammer's blog post (which seems to be down at the moment)).
Yes, OAuth is not, in and of itself, an authentication system. In general, OAuth-based authentication works using the assumption that a user who can authorize a function call is the user him/herself. So, system A requests access to a function (for example, a function call to ge the user's profile data) on system B. If the user authorizes the function call, then it logs the user into system A.
One issue with using OAuth as an authentication system (at least in OAuth 1 -- I'm not that familiar with OAuth 2), is that nothing is standardized for using it as an authentication system. There's no standard for what function call to use, and there's no standardized OAuth endpoint (or standardized way to do discovery), which means that the implementation will probably have to be a bit different for every system that you want to autheticate against.
It seems to me that 99% of development requests have a requirement to allow users with accounts on "System X" (e.g. a customised CMS or the like) to be able to log into Moodle having already logged into "System X". We also need to pick up whatever profile information "System X" has.
I get asked this every other day, but I've never been asked the reverse or to code a facebook style solution. Maybe that's just my experience. It brings me back to my original question - what will Oauth actually do in Moodle. I'm not sure this is clear. Perhaps it should be before we go very much further.
I read Eran Hammer's blog post. It's quite depressing and certainly doesn't make me feel any more optimistic at all. Are we *sure* we are going down the right path here?
For Single Sign-On, I personally would recommend OpenID. There are contrib plugins for both using Moodle as an OpenID consumer and an OpenID provider. (Disclaimer: I wrote the OpenID provider, and was involved in development of one of the forks of the OpenID consumer.)
As far as OAuth goes, I believe the main reason for adding OAuth is as a replacement for MNet. It will also (I'm guessing) provide another option for calling web services securely.
Regarding Eran Hammer's blog post, I personally would say that we should just use OAuth 1 (especially since I've already done a bunch of the work in making Moodle an OAuth 1 provider ), but I don't feel strongly enough about it to argue for that.
If I summary, replacing Mnet has for goals:
* obtaining maintainable/expendable code => using more standard methods / common concepts to developers for the authentication and authorisation process.
* make it more easy to set it up for the administrators.
The idea of using Oauth2 as an authentication protocol is that:
- it is easy for a developer to implement an Oauth2 client.
- it is a popular authentication/authorisation system
- it's still in draft, and sometimes described as a mess (Eran Hammer's blog post), but from my point of view it does not matter. We just need to do it the Google or Facebook way. Most client developers will be happy with that. Google already deprecated Oauth1 for Oauth2, forcing developers to know about their Oauth2 implementation.
For the Mnet authorisation parts (enrolments in external courses, list of courses... TBD):
I thought using web services, so using temporary tokens from Oauth2. But with OpenID, the provider could also generate a token during the authentication process.
After reading Hubert comments, I don't see any issue using the couple OpenID/Moodle web service to replace Mnet. As I don't see much more issues with Oauth2.
I think, for the authentication part, we should evaluate:
* how easy is the authentication provider to implement/maintain (knowing that for OpenID there are written plugins...)
* how easy are the clients to implement
* how easy is the authorisation part to implement/maintain
* how easy is the administration process (in Moodle)
I'll start writing a doc. for Mnet replacement.
For me, I don't think that OAuth 1 vs OAuth 2 would be much of an issue for developers, as long as we have a good library. (Though if OAuth 2 follows in the footsteps of OAuth 1 with respect to libraries, it will have issues -- I only found one (out of the four that I tried) OAuth 1 PHP library that didn't have showstopper problems.) And there are enough big players behind OAuth 2 (e.g. Google and Facebook) that, despite the pessimism in Eran Hammer's post, I think that something will come out of it.
There is a hybrid OpenID/OAuth extension that allows the OpenID authentication sequence to also exchange an OAuth token. I believe it's only for OAuth 1, though. But it seems like it might be simple enough to adapt it for OAuth 2. Or we could make our own extension that will exchange a Moodle web service token.
Anyways, IMHO, the MNet replacement should be designed in a way that it is not its own separate component, but rather is designed in a way that it improves the other existing parts of Moodle (which sounds like that's the plan anyways). e.g. MNet web service calls should be callable by non-MNet clients, MNet SSO can be used by non-MNet clients, etc.
I want to use Oauth2 on my moodle site. i installed it, i got the goole, facebook and micrsoft Client ID and Client secret but i can't put it to run. To use it after getting the apps ID i have to develope something else on facebook, google, etc for the registration form? Help me please. I attach two images to verify the issue with google and facebook.
i have the same problem. how did you solved yours?
We'd like to know from users / developers etc. what they would like to be able to achieve from a future authentication between Moodles and Moodle and Mahara(s). Please fill in the survey at https://docs.google.com/forms/d/1vyECf8s8lyEX6YJuf9SGe7sUN5flaROcfBF7mPxY9fc/viewform
Please fill in the questionnaire by 20 June 2014. Once we have all responses, we'll collate them and analyze what is required in the future and how we can best achieve that.
Thank you very much to everyone who responded to the survey earlier in the year. The answers have formed the basis for re-thinking the connection between Moodle and Mahara (and other systems).
Please find a high-level proposal on the tracker item for further discussion.