Ryan Chenkie: [0:00] The authentication and authorization implementation that we have for our Orbit app is freestyle. What I mean by that is that it doesn't abide by any particular framework or protocol or specification that has been drafted up.
[0:14] One such framework that we could abide by, if we wanted to, is the OAuth 2. Authorization Framework. OAuth 2. specifies a very particular way that authentication and authorization would happen.
[0:27] On top of OAuth 2., we could have something called OIDC or OpenID Connect, which sits on top of OAuth and provides a protocol for how we would deal with user identity.
[0:38] We're not using any of those things but we are borrowing certain concepts from them. One of those things in particular is we're using JSON Web Tokens to guard our API and to grant access to certain resources.
[0:50] This is something that's covered extensively within OAuth. We're rolling our own type of authentication that would do something similar. We're taking various concepts from OAuth and OIDC and we're making them our own here with our hand-rolled variety of authentication.
[1:07] There's nothing terribly wrong with this. Many different applications are doing this thing. We've got JSON Web Tokens being issued to users only when their username and password check out.
[1:18] Then we're using those tokens and the information contained in their payloads to protect our API. We've got a Protected Setup, but some people would argue that we shouldn't be using JSON Web Tokens in this fashion, if we're sitting outside of a framework like OAuth 2..
[1:33] There's some merit to that. It could be argued that if we really wanted to do things properly that we'd be implementing OAuth 2. and OIDC. One of the side effects of various concepts from OAuth and OIDC coming out into just general hand-ruled usage is that of the refresh token.
[1:50] The OAuth 2. Framework here specifies information about how you should deal with refresh tokens. If we check out refresh tokens, we can get a sense of what OAuth talks about here.
[2:02] Refresh tokens are a string representing an authorization granted to the client. The string is usually opaque and it denotes an identifier used to retrieve the authorization information.
[2:13] OAuth 2. is very prescriptive. It gives us a whole flow diagram here about how refresh tokens are supposed to be used to get new access tokens. OAuth specifies various actors like an authorization server, a resource server, and then the client.
[2:29] Beyond this, there are various types of flows for when refresh tokens would be used and when they wouldn't be used. Once again, we're taking pieces of this over into our hand-ruled implementation and for the most part, that's fine.
[2:42] Here's the thing, I recommend that everything we do in this module, that you don't actually go and implement it. The concepts that we're going to learn are going to be useful for thinking about how we might get what looks like a persistent user session.
[2:56] Because we're sitting outside of the OAuth framework, because we're not abiding by any of the flows stipulated by the framework here, there is an argument to be made that we shouldn't do it.
[3:06] Just like we wouldn't roll our own cryptography library. That's a task that has been accomplished by people that are way smarter than you or I. It's error-prone and there's a lot at stake if we get it wrong.
[3:17] The same arguments might be said about how we're setting up refresh tokens. With that thought aside, we're going to go ahead and see how we would implement this. In our case it will look a little bit like this.
[3:29] Our refresh token is going to be an opaque string of 64 characters. That's just going to be used to store in our database so that we can later retrieve a user I.D. That's pretty much what the OAuth spec here stipulates.
[3:43] Even though we are not doing strict OAuth in our example and we're just borrowing pieces of it, we are abiding by some of its stipulations. We're going to generate our refresh tokens with a random token library.
[3:54] Then we're going to set them as a cookie in the user's browser and then we're going to create some endpoints for us to get new JSON Web Tokens, where we're approximating to the access tokens. We're going to use the refresh token to get fresh tokens so that we can keep accessing resources on our server.
[4:11] If you are to heed the advice of not actually implementing this, in your own case, once you've gone through this module, and you're wondering what is then to be done to accomplish the same kind of thing. There are modules in this course that deal with the problem that we're trying to solve.
[4:25] Again, that problem is we want to keep the user logged into the application. Module two, which deals with cookies and sessions, gives us a way to deal with that. Module three, which deals with third-party authentication providers, also gives us a really nice way to do that as well.