 So, I'm going to talk about Ember and Oof, and in many ways this is kind of a tragedy, and I'll get to that later. But so I'm Matthew Rudy, and this is my logo, but it's actually just an emoji, but I've just changed colors. And I'm currently working on Chronicle in London, which is like a backbone front end, and like a load of ruby, and potentially in the future we're going to move to like Go and like Asandra or something, but we're basically a start-up, we're going to launch kind of next week, and we're always looking for, they're always looking for developers. So what are we trying to do with Oof? And I think there's sort of two things we want to achieve. One of those is like authenticating via a third party, it's the classic sign up or sign in with a third party. Because we don't want to handle passwords, because passwords get leaked, right? But we may also want to like obtain access to a third party API, and that was actually what I was trying to achieve when I was working on this little project over Christmas. So the tool, which is of course Oof 2, has its own logo, and has now a finalized specification but you've probably read about Oof 2, and particularly like the Road to Hell, described by the former author of The Standard, who quit a short while before it was published. So he explains his reasons for disliking The Standard as it turned out, and a lot of it was kind of like movement towards like corporate standards, but then at the same time people say that it doesn't really match the standards the corporate world needs. But actually, I think it's all right, at least for my purposes, and the spec is actually very readable, it's actually very simple, and maybe that's the problem is that it's too simple, and it's too many ways to interpret it, but fundamentally it provides four different flows, or four different grant types, which are the authorization codes, like the implicit grant, the resource owner password credentials grant, which is just like passwords, and the client credentials grant, and the spec has these very nice little flow diagrams which if you don't know what the resource owner and the fact is basically like someone is giving us, someone is using a browser, we're redirecting them to GitHub and then they're signing in GitHub and then it comes back, and this is the classic Oof situation, Oof 2 versus Oof 1, it achieves the same thing, like there's specific things about security, and Oof 2 particularly doesn't really provide any security, it says use HTTPS, but like this is, oh, so what actually happens is we get back parameters, which is an access, it's an Oof code, that we can then communicate via our secret on a server with GitHub who gives us actual access token, so it's so important, this only works if you are a secure server, because that's just how it works, but as well as giving us a token to use GitHub, we're also basically authenticating their identity with GitHub, which is the way that actually I use Oof most of the time is like Omni-Oof and I'm basically logging in, and this is the only flow that really gets you that, but what I was actually excited about and wanted to play with was the implicit grant, which in this case is the client, as the spec describes it, could well be amber, because it doesn't require any secret conversation between the client and the server, and in which case we don't necessarily have to believe that the token works, because the user is basically just trying to access GitHub, and if they have a valid token and GitHub is given it to them, then we can just use it, but importantly this actually uses the hash of the URL, and the reason is because we're trying to be secret for the, it has a very strange name for this, they call it the web hosted client resource, and importantly in this grant type we're trying to keep the token secret from them, and I'm suggesting that we probably want to deploy to S3, but the way that browsers work is that hashes are not sent to the server, but like Amber could definitely read this, and we could then just use that token straight away and access GitHub's API, and the third type is passwords, the password grant, which does what you expect, the user gives you a password and you hit an API and it just gives you back an access token which we can use directly, and the fourth one is like the client credentials grant, that as far as I see it's basically for servers to communicate with servers that are both in each other's trust, or I think that's the password, password authentication, or administrative interfaces. Yeah, from what I've seen I can't see, it's really for like servers using OAuth as like a standard to communicate amongst themselves, but so implicit grant flow is what you want to do, and there is thankfully an Amber OAuth 2 library that implements this and it's pretty well maintained and the config looks just like you would in like sort of Rails app with omni-auth. We're just going to give it a client ID and there is no secret, like in a server side you'd always be giving a client secret, but there is no secret because we can't trust the client. And importantly like this whole thing is basically that we have to create a state token that proves that when GitHub comes back to us that it will be the request we made. But importantly like they actually open a, the thing I don't like about this library is that it opens a new window which inevitably causes like pop up warnings and it doesn't work unless you accept them. So then this works. You see the examples in GitHub and there is a little trick here. So just using this is just like initially in your orphan you'll get the pop up warning and ignore it and eventually we'll get to, oh, I'm in the past. And this is something I think is quite cool is that GitHub is still not responsive. So if you have like a little window with a login form it just, I think I even moved it in this example, but like it just doesn't look good. Like GitHub need to kind of sort out their responsive login forms. But basically we get like a token except we don't because this actually isn't the implicit grant. Even though we asked for it, GitHub only actually supports the, so we're expecting to see, we can get like a parameter but actually we're supposed to be getting like a token. So GitHub doesn't actually support the implicit grant and they don't, well the documentation doesn't say they do, but I would hope that they'd just give me an error rather than looking like it was going to work. So basically they seem to ignore the token type parameter. So I spent ages like looking at this and then realised it was a total waste of time. But as I said, GitHub actually says you should use passwords. So kind of ruins my whole plans. So like the TLDR is like pure client side is purely supported. And from what I can work out, like Google does do it. Facebook sound like they do it. And there's probably other parties, but like actually I want to get GitHub. So my only solution if I want to stick to like a pure client side approach is to use passwords, which is what I didn't want to do. But I'm mostly like a Ruby developer. So I could just set up like a really simple omni-off server that just did this. So what about a hybrid approach? So what I think is cool, and I have like written a bit of code, but I haven't really finished it, is the authorization code flow but as an API. And like Ember and Rails, I love each other, right? So it's not going to be a problem. So let's take the authorization code flow and let's stick Ember in the middle of it, between the server and the web browser. So the concept is basically this. So in building like client side apps with like REST APIs, like we do this all the time. So like Ember should be like getting like an OOS slash new root, which should return like a URL to redirect to. And then Ember can redirect the client like storing state before it does. And then like get the callback and because we now have query parameters, we can actually in an Ember root, we can eat that up and do something with it and send it back to the server with a post. And I don't know if OOS is the best path, but that's what I'm thinking right now. If anyone has a better solution for like the name of this root, then please, please let me know. And then ultimately we're going to pass that code and the state object as well, I think. And we're going to end up getting like a JSON response that gives us the access token. And then we can do what we want to do. So I gave it big thumbs up. So like, so this is my hack together like version of it that probably doesn't work, but looks like it works. So like all we really want is just a simple like promise based Ajax client that gets a new token or gets a request for a token and then once we get the response, accepts it and gives us the get have access token. Now there may be something that does this already, but it's so simple it doesn't really need something else. And thankfully we can actually just do it in almost no code in Ember given we have query parameters because all we care about is that code, the code value that comes back, the state value that comes back and that's it really. So it's easy, right? So basically when I did this I thought like I was going to build like some really cool like github Ember app, but then I got sidetracked all the time. I'm trying to work out like this whole thing and then I realized it was a waste of time. So thanks. Any questions? Why which bit? You're sort of using trying to construct an API using a service. I don't know why I'm not using the service to handle those requests for you as a proxy to the Ember app. Why try to get the token into the Ember app? So what I want to do is build a like Ember interface for like Jekyll. So I want to basically like in the client I want to be interacting with the API. So all I want is a token. And going by the service doesn't make any sense. Well it doesn't make sense but it's unnecessary. So the way I have tried it before is either hosting the Ember app out of a Rails app and like setting a cookie and that's the easy way. But like I'm trying to get rid of cookies, right? So that's the easy way. Basically just use OmniOrph, set a cookie for domain and then redirect back to the Ember app and it would just work. But I'm trying to avoid that. And the other way that I do it, like my client does it right now, is that we have a separated Ember app and a separated like API server. And what happens is that we do an OAuth request and the callback URL actually is the API server. So GitHub goes back to the API server and then gets a token there and then redirects back to the Ember app, well it's a backbone app, with the OAuth token in the params. And that does work. But then like, I mean we are using Rails in a very similar way but I think it's an unnecessary step and I like building it up. So it suits me. And it's a valid question. But for my purpose, what I just want is like an OAuth token in my Ember app so I can like do cool stuff with Markdown. Yeah. Not a question but I ended up doing something similar. I've got an OAuth server that implements OAuth itself. So the Ember app authenticates with the OAuth server through plus it grants. And that authenticates with any other GitHub. Okay. So you log into the OAuth server and then the Ember app goes into that. It doesn't care about where that's gone off and talked to. That's the other way to do it. So then you can just implement a grant on Ember app. So that's kind of a thing. That's a good question or a question. The implicit grant for that loose case, I would have thought that would be a case where you'd use your credentials and then it would just be more standard to part. With our app, you can log in with Facebook, LinkedIn, Twitter or user and password. And all that's kind of held on the OAuth server. And then we authenticate with that, get back an OAuth token. And that OAuth token we then use against our API server and the API server. And the OAuth server both talks the same database so that's all stored there. But all the Ember app has to care about is the OAuth token at that point. I don't know if I've answered a different question. Yeah, well it's probably a conversation for viewers. So I do have a question. I'm not sure if it's a fair question and it's sort of not really Ember related, but it's OAuth related. You brought up the fact that that library that's been used and I haven't seen it before, so I'll have to take a look. And how does this annoying pop-up function out at the end? And the smoothness of which you can authenticate. I've seen a few cases where it really works well. And when it works well, it's just a million times better. And then you can go back to the process. Is there a way to avoid that? Is there a reason technically? Why? I mean, it would seem like this would be an obvious change. Yeah, I think the only reason is because I haven't spoken to the author. But I think it's probably because they're building apps that don't use push date. So at that point, if you're using the hash for your routing, then using it also for picking up the OAuth token maybe doesn't work. That's my only guess. I haven't spoken to them. So actually, the way I approach writing talks is I always have this ambitious project that I start and then I realize I should just build a smaller library and then I realize I should stop doing that and do something else and then I achieve none of it and just give a talk. But I tried lots of different apps, right? And one of them, I basically took that Ember OAuth2 app client and just reused it using the hash directly on the URL and it does work. So I think a simple pull request and an alternative flow for using that would be really simple because the library's always there. Importantly, it knows how to store the token state, the state objects. So it already knows how to parse the parameters and such. So it would be fairly simple to do. I suggest just doing a pull request on his project and giving two different approaches. Okay, one more question. Do you think they're going to sort it out as the client side for a lot of the work? For the GitHub? Yeah, for any of those services because it doesn't seem to be a priority. No, it works a lot in cases. I think where you have, especially data that's not as potential to use easier use case to open up like last FM would be supported, for instance. You have Facebook definitely does and you have, there are a lot of different cases where the implicit grant works. And I think that there would be an interesting use case where if you wanted to, you're back end server, and I think if you have a back end server, you're probably considering having a hold of the secret there and you can do a lot more. At least they'll provide more services for you anyway as much as it might be more of a push real time service than a pull request reply. But the interesting thing would be to have your client basically get forward captioning. Just basically have it pull out a bunch of raw data, process that data, and then the interesting data that you care about gets sent back down to your server, to this work there. That would be, I mean, I've thought about doing that. I haven't had the time to have a pet project. So I don't see any good reason why I haven't done it apart from just it hasn't been a priority. Because, I mean, they already will give you a token if you give them a username and password. So why not, if you've authenticated by their system directly, it's more proof that you're the person. Maybe that's the answer. Maybe that's the answer. Raise an issue on the GitHub API repository. Cool. Thank you.