Welcome, everyone. My name is Micah Silverman. We're going to get rolling in just a minute or so, but I just wanted to do some quick housekeeping before we get started and before I introduce myself a little more formally. At the bottom of your screen, you'll see a bunch of various widgets that you can use to interact with the presentation during the webinar. You can submit your questions in the webinar by clicking on the Q&A widget there on the bottom, at the bottom. Like I said, my name is Micah Silverman. I'm one of Okta's senior developer advocates, and we're going to be talking today. I'm going to be talking today about OAuth and OpenID Connect. You can see at the bottom of this first slide, you can get me on Twitter at a fit nerd, and you can get all of Okta's developer advocacy team at OktaDev. And just a little quick background about myself. I'm a software developer and a developer advocate. I write code. I speak at conferences. I contribute to Okta's developer blog where we have a lot of tutorials and thought pieces on OAuth and OpenID Connect, and we'll have that available as resources. Now, a lot of times if you search for OAuth or OpenID Connect, or if you're interested in learning about the standards, you tend to get one of two types of Google responses. One is the specifications themselves, which are great if you're building an OAuth service like Okta has done, or if you're suffering from insomnia. Those are great. The specifications are great for that. The other type of hit that you get is kind of deep dive into code without a lot of context for why OAuth, why OpenID Connect, how do they differ, where do they come from. So we're going to take a step back at the beginning here and try to give some context around OAuth and OpenID Connect. In order to do that, we're going to jump back a bit to around 2007 to look at what the web looked like then. So at that point, we had simple login, we had forms and cookies, we had full page transitions. You'd click on a link, you'd go to another page, you'd fill out a form, you'd submit that form, get to another page. That was kind of the state of the art of the web. We did have some single sign-on standards like SAML, but those were really in the domain of the enterprise. If you were a big bank or an insurance company, maybe you were using SAML, but it certainly didn't proliferate out to consumer-facing websites. To put things in context, in 2007, mobile was not solved as a viable platform. So 2007 was the year that the very first iPhone was released, and if you go back to articles of that time, there's probably an equal number of negative articles as there were positive. Lots of articles saying that this was ridiculous, nobody was ever going to spend hundreds of dollars to have a computer in their pocket to make phone calls, who wanted to browse the web on a three-and-a-half-inch screen. So mobile was not solved at this point, and we were just starting to talk about the idea of delegated authorization. Now we're going to talk about delegated authorization a lot, but that conversation came out of the state-of-the-art of the web where you had interfaces like this. This is a real screenshot from around this time from Yelp, and we just started to want to have interactions between different websites. So in this case, Yelp was this hot new service where you could rate restaurants, and Yelp gave you this interface so that you could connect with your friends that either had a very similar interface, you put in your email and password, and Facebook would read your contacts and give you a list of your friends and show you which friends were already on Facebook so you could connect with them, or give you the opportunity to invite friends to Facebook. So these sorts of interactions between websites, Yelp and Facebook are examples, started becoming more important. The problem here was one of access and authority. Once I give my password to Yelp or to Facebook, that's kind of giving them the keys to the kingdom. Really what I want them to do is have read-only access to my contacts. I barely trust them with that level of authority. But in practice what's happening is they now can do anything as me. They essentially can masquerade as me. They could send emails on my behalf. They could delete my contacts. They could look at my Google Docs. That's way more authority than I want to be able to give them. So the question that emerged is how can I let a website access my data without giving it my password and access my data in a very limited way? Now I just want to do a quick check here and make sure the audio is okay. So I'm just going to check in with my producers. Is the audio good or do I need to switch to a different mic? Just let me know in chat. Okay, cool. All right, so now what emerged out of this conversation on delegated authorization, how can I let a website access my data without giving them my user ID and password, is the OAuth and then later on the OpenID Connect standards. But now there ended up being a lot of confusion around these standards. So the confusion comes with a lot of terminology and jargon. This is less of a factor today, but there's a lot of incorrect advice. So you literally get blog posts or other types of posts where people were saying to take a certain approach and using OAuth and OpenID Connect was just plain wrong. In order to understand OpenID Connect, we first need to talk about OAuth. And we're going to see a little later on kind of a spoiler alert that OpenID Connect is a thin layer that rides on top of OAuth. It doesn't stand alone. So even if your concern is only one of authentication and single sign on and identity and you say, well, I don't need to know OAuth. I just want to focus on those concerns and use OpenID Connect. You still need to learn a little bit about OAuth because OpenID Connect builds off of it. And it's often hard to find a lifelike example out on the web. As human beings, we like to deal with analogies and metaphors. It helps us to learn things. And it's hard to find that out when you do a web search. So we're going to attempt to relate OAuth to a lifelike example. And that example is how we interact with a hotel. So the hotel analogy. And it turns out that the way that we interact with hotels maps on to OAuth in some very specific ways. So this diagram here, we have a person who goes and books a hotel. And they interact with the hotel receptionist. Usually we give them a piece of ID and a credit card. They hand us a hotel key and then we go open the room up. So that's kind of the day-to-day interaction we have with hotels. Now more formally in this diagram, a hotel booking system delegates access to me as a guest so that I can interact with the hotel receptionist and get a key and then I can access my hotel room. Now it turns out that the way that we interact with hotels maps on to OAuth in some very specific ways. Three in particular that we're going to talk about here. First of all, there's this idea that with this hotel key that I've been handed, I can only access a very limited subset of rooms, usually one. I can't just go up and down the hall and open any room. I can only open up the room that's been assigned to me. Now in the world of OAuth, we call that scope. And the tokens, the keys that we deal with in OAuth called access tokens also can have limited scope. So that's the first way. The second way is that there's an expiration built into my hotel key. So if I check out of my hotel and I keep the key and I come back the next day, it's a pretty aesthetic, it's built into the key. There's nothing that the hotel receptionist or the hotel manager had to do explicitly to expire that key. It's built into the key. Likewise in the world of OAuth, we have these access tokens and those access tokens also have a built-in expiration. And now the last way that I'm going to touch on that hotels map on to OAuth, it really drives home the point that OAuth is all about authorization, where OpenID Connect is about authentication. And this last point is that the hotel key is what we call a bearer token. What that means is that if my arms are full and I go up to my hotel room door and I hand the key off to my daughter or my wife, they can open that hotel door just as easily as I can. So the hotel door doesn't care who I am. All it's doing is validating the key. Is it the right room? Is it not expired? And then if that's the case, it's going to open up. So likewise in the world of OAuth, when we have these access tokens, they are bearer tokens, and the API that we're interacting with with the access token doesn't care who we are. It's just going to check that the token is valid, that the scope is correct, and that it's not expired. It's also one of the reasons that in modern hotels, those hotel keys don't have the room number stamped on them because if we were to drop that key in the lobby of the hotel and it had the room number on it, then anybody could open our door because, again, the door doesn't care who we are. Now, let's look at the same diagram in the context of an application. And if you notice, switching back and forth between these slides, the arrows and the steps are the same, but the actors are a little bit different.  Yelp obtains an access token from Google, and then Yelp uses that access token to interact with an API, in this case the contacts API. So it's very similar to the way that we interact with hotel rooms. Now, with that under our belt, we can take a look at some more formal OAuth terminology, and the third column in this table are our formal OAuth terms. So we have these four actors. We have a resource owner, a client application, an authorization server, and a resource server. Now, starting at the top, the resource owner wants a client app to do something on their behalf. So that's like in the hotel, the hotel booking system is going to enable me to book a room.  The client application needs authorization to interact with an API on behalf of a user. So in the case of the hotel, that's me as the guest. In the case of the app, that's Yelp. So Yelp needs authorization in order to interact with an API, the contacts API on my behalf. Next up, we have the authorization server. The authorization server grants access in the form of tokens to an application. So this is Google granting access to Yelp in the form of an access token. And finally, we have the resource server. The resource server has an API that an app can use if presented with a token. So the contacts API, Yelp can use the contacts API as long as it presents a token that has the right scope and isn't expired. So now, in a more modern app, when we're using OAuth 2, what we're really saying is I trust Gmail. I use Gmail every day. And that's where my credentials for Google are supposed to go. And I kind of trust Yelp. I want Yelp to have access to my contacts only. And so now, instead of a form that I click on, or that I put my username and password in, now I have this friendly connect with Google button. Now, we're going to use the option that's going to enable Yelp to read tokens on my behalf. Now, when we were looking back at these different analogies, like the hotel analogy, you'll notice that there were steps here, one, two, three. Same as with our app scenario. These are the steps that it took to get an access token and to use that access token. Now, in the world of OAuth, we call that the flow. And there are a number of different OAuth flows that we're going to take a look at now. And the very first one that we're going to look at is called the authorization code flow. And we start with that flow because it's, first of all, it's the most secure. It's also the most complex. It's got a lot of moving parts to it. So let's take a look at the authorization code flow. Now, the first thing that happens when I click on that connect with Google button is it sends me over to Google to authenticate. This is where I'm supposed to put my email and password. And so Yelp is not involved in this part of the flow. I'm going to authenticate at Google like I ordinarily would. And one thing to notice is that included in this initial request is a redirect URI. That's because we're outside of Yelp at this point. And when we're done authenticating with Google, Google needs to know where to send us back so that Yelp can continue this flow. So that's why we have this redirect URI. Now, I also want to point out that I said that OAuth was all about authorization. But here we're talking about concerns of authentication right off the bat. That can be a little confusing, and so I want to clear up that confusion. There's an expectation that authentication is happening, but it's out of band of the OAuth flow. What I mean by that is that this authentication may be complex. Maybe in addition to putting in my username and password, I have to provide two-factor authentication. Maybe my password is expired and I have to reset my password. That could all be part of this authentication piece, but OAuth doesn't care about any of that. OAuth only cares about the assertion that it gets back ultimately as proof that I authenticated. So authentication is happening, but it's really out of band of the OAuth flow. Let's continue. After I authenticate, I then get a consent screen. Now, you've probably seen this. Facebook popularized this. The purpose of the consent screen is so that the authorization server can present to you as a user what it is that Yelp, in this case, is asking access to. So this should be human-readable and it should be clear. And in this case, we're saying the consent form is saying Yelp wants to access my public profile and contacts. And this is my opportunity to allow it or not. So this is our opportunity to say, well, you know what? Yelp is asking for too much. I don't want to give them that authority. Now, if you're like my mom, you're going to click on yes no matter what it says here. But hopefully we're a little more discerning because this is our opportunity to say, you know what? I've changed my mind. I don't want to give Yelp this access. Assuming we click yes, this is where Google now uses that redirect URI to go back to Yelp. And what it sends back to Yelp via an HTTP redirect is an authorization code. Now, the authorization code is a one-time use code and it has a very short lifespan. First, you have 60 seconds to use the authorization code before you have to start the flow all over again. Okay, now that Yelp has this authorization code in its hot little hands, it can exchange the authorization code for an access token. And that's been Yelp's goal the entire time. Yelp needs to get an access token so that it can interact with the contacts API. So what Yelp does is it makes a post request to Google to exchange the code for an access token. It also, this is a simplified view of what happens. It sends along the authorization code, but it also needs to send along a secret that had been issued to it by Google earlier. And so now a combination of the secret and the authorization code gives Google everything that it needs to validate. And assuming it's valid, Google is going to return an access token. Now that Yelp has the access token, it can use that access token to interact with the contacts API. And now it can read my contacts and Yelp now has the authority to access my contacts, read only. It doesn't have any authority to do anything else like access my email and it never saw my past further and see what else is going on with this. Now we're going to revisit this flow a number of times. And let's see what we have here. So we're going to add in some more OAuth 2 terminology. And now let's talk a little more deeply about scope and consent because those are intimately linked. When I click on connect with Google in addition to the redirect URI, it's also sending along a space separated list of scopes. Now these are the scopes that Yelp is requesting and Yelp can request any scopes. It could request write access to my contacts. It could request the ability to send email on my behalf. It can request whatever it wants. But Google is going to show all of the scopes that Yelp is requesting and give me an opportunity to say yes or no. So the scopes that are requested and what we see in the consent form are tied together. And it also drives on the point that the scopes that Yelp requests are relevant to the authorization server to Google. So the scopes must be scopes that Google recognizes and then Google is going to present those requested scopes in a human readable form so that we can make a decision. Now assuming that we say yes, everything continues here. We redirect back with the authorization code. Yelp exchanges the code for an access token and then Yelp talks to the back end API, in this case the contacts API using that access token. Alright, let's look at some more terminology. Bear with me a sec. Here we go. Even more OAuth 2 terminology. So we have this concept of the back channel and the front channel. And you may or may not have noticed in the diagrams that we've looked at so far, there were solid lines and there were dotted lines. Now the back channel is a highly secure channel and the front channel is a less secure channel. And what we mean by these channels is the front channel is anything that passes through your browser's address bar. That's what we call the front channel. Anything that's a server to server communication, that's the back channel. So let's revisit our flow here and see when we're dealing with the front channel and when we're dealing with the back channel. And when we click on this initial link, that's the front channel. That is you this initial request that includes the scope and the redirect URI that all happens in your browser's address bar. We also see the consent form from our browser. So that's front channel and Google redirects back to Yelp on the front channel as well. So this authorization code that Google sends back passes through your browser's address bar. Now we call this a less secure channel because there are certain things that can interfere with this interaction. When Google redirects back, if you're familiar with HTTP, this is an HTTP 302 redirect that hits your browser and then the browser sends that request over on to Yelp. The browser does that automatically. You don't have to intervene. But we call it a less secure channel because, first of all, Google has no way of knowing that the correct recipient, namely Yelp in this case, actually received the redirect. So you may have some compromised network or a compromised machine and maybe Yelp never receives that redirect and Google has no way of knowing that. If you heard that beep, that was my phone activating because I was saying Google so much. So there you go. Google is always listening. All right. I'm going to have to turn my phone off, I think. All right. So that's one issue is redirect interception. Another potential issue is you may have a compromised machine. You may have malware or a virus. You may have even a misbehaving browser extension that's listening to what's passing through your browser's address bar and intercepting it. So these are all risks on the front channel. Now we're going to see in a little while and you may have asked, you may have the question, well, why do we go through this whole dance? Why do we have an authorization code and then we have to exchange it for a token? Hopefully that will be cleared up in this conversation about back. So everything that happens on the channel, including getting this authorization code. Now assuming Yelp gets the authorization code, the next thing Yelp does is exchange it for an access token. Now if you notice, this line is dotted. This is a back channel communication. So Yelp sitting in Yelp's data center behind Yelp's firewall is making a post request to Google sitting in its data center behind its firewall. This is a much more secure mode of communication. And that's why we call it the back channel communication. So now Yelp has a high degree of confidence that it's communicating with Google. And because it's a post, the request is a post, the response from Google is going to come back on that same channel. So it's much more trusted. And this is why we have this little dance. Google doesn't return the access token directly to Yelp in a redirect because then the token would pass through your browser's address bar. And if you remember, the access token is a bearer token. So if you have a malicious browser extension that's examining your address bar and that access token comes back through your address bar, now that malicious browser extension has the access token and can use it directly. If, on the other hand, the browser intercepts the authorization code like a misbehaving browser extension, there's not a lot that that extension can do with that authorization code. Because if you remember from before, in order to exchange that authorization code for the access token, Yelp also needs to provide a secret that your browser extension would have no way of having access to. Because that secret that Yelp is using is programmed as an environment variable or in a database, something that Yelp only has access to in its server safely in its data center behind its firewall. Okay, once Yelp has the access token, it can then use that access token also on a back channel communication with the contacts API to read your contacts. Now, tactically speaking, this is what when we click on that connect with Google button, this is what the URL looks like, or this is an example of what the URL would look like. So we're hitting an authorization endpoint and we're passing in, at a minimum, we're passing in these five query parameters. We have a client ID that identifies the application in the service, in this case Google. So with Google and Okta and Facebook and most providers, you can have any number of applications defined. And so the client ID identifies the application. Then we have the redirect URI that tells Google where to redirect back to we have a space separated list of scopes. We have a response type. This is part of the OAuth specification and it just indicates to the authorization server what we expect to get back from this interaction. So what we expect to get back is a code or an authorization code. And then we have a state. The state value is usually a randomly generated value that the application generates. So this would be something that Yelp generated. And the responsibility of Yelp is to generate the state and to validate the state. And the responsibility of the authorization server like Google is to return the state when it redirects exactly as it got it. So it's just an additional check to make sure that Yelp is interacting with Google when it gets a redirect. Now assuming you, when you get to the consent screen, you're going to either click allow or deny or yes or no. And if you clicked no or deny, it's going to redirect back with an error. That's what this top URL is showing. If you click yes or allow, it's going to redirect back with the authorization code and the original state that was passed in by the application. In this case, Yelp. So that's the first leg of the interaction that we've been seeing in the diagram, which is the authorization step. Now we have the step where Yelp is going to exchange that authorization code for an access token. And this is an HTTP post. The content type has to be XWW for URL encoded. That's part of the specification. And then Yelp needs to provide these queries to exchange the code for an access token. So it's the code itself. It's the client ID. And then this is where Yelp provides the client secret, which only it knows. Or I should say it and Google know because Google assigned the client secret. And it needs to provide the grant type. Grant type is synonymous with flow. And so this last 10 slides or so, we've been talking about the authorization code flow. So grant type is required, assuming all this checks out. Then Google is now going to respond with an access token. It's a JSON response, and it looks something like this. It's got the access token itself, an expiration, and a token type, which is going to be bearer. Now one thing, if you have questions, ask questions using the Q&A panel and we'll address them to the greatest extent possible at the end. Now once Yelp has this access token, the way that it uses it is to hit an API endpoint using a standard HTTP get or post. And then it uses this authorization header. This is also part of the HTTP standard, which predates OAuth. So there's an authorization header. And the way the authorization header works is you give it a scheme and a value. Now there are some built-in schemes that you may or may not be familiar with, like basic is a built-in scheme.  That's where you get that old-school pop-up and you have to put in a username and password. And in the case of your home Wi-Fi router, it's admin-admin or admin-password and everybody knows it because you never changed it. That's basic authentication. But the HTTP specification accommodates custom schemes. And in the case of OAuth, the custom scheme that we're using is the keyword bearer. So bearer with a capital B that must be present, followed by a space, followed by the access token that we just got. And then it is the responsibility of the API now to validate that access token. So the API receives that access token. It's going to validate it to make sure that it's a valid token, that it's not expired. It's going to make sure that the scope is correct for the API endpoint that's being interacted with. Assuming all that checks out, the API will respond with, in the example we've been talking about, a list of contacts, or it'll respond with an error if Yelp was, say, trying to write to my contacts. The Google API would recognize that it hasn't been authorized with that scope, and it would respond with an error. So in using the access token, the client, Yelp, passes the token along. The API validates that token and makes sure that the scope is correct, and assuming everything checks out, it'll send back a response. Okay, so we dove deep there into the authorization code flow. We're going to talk about some other OAuth flows, and we're going to touch on a few of them. We don't have enough time to get into all of the different flows, but it will at least let you know under what circumstances you would use the different flows. And we have a whole bunch of resources at the end if you want to explore some of the other flows as well. So authorization code flow, that's what we just talked about. That uses a mix of the front and back channel as you saw. There's a special extension to the authorization code flow called authorization code with pixie pkce. That stands for proof key for code exchange, and we're going to look at that in some detail toward the end. That also uses a front and back channel, and the spoiler alert there is it's a way to use the most secure flow, which is the authorization code flow in unsecure environments, insecure environments like your mobile apps, your desktop native apps, your single page apps, spas. So this is a technique in order to be able to use this flow in an unsafe environment. The implicit flow is a front channel only flow that has been deprecated. We're going to talk about that in just a second. We're going to look at that flow, but the punch line there is you should no longer use it because the latest guidance says to use the authorization code with pixie flow for your spa apps. Then we have a couple of other flows that are back channel only. One is the resource owner password flow and the client credentials flow. Resource owner password also is a flow that is not generally used anymore. It's still a valid flow, but in your most cases you won't be using that flow for a variety of reasons. The TLDR there is that it requires that you give the username and password, and so in most cases it's going back to that password anti-pattern where you're supplying credentials to a third party. So you shouldn't use the resource owner password flow unless it's a first party app. Finally, the client credentials flow. This is a valid and often used flow. This is for when there is no user. So if you have a microservices architecture and you want to secure service-to-service communication or you have a batch or a cron job, there's no user involved, that's where you would use the client credentials flow. Let's talk about the implicit flow. Just imagine that Yelp has an Angular app, a single page app, and it wants to use OAuth. Well, in the old days the implicit flow was released at a time when there were limitations both from providers and from browser capabilities, and the implicit flow was the best we could do. Now this is what it looked like. We would authenticate at Google. That's good. We would get the consent form. That's good. But because it's a spa app, Google would immediately redirect back to the browser with the access token. Now this presents a couple of problems, some of which have always been there with the implicit flow and some of which are new. So the problem that's always been there with the implicit flow is redirect interception, which we talked a little bit about earlier. So because this is a front-channel only communication, that access token might be intercepted, and then because it's a bearer token, it's kind of game over. So now you might have a malicious app reading all of your contacts and maybe spamming your contacts in a way that you didn't intend. Also with modern browsers, we have a couple of new possible vectors of attack that didn't exist when the implicit flow was first released, and it's another reason why you shouldn't be using the implicit flow anymore. One of those is browser history syncing. So we have these super convenient features in browsers like Firefox and others where we can now sync our browser history, and that's great from a user experience perspective. I can log into, say, my bank on my mobile Firefox app, and then when I walk into my office, I can go over to my desktop and I can pick up right where I left off. Super convenient. And that's because Firefox is syncing my browser history, including cookies and tokens and anything else that might come across. But that increases the vector of attack because now an access token potentially is being synced to the cloud, being synced to multiple devices. It's kind of a black box. I don't know what's really going on there. And so that's just a new vector of attack for these sensitive bits of data like a bearer token that we don't want to leak out. So the punchline here is that you really no longer want to use the implicit flow because it's all front channel. Now the good news for our spa apps is that we have an alternative approach that we can now use in the browser. This used to not be the case. We used to not be able to use the authorization code with PixiFlow in the browser, but now we can and so that's the recommendation. All right. Jumping back into our time machine, we're going to look back to 2012 and identity use cases back in 2012 for simple login, for single sign-on across sites, for mobile apps, and for delegated authorization, OAuth 2 was widely used. Now the problem is that the first three use cases are all authentication use cases and it wasn't what OAuth 2 was ever intended for. So Facebook and others were essentially misusing OAuth and kind of bending it to conform to these other use cases for which it was never intended. So a bunch of really smart people got together and said we need a new standard to deal with authentication because there are problems with using OAuth 2 for authentication. One is that there isn't a standard way to get the user's identity information. So Facebook might have implemented it one way, Google might have implemented it another way because we're outside the scope of the standard for what OAuth was ever intended for. Which reduces interoperability. OAuth gave a lot of flexibility. It introduced the concept of scopes, but it didn't define any scope. So maybe Facebook calls your user profile profile whereas Google would call your user profile user info. So it's kind of like the Wild West out there. Everybody was doing things a little bit differently. So Google and Microsoft and a bunch of other smart people got together and said well, OAuth gets us like 80% of the way there. Let's build a thin layer on top of OAuth and get us the rest of the way there and that's what OpenID Connect is. OpenID Connect is for authentication. It's for concerns of identity and it rides on top of OAuth 2. That's why we spent all this time talking about OAuth before we could get to OpenID Connect because it doesn't exist on its own. So OpenID Connect adds a new token called an ID token. It adds a standard endpoint called the user info endpoint to get additional information about the authenticated user. It introduces a standard set of scopes. So there's a handful of scopes like profile, email, address, phone that are predefined with OpenID Connect and so every implementation including OAuth has to support these scopes. It also still supports custom scopes so there's still a lot of flexibility but now we have a much higher degree of interoperability because we all know we're talking about the same thing and so it's standardized the implementation. Let's revisit our authorization code flow but now in the context of OpenID Connect. We have all the same flows available to us because again OpenID Connect is still riding on top of OAuth. All right, so we kick off the flow similar to the way we did before except now we have a required scope and that is the OpenID scope. That's what distinguishes this from a regular old OAuth interaction. So far, so good. We see the consent screen just like we did before. We redirect back with an authorization code and now here's where things are a little bit different. When Yelp exchanges that authorization code now it gets back both an access token and an ID token and now Yelp has an additional capability which is it can use, first of all it can identify me by name because the ID token has my user identifying information in it and it can use the access token to interact with the user info endpoint and that user info endpoint now gives additional information back to Yelp. Okay, bear with me a second here. Let's take a look now at the anatomy of this ID token. Now another thing with OAuth was in terms of flexibility and the standard is that OAuth defined access tokens but it didn't dictate the format of those tokens. So Facebook might have a different token format compared to Google, compared to Okta. One of the things that OpenID Connect specifies is the format of the ID token. It must be a JWT which is a JSON web token. Sometimes they're referred to as JOTs. I'm not particularly a fan of that. I don't know how you get the ah sound out of the W but that's the way it is. So if somebody says JOT you'll know what they're talking about. It's a JWT.  We've added some white space and we've colorized it but it's really just one long string. It's got three parts to it. It's got a header, a payload, and a signature. Now the signature is cryptographically signed and to create the signature we use the header and the payload along with a private key and a signing algorithm and that gives us the signature. To validate the signature we use the header and the payload and a public key with a validation function and that gives us a high degree of confidence that neither the header nor the payload have been tampered with. Now the payload is just valid JSON. It's key value pairs but in our industry we have to complexify everything so we don't call it key value pairs. We have to find claims so the key value pairs are and find claims, those are referred to as registered claims and those are just claims with a purpose and they're usually these three letter claims like EXP is the expiration. That tells us when this JWT expires and the value type for EXP as dictated by a specification must be a long number that represents an epoch time, a number of seconds that have elapsed since January 1st 1970. If this value were a Boolean or an array or a string it would just invalidate the JWT because these are registered claims but you can also have custom claims like name and auth time, those are all custom claims and those can be any valid JWT or sorry any valid JSON. All right, we have about five minutes left and we're going to cook through these last few slides here and then we'll have lots of time for questions. All right, so fast forwarding to today we now have everything in its right place. For all of those authentication use cases, the first three, simple login, single sign-on, mobile app login we have open ID connect and then for delegated authorization we have OAuth 2. So on the left-hand side OAuth 2 is for when you want to grant access to your API and open ID connect is for when you want to login the user and understand information about the user. Now knowing which flow to use when for your web application that would be like your Spring Boot, your .NET, your Node.js when you have a back-end you want to use the authorization code flow the most secure and the most safe flow to use because of the back-channel. Now for a native or mobile app or a JavaScript app like a single-page app you're going to use this special extension which is going to be the last thing that we talk about the authorization code with PixiFlow, PKCE and then for microservices and AP credentials flow. All right, let's talk about Pixi. I've left my favorite for last. So Pixi stands for proof key for code exchange and it's a way to use the authorization code flow in an unsafe environment. If you remember the authorization code flow, the end where we exchange the code for a token that relies on a client secret, a fixed client secret. Now in the world of our spa apps or our mobile apps it's not safe to store a fixed client secret because those can be analyzed and decompiled and parsed and looked at and extracted. So what Pixi does, what the Pixi extension does is it allows us to have a dynamic secret that's safe from prying eyes that's only used once each time we go through the flow and it gives us a way for the authorization server to validate that fixed secret. So let's take a look at it. If you're not familiar with this type of diagram this is called a sequence diagram and we look at things from left to right and top to bottom to get an understanding of how the different actors interact with each other over time. So moving from left to right the resource owner that's you sitting in front of the browser you go and access the client app. Let's say this is an Angular app. Now the client app is going to generate a random value that's going to be our stand-in for the client secret. We're going to call that V and it's going to hash that random value using a standard hashing algorithm like SHA-256. The result of that hash we're going to call $. Now the Angular app is then going to redirect over $. The authorization server stores that hashed value which we call $ and it returns the login form to the user so they can authenticate. Now the next part of the interaction is the standard authorization code flow. So the authorization server after you've authenticated redirects back to this Angular app with the authorization code. We're going to call that alpha. And now this is the point at which the client app our Angular app needs to exchange the authorization code with the client ID, the client secret and the authorization code. In the case of Pixi it's going to use the client ID random value that it generated at the beginning of the flow and the authorization code. It's going to send that over to the authorization server and now the authorization server is going to validate that random value V by hashing it first and then comparing the hashed value to the value that it stored earlier in the flow. This is very similar to the way that we handle passwords in modern identity systems. So Octa never stores your plain text password but when it's presented with your plain text password it hashes it and it compares it to the hashed value. Likewise earlier in the flow we saw that our authorization server stored the hashed value and then later on when it receives the plain text stand-in for the client secret it's going to hash that value and compare it to the value that it stored before. We're running a little short on time so let me quickly demo this but you'll have the resource list so that you can look at this demo yourself if you're so interested. I'm going to share my screen really quick here and I have a little example here that I call the Pixi CLI and what the Pixi CLI does is it emulates a standalone native client using the Pixi flow and all I have to give it is an Octa org and a client ID. Let's take a look at what's going on here. So the first thing it does is generate the code verifier and it generates the code challenge. That's our plain text value v and our hashed value dollar sign just like we saw in the diagram. It's then going to kick off a connection to our authorization server using an authorized endpoint and what I have highlighted on the screen now this is the standard view or this is the standard authorization code flow but we add two additional parameters which is the code challenge method so that Octa knows the hashing algorithm that we're using and the code challenge which is that hashed value. So now it's going to launch the browser and I'm going to authenticate I'm going to authenticate at Octa this is where I'm supposed to authenticate and now Octa redirects back with an authorization code. Also it's telling me that I can close this tab because the authorization leg of this interaction is now complete and I can see that my little example here got this authorization code which we called alpha just like in the diagram. Now when I press any key to continue it's going to exchange that authorization code using the original code verifier this is our stand in for the client secret and so Octa is going to hash this value and compare it to the code challenge that it stored earlier and now the response that I get back includes an access token and an ID token and it's going to use that access token to hit the user info endpoint and get back a response which proves that this access token was valid. Now in real life you're going to use a library to manage something like the pixie flow but this example does everything close to the metal you can see here that it's building this authorized URL manually and the purpose of that is so that you can you can see what's going on behind the scenes so it's just for demo and you can have access to that at the end. Alright last slide and then we'll address questions again my name is Micah Silverman you can tweet at me at a fit nerd you can tweet at all of Octa's developer advocates at Octa Dev and if you go to developer.octa.com you can get your own free forever Octa org where you can play around with everything that we talked about today including OAuth and OpenID Connect so thank you again for attending I'll pause there and we can start hitting the Q&A alright now let's see I'm looking at the questions list here so bear with me for a second right so first question is what should a spa send for REST we didn't get into great detail so the spa for REST calls is going to send the access token as part of that request that's something that JavaScript can do just fine so it would be a post or a get an endpoint and it would have that authorization header and Octa like many providers has chosen to use JWTs as its access tokens so this gives the API some flexibility in how it validates it one thing the API can do is to validate the the token directly because it's a JWT so it can go and fetch the public key and it can use the algorithm you'd be using some JWT library to validate that the signature is correct and then you could look at the expiration and make sure that it's not expired and then go on from there that's one way if you're dealing with a JWT the other way is what's called the introspect endpoint and this is part of OAuth2 and the API could send that access token whether it's a JWT or not it could send that access token to the introspect endpoint at the authorization server and then the authorization server will send back a response that says either it's valid or it's not alright next we're gonna look I'm just gonna go down the list here we have a bunch of questions and we may not get to all of them I will try to answer all the questions but I understand that at the top of the hour people may need to drop off okay is the OAuth2 password grant type the same as resource owner password credentials flow if yes we're not sending any scope equals open ID in the request to the token endpoint does it fall under OAuth or open ID connect good question alright so there's a couple of questions in that question first of all providing the open ID scope is what distinguishes the interaction from being OAuth or open ID connect so if you don't provide the scope open ID then it's OAuth and you can't get back an ID token you'll only get back an access token now if your response type is explicitly saying that you want to get back an ID token and you don't provide the open ID scope then you'll end up getting an error because it's incompatible open ID tokens only exist in the context of open ID okay octa does have support for the password grant type formally it's the resource owner password grant type and if you're not sending any scope equals open ID then it would just be an old school OAuth interaction and you would just get back the access token now I'm going to assume that that you know the answer makes sense you can send a follow-up question if I didn't properly answer anything just because we have so many people I'm just going to keep going down the list here what's the difference between the data of the ID token and the data of the user info endpoint good question so the ID token is a JWT it's sent back to the application in the authorization code flow when you exchange the authorization code you get back the ID token and typically that would be a light amount of user information and in octa and other providers you can control what gets put into that token typically you wouldn't want a ton of user information in that in that JWT because you start to introduce network latency if it's a really big payload so let's just say for the sake of argument you have a service and part of the user profile includes every movie that I've seen in my entire life well you probably wouldn't want to jam that into the ID token rather when you hit the user info endpoint you can return information back that you wouldn't typically include in the ID token like something that's very verbose like the entire set of movies I've seen in my entire life or also you might use the user info endpoint for more sensitive information that you don't want to come back as part of the ID token all right continuing on how does the API endpoint validate the token submitted with the request as valid we touched on that a bit that is either going to be a JWT validation or an introspect validation that is not a JWT it would have to introspect it has to rely on the authorization server to otherwise it can validate all right we have time for one more question and I apologize it looks like we're not going to get to all of them so let's see what's next is the client secret unique to the Yelp user or unique to Yelp company wide good question so the client secret is issued to the application by the authorization provider so in the context of this question it would be unique to Yelp so Yelp does a registration process with Google Google issues a client ID and a client secret and Yelp stores that in a secure way either as an environment variable or in a database however it does it but that's how Yelp identifies itself to Google both the client ID for the purposes of identifying the application and the client secret the purposes of being able to securely exchange an authorization code for an access token and other types of interactions all right so I've been given the hook by my producers here that was our last question I know there's a bunch of other questions and we'll capture them and consolidate them and see if we can't answer them in follow up I want to thank everybody for joining us today and with that I will release you to the rest of your day have a good one and tweet at me if you have any further questions


Promotion chasing Bradford were on the wrong end of a surprising 1-0 defeat in Midweek at Swindon Town which has put a dent in the Bantam pursuit of automatic promotion. Jenningham's excellent 2-0 home victory over promoted Leighton-Orion in Midweek makes them now safe as houses for another season in League 2. For a long time this season their EFL future was in doubt, but not anymore for the Kennside. This should be a really intriguing encounter between two sides who have been in excellent form in 2023. Bradford start the day in sixth position on 71 points. Three points on Tuesday for Jenningham, absolutely secured their safety, they're now in 17th. It's an early opportunity, it's an early goal for the visitors. It's Timothy Dieng, not in the Bantams promotion script this one. Right footed shot from the right hand side of the penalty area. It's a mistake by the Bradford defence. Dieng takes it upfield, holds off his marker and fires unerringly into the opposite corner. From that defensive error, Bradford have only lost one of their last seven League meetings with Jenningham. That was a heavy 4-0 defeat in October 2018 and that was nearly another goal for the visitors Jenningham. Well this has not started well for the promotion chasing home side. Once again the architects of their own downfall. Any one of us can feel low, our thoughts can get us down. We can also feel worried about family and friends. But you don't need to struggle on your own. A helping hand is at the end of the phone or keyboard every day of the year. Call guideline on their free phone number today. 08 001 884 884 Or go online to use the live chat www.mindingbradford.org.uk Guideline is brought to you by Minding Bradford, your local mental health charity. Well Jenningham have only suffered one defeat in that last eight League visits to Bradford. Which was a 1-0 defeat in March 2018. Jenningham quite like a trip to Yorkshire. But Bradford looking to get back on level terms early in the second period. It's Andy Cooke, the division's top scorer. 28 goals in all competitions now, that's 25 in the lead. 60's last six, a valuable lead. It's a brilliant cross from the left hand side. And Andy Cooke, top header, great lead. Andy Cooke now has 12 home league goals this season. That's the most player player in a single campaign at Bradford. Valley parade since 2011-12 season when James Hansen got 12. Cooke will hope he has even more in him this season. Ellingham coming forward, they've played well so far. Left for a long time, now being packed back, looking for that second goal. Looking to regain their lead, but it's a very good save by Lewis in the Bradford goal. Mackenzie it is, who finds that little bit of space to get his shot away. And in two of their away lead games this season, losing the last three on the bounce. But so far they have a point here on the road. What a good point it would be against a very good Bradford cityside. Opportunity here, an appeal for Humboldt. Shot coming in, fantastic save by Morris in the Jenningham goal. And football all round, banks it is. Who picked it up, left footed. Superb right handed save by the Jenningham stopper. For three points here, help consolidate their playoff place. But to keep alive automatic promotion hopes. It's still inside the box, appeals for a penalty. It's given up, put themselves ahead and put themselves in poor position for three points. It does look like a penalty. Banks it whilst he drew the penalty from Max Emmer of Jenningham. Here's the chance, it's a goal from Andy Cook, converts the penalty right footed into the bottom left hand corner. Tends the Jenningham goalkeeper the one way, that's the sixth brace of the season. Was potentially for a vital three points as the promotion chasing Bantams. Go into the lead, that's 29 in all competitions for Andy Cook. What a season. Bradford looking to go as deep into the Jenningham half as possible. Hoping to hold on to this. Two on lead with moguls to go, shot coming in. It's a really good save, fantastic shot. Nichols it was from distance. Second touch with his left right foot, he'd shot. And Lewis pushes it round the post. The visitors searching for an equaliser. Again, it's Lewis coming up jumps in the Bradford goal. He's not on a lot to do today, but what he's done, he's done superbly. Two fabulous saves in a short period by the Bradford City stopper. So deep now into this game, and Bradford just hanging on a little bit. In possession of three points as we speak. So Dunder trying to get the ball in, but he wins a corner on this knee aside. It's going to be taken and it's going to be right footed. Swinging in towards Lewis in the Bradford goal. But it's an equaliser, right at the death. The last minute of additional time, and it's a hammer blow for Bradford. Substitute for Julligan, Oli Hawkins. Lewis if Bradford tries to punch it away. Lots of bodies around him, was he being held? Oli Hawkins pouncing, securing surely a point for the visitors from that corner. Hawkins third goal for Julligan. And that's a Bantams body shot. Taken the wind out of Bradford's sails. Such a late goal. Mark Hughes will be so disappointed. Defeated midweek, and victory snatched away from them. And Julligan have another late free kick here. And it'll be a yellow card. Nichols it is, he wins the free kick. Right footed free kick coming in towards the back post. Sales over the heads of everybody. Well that's full time and at the break the visitors Julligan led. Thanks to the end strike on 12 minutes. Bradford bounce back with top scorer Andy Cooke's header early in the second half followed by Cooke's 29th goal from the penalty spot in all competitions this season. The Bantams were headed for three points, but Julligan's last gas equaliser from Sir Ollie Hawkins. Mark Hughes isn't happy. It's either with the amount of time at the end of the game or it looks like it's being held. He's suggesting that Lewis was being held by Bradford keeper but it's full time and it's Bradford two. Julligan two.


Everyone, Sam here with late sports card, driven 22, obsidian basketball hobby, 12 box full case break, number 15, random team stop. So look again at your random results. As always, you can find those on the website under the results tab, as well as the link in chat. Good luck. Like pound and red bulls, and I'd have to wait for like seven. There's a bunch in there. And now, I'll meet them tomorrow. So I have my, the plumber's coming tomorrow. I have to re-fight my house. Yes. What do you mean by the house? The house. The whole house. Are you kidding me? Yeah. There's a leak in one of my closets. Move all my stuff. I move most of it, but I have to move some still tomorrow. And then, yeah, it's just not gonna be fun. It's coming at 8.30. I should call you at 6 a.m. Yeah. Gary Trent to 99. And rainbow, that is RJ Barrett on the short print. Anthony Dibbs, Walker Kessler Rookie. Autos, we've got 14 of 25, second year Key on Johnson Volcanic for the Blazers. That's Portland. And then to 149 Kavan Looney, Volcanic Auto. Going to Golden State. That's Warriors. Sold out by the way, everybody on UEFA. So thank you there. Appreciate that. That'll go right out for basketball before we go into football. Legacy sold out. Just three breaks with spots left tonight, everybody. That's it. Three breaks with spots available tonight. NT and 10 box football. That is a Malik Beasley to 99 and Equinox to 99 of Donovan Mitchell. LeBron joining Goodwin Rookie for the Wizards. Going to the Hornets to 149, Tael Maladon. That's on that one there. Charlotte, and nice one here for the Thunder to 99, Chet Holmgren, Rookie Jersey Auto on the Ink. Grats on that. Okay, see, very nice. We'll call Bridges Orange to 50. That's, and Equinox, Luca to 99. Orlando, Robinson, Rookie. Dremond and J.Dub, Rookie. This one there to 75, Lou Dort, the Dorcher Chamber. Let me go on out to the Thunder, Lou Dort. And to 99, Alfred Schengun, Magnetic Signatures. For the Rock, second year, Turkestan Duncan, good. Malik Beasley, Purple to 99, and Kade Cunningham, Equinox to 99, Kade Base, Caleb Houston, Rookie, Ant-Man. Redemption, that's gonna be A, Dallin Terry. Going to the Bulls, congrats Bulls. Dallin Terry, Rookie Eruption Autographs. Chicago, and nice one here, 11 of 25, Jadon Ivy. Going to the Pistons, there you go, Detroit. Nice one there, Pistons, very solid. Take that all day. Give a chance, thanks, sir. Next one up, yeah. Takigan Murray on the Orbital to 99, Rookie. And nice one here is Volcanics. That is the Super Short-Print Case-Hit, Shade-On-Sharp, going to the Blazers. Very nice Rookie there, got the Blazers. Sohan Rookie, Al Horford, and Boi-On-Bagana. 249, that's gonna be Gary Trent, Game-Use Jersey Auto, going to the Raptors. Matrix material. And Redemption, Walker Kessler, Rookie, Jersey Autographs, Electric, Edge, Purple. Nice one there, Jazz. Lecox C with the Jazz, very nice, congrats, buddy. Patches of some sort, I believe. Well, here's the Orange to 50. And Supernova, Keegan Murray to 75. Halliburton, Gordon Hayward, Jaila Brunson. Nice one here to 75, Antoine Walker, Game-Use Jersey Auto for the Seas. That's Boston, Antoine Walker. Matrix material. And a Jeremy Sohan, Rookie, Jersey Auto for the Spurs. I think we're just gonna skip this recap. Yeah, we're gonna skip the recap, guys, on this one. It's a very quick break, it's only gonna be about 10 minutes in total. Jomerant, Purple to 99. And Orange Tunnel Vision, Kyrie Irving to 35. Nice one there, Dallas, he's a Maverick in this. Andrew Nemhard Rookie, Kyrie, Jabari Smith Rookie. Nice, the 149, Brian Scalabrini, the White Mamba, Lightning Strike, congrats, Seas. Scalabrini, love it. And second year to 149, Davion Mitchell, Galaxy Auto for the Kings. Congrats, Sacramento. Again, teams are on sale in NT, and then you've got 22 to go on 10 bucks, football. It's the only three breaks remaining with spots now, everybody. Orange, Kelden Johnson to 50. Purple, E.J. Griffin to 99. Jabari Walker Rookie, Michael Porter Jr., two of five, the Nasus on Tentacumpo. Yannis' brother going to the Bucks, again, two of five, nice one there, on the Volcanic Signature. And rookie jersey, Otto Max Christie. Very nice, that is one of 25, three color, and technically three color, a little bit of purple on the right as well. Dual three colors, take it, we'll take it. Green, Dilo for the Lakers to 25. And an orbital, LeBron James to 75 for the Lakers. Dual Lakers there. Lani Walker, Paul Pierce, D'Angelo Russell. Nice one here to 149, Jose Alvarado, Grand Theft Alvarado going to the Pelicans. Grads New Orleans, Magnetic Signatures. And 499, Alfred Shengun, Magnetic Signatures going to the Rockets. Grads Houston, second year Shengun again, that's the second one of the break. We'll take that for show. Benedict's Matherin, eggs Benedict Cumberbatch. To 50 on the Orange, Jerry Sohan, orbital to 99. God, that's so funny. RJ, Iota Sumu, D'Angelo Russell. Nice one here, 30 to a 50, Thanesis on Tentacupo again. Going to the Bucks, bunch of Thanesises. You Chris D, picking up a spot, 10 box football. Down to 21 to go now everybody. 149 is Christian Brown, rookie eruption for the Denver Nuggets. How does that say his name? Thanesis. Oh, yeah, say that, it does not. Barclay, nice color match for the Suns. 299 on the Purple, Orange, Jordan Pool. Pool party to 50. The Warriors, that's a Jeremy Grant, Malkai Branham, and DeMar DeRozan. 2250 Clippers, Yvika Zubak on the Magnetic Signatures, Yvika Zubak. And 250, Jake Loravia, rookie eruption, rookie auto. Going to the Grizzlies, nice one there in Memphis. Box, good luck everybody. Jeremy Grant, Purple to 99. And Aaron Gordon to 25 on the Green, A-A-Ron. Kuzma D Wade to 50, Will Barton, going to the Wizards. Nice one there on the Galaxy Auto, it's my guy. 10 to 25, Tyrese Halliburton, two-color patch auto. That is game worn for the Pacers. Congrats Pacers, Matrix Material. All right guys, that's gonna do it for the break. Thanks again for the fill, do appreciate it. Coming up next is Choice.


At the start of the pandemic, we had gotten the mission to really create a system for where there was none. There were no moods, there were no e-learning systems at these schools. It was very basic, very frontal learning. And we were supposed to build a system that can host up to 7,000 schools. And therefore we built the system up so that we can scale school by school and eat school horizontally. So in the end we were able to achieve this, we were able to provision over 3,000 of these schools, which hosts over 1.4 million students.


7 people were killed and at least 18 were injured after the roof of a school's gymnasium collapsed during a storm in Fitchett Province, over 300 km north of Bangkok, on May 22 evening. The emergency personnel worked through the wee hours of the morning on Tuesday to rescue injured victims from the wreckage and recovered the bodies of six people which included students, janitors and parents. The death toll later increased by one when a six-year-old boy succumbed to his injuries at the hospital after being rescued. Residents in the area reported that the collapse took place amid a violent storm. Speaking to local media typibias, an unidentified resident said, at first, I didn't know what it was, I didn't know it was the wind. It was like a battlefield because of the loud noises. I've been here for 40 years and have never experienced such an event.


Welcome to the 100% Shiny Rock Pokemon Hunting Locations in the Teal Mask DLC. If you're looking for any specific Pokemon, make sure to check out the timestamps down below. If you're looking for a certain Pokemon type, check out the playlist for the Teal Mask for any of the typings. And if you're looking for Shiny Pokemon in Paudeia, make sure to check out that playlist as well. For the Rock Sandwich, we're just going to use one jalapeno and two salty herbomisticas. Feel free to use any sandwich of your choice and please write it down in the comments below. Everyone who writes these sandwich recipes are extremely helpful and people do like those comments, so let us know. You'll know you did it right when you have Sparkling Power Rock and Encounter Power Rock at level 3. Now, most of the Rock Pokemon in this video are going to be easy to see except this little guy over here, so make sure you have the double home zoom in technique for that. And in order to do that, just go to your home page, go down to your settings, go all the way down to system and from system you're going to find the zoom option. Once you have that, just turn that on and you should be able to double tap your home to be able to zoom in and see any single Pokemon. All right, let's get hunting. The Pokemon we're going to be hunting is going to be Rockruff. Now Rockruff is in Paudeia, but you know, we're in Kitakami and it'll show up that you actually caught it in Kitakami. So what you want to do is pretty much from right over here from Kitakami Hall, you can go ahead and drop down all the way over here. And since Rockruff is a little more common, we have a good spawning area right about in this area that you can open up a picnic and you can kind of see the amounts of Rockruff that are spawning here. Look at the amount we have over here. There is quite a bit and you can even peek behind you to make sure there isn't any.   Take a second, there you go. Three, four, five, then you get a whole group over there. I noticed the more left corner you go over here, the faster they spawn. So if you want to keep that in mind, I noticed that is a trick to spawn certain Pokemon. You got to find that right corner, run your character into it. You'll get a whole group. Do the picnic again. Get out the picnic just like this. And then if they spawn slow, here we go. Here's the corner we run into. And then you can see all of them start to spawn pretty quick over there. So yeah, this is a pretty good Rockruff spot. They are overall roaming around the map in various locations, but I really do think a picnic reset might be the best play for this one over here. If not, you're not into hunting this mon here. Well, Paudea is a great spot for it and it's evolved forms. All you got to do is look for that blue dog. And in my rock video for Paudea, I do show you how to get the dust form like in rock in the wild. So keep that in mind. There's a very easy way. And good luck hunting your Rockruff. The next spot that we're going to be going to is going to be for the evolution of Banzi Sudowudo. This is going to be located all the way up at the gracious stones area. And as you can see, the only Pokemon that spawns out here is Sudowudo. And of course, the shiny is going to be really obvious for this Pokemon. And they will just all run away from you and despawn out. So it's like easy shiny hunting as they see you and they're just, they're gone. That's it. They're, they're adios. They're gone. And all you got to do is just keep going around until you find yourself a shiny one or you can picnic reset when you have a good amount in your area and reset the spawns. Now something cool I just wanted to point out about the gracious stones is that if you go towards the body of water right over here, besides focusing on the Sudowudos over here, you also run into a little bit of a Dreadnaw situation, which is pretty nice to have because you get a good amount over here in the water as it spawns with the Rock Sandwich. And pretty much you just need to stand over here and do some picnic resets or you can despawn these out completely, walk back to all the Sudowudos and then come back over here and see what spawns exactly. So let me know if you like this Dreadnaw spot a little bit better. I think picnic resetting and having two hunts at the same time might be a lot more fun for people if you don't have these shinies. I just wanted to point this out so you all are aware of this area to hunt in the gracious stone. All right, good luck hunting these two Pokemon out here. If you want shiny luck like this, make sure to hit the subscribe button so you can, you know, catch a shiny. So if you want to get yourself a nose pass, you're going to have to come all the way up to the Paradise Barrens. Now something interesting about the Barrens is that Geodudes and also you get Sudowudos spawning in this area. And what you really primarily want to do is stick to the more rocky areas. So if you happen to see some patches of grass, avoid going to the grass. I think that's the safest bet. Now it's going to be easier to identify the shiny because, well, it's going to be a gold shiny or yellow. So yeah, yellow, yellow rock is all you're going to look for. Look how many spawn on here. You could either do a picnic reset or you can just despawn an entire group out. This place is big enough. But like I said, just avoid going on grassy areas to not deal with any Sudowudos. I notice I get the best spawns over here. So if you want to really get the best spawns, once you get to this Paradise Barrens fast travel, come out here and just spend your time right in this area. And if you do happen to get the shiny here, you can then evolve it into your own personal Mr. Potato Head, which is going to look fantastic. And it's going to gain the steel typing. So good luck getting this Pokemon. I believe in all of you who are hunting and you should be able to get one. Yeah, no problem. It's an easy one to identify. All right, good luck. The next location we're going to be heading to is going to be the Felhorn area right over here. Now something really cool about this location is that there is a water type Pokemon that we're going to hunt. That's going to be a lot easier here because it's the only one that spawns here, which is awesome. So this is going to be your Dreadnaw location. And you can see how many Dreadnaws are spawning in this area. There's literally nothing else besides Dreadnaws that you see everywhere around here. Now sometimes I get a little lag. I noticed that and you guys might be able to find a pretty good spot in order to picnic camp maybe and reset all these spawns. So that's pretty much what you can do when you're out here. This is the shiny that you're going to be looking for. It's going to be obvious and very different as it's green. These were also in the Paudea area if you were to run around by the lake in the Paudea spot. But honestly, I see a lot of solo spawns here. It's better to me than getting a chuddle. But I know you guys might want a chuddle. That's solely up to you what you want to decide. If you go on to the grass areas, you will get rock roughs that do spawn here. So don't worry about that. But yeah, this looks like a good picnic recent area. So maybe exactly in this spot where I am right on a beach. All right. So good luck hunting your shiny Dreadnaw in this area. You'll probably be able to get quite a few of them here with your shiny sandwich. So if you want to solo hunt bondslees that evolve eventually into a pseudo-wuto, you need to head over to the Kitakami Hall at the top part over here. Now this is cool because this is a nice little town spawn. It'll show up as Onimountain. And you will see a bunch of bondslees all the way in the fields. Now, if there is a shiny one, it's going to be very obvious because it looks like this. And this is what its evolution looks. Now the double-home zoom in future is going to be handy because look what is hiding in the grass. Nice and obvious. It's going to be the bondslea right over here. It just appeared and it is a town spawn. So there it is. There we go, baby. Got myself another bondslea. Even though they do exist in the base game, this is literally a solo bondslea spot. So it's so nice to get one of these. Another location for getting a bondslea will be to teleport all the way to the Infernal Pass and then come down over here. So you're not going up that mountain, but rather you're facing down over here. And you can see that you get a good amount of bondslea that spawn over here. This is a great spot to simply do a picnic reset, make them all go away.  So make sure you're just turning around and looking out for that Johnny bondslea in this location. But this is a great picnic reset in case you don't want to do the town reset method. But of course, town's reset method is going to be the better one if you want it to get done faster.  Seriously, it's just in and out. So good luck getting one of these if you haven't already and evolving it into Sudowudo. The next Pokemon we're going to be hunting is going to be Geodude because it's also not just a ground type, but it's also a rock type. And all you have to do is head over to the infernal pass and there will be tons of Geodudes everywhere. The best strategy for Geodudes as usual is just run up and down to despawn a bunch of them. Obviously not too fast because they're solo spawns or get in a really good location where you can see a bunch of them at the exact same time. And you can do picnic resets. This is pretty much how I ended up getting my golden Geodude. It looks pretty sick. Then it's going to evolve into Graveler. And after that, it's going to evolve into Golem via trading. So just keep that in mind when you are hunting this. So this is another sandwich that you can go ahead and catch a Geodude with. All right, so good luck hunting down your shiny. The next Pokemon that we're going to be hunting is going to be Glamet. And to hunt Glamet, you're going to have to head over towards the crystal pool, which is going to be a great spot. Now Glamet is a poison and a rock type, but when you have the poison sandwich, puffings kind of take over more than they do. So that's why the best hunt for this is going to be with the rock sandwich. Of course, this is in the base game, so I wouldn't be surprised if you guys watched my video and caught one of these in Area 0. But if you haven't, you could spend your time out here. Area 0 gets kind of boring of being in the cave and it feels good to be outside to get it. Now Glamet shiny is going to look like this. While it's evolution, Glamora is going to look like this. So you know exactly what you're looking for when you're hunting for the Glamet.  Make sure you're looking, because sometimes the spawns are hard to see and you don't really want to miss that shiny. So really don't go too fast. Just kind of crawl slowly around the area. Make sure you're zoomed out. You're kind of pulling a 360.  That's pretty much how you can do it up here. But there is another location and we're going to go into the cave to do this. And this is weird because it's kind of a segway into another Pokemon and then a dual hunt. So when you jump with this cave, just be a little careful. So you're going to have one thing over here.  When you enter into here, you're going to find a room filled with carving. So this Pokemon is also going to spawn with the rock sandwich. It's also spawned with the berry sandwich, but this is another spot or another Pokemon you can hunt with it. So when you're in this room, the best scenario that you want to do is find a good spot to make a picnic. They'll all despawn. So just like that, throw it out. And don't worry, I'm not done with the Glamet. This is kind of like a mix of a dual hunt. And when you do the picnic and back up a little bit like this, you're going to get groups of harbing, pawning in the area. And this is what the shiny that you're going to be looking for. It's going to be more of a black colored rock with the blue. It's going to be very obvious. Here's the one that I caught in this cave. You can see that. So you just need to keep doing that over here in order to get yourselves a shiny carving. So it's going to be too hard. Just find a nice spot in the ground, drop your sandwich, throw a picnic up, and then back away. Let them all spawn in.  Anyway, we need to proceed further down in this cave because we are handling the rock sandwich. So now we're going to go to somewhere known as the dual hunt for Glamet and more carving. So on this next layer as we drop down, you can see some Glamet over here. This is not really a hot, shiny hunting spot. We're going to go further down and drop all the way towards the water. So here we go. Keep following me. Boom. We splash in the water. And then we want to head all the way down further this way towards this spot over here. Now you don't want to drop down this area, but what you want to do is as soon as you hit this area, you're going to see all these spawns over here start to come in a little bit more aggressively over there. And you can see some spawn above, some spawn on the floor, and you'll get a couple of Glamet. Now, sometimes you will get a Carbink spawning and my strategy here is to send my Pokemon out just to beat them all up while I back up a little bit. So it turns into slightly of an auto battle while they do spawn in. Now, Carbinks do sometimes spawn in with it. I do think this is more of a Glamet hunt, but it's a pretty relaxing one where you can just get up, walk away and come back. And there you go. There's your Carbink that spawn. So that's why I call this spot a little bit of a dual hunt. So let me know what you're doing in this area.  All right.  I hope this helps. I'm sure so you guys will come up with a more optimal way of where to stand exactly the precise track on the floor. So good luck with this hunt. I'm sure you guys will enjoy doing a nice AFK hunt here for this. Now that you got all your Shawnee Rock Pokemon and Kitakami, you should check out this video over here.


On this channel you're going to see physician assistant related and healthcare related content as well as content for students who are just looking to take their education to the next level. So take a look around if you like what you see, go ahead and subscribe and hit that notification bell so you can know every single time I put a new video out. I'll see you guys. I have a video called everything you need to know about the GRE in eight minutes for those of you who don't know anything about the GRE. So please be sure to go over to my search bar and type that in and watch that video after you've seen this video. I'll also leave a link for that in the description box below as well. So you guys I am super excited excited because of this video that you guys are about to see. I did a collaboration with Philip who's also called the tested tutor. He has his own YouTube channel so I will leave a link for that in the description box below so you can check out his channel. But you guys he scored a 340 on the GRE which is a perfect score. Let me say that one more time. He scored a perfect score on the GRE. So he's going to be sharing some of his tips that he used to get a perfect score in the GRE with you all so that you all can also improve your GRE scores. So without further ado here's Philip. Hey guys my name is Philip and I make videos for a channel called the tested tutor. Massive thank you to Adana for giving me a chance to talk to you guys today. My channel is awesome but it will never quite be as cool as her channel. Before I get talking about my 340 in the GRE I just wanted to give you a quick background about why I'm here on the interwebs. My story starts with helping hundreds of kids with maths and English and I kind of got addicted to helping people pass their tests. But what about all those poor people on the internet who can't afford a tutor like me because I am kind of expensive so I thought I'm going to give my advice my amazing secrets out for free on the internet and that's what my channel is about giving my tutoring secrets to those who can't afford for a private tutor. I talk about the GRE, English vocabulary, how to learn in general but I don't know my channel might develop in different ways. We'll see it depends what people want and what helps people the most. But back to my 340 so I got inspired to take the GRE after I heard that it tested vocabulary which is one of my favourite topics and I researched the test by watching loads of YouTube videos including an amazing one by a person called Adana. So kind of on a whim I decided to take the test. I gave myself about a couple of months of preparation study and in a second I'll give you my tips about what I did to improve my score. I had many advantages going into the test of course but I would boil down these three tips as the way that you can improve your score wherever you're starting from. First one, biggest one, do loads of practice questions and practice tests. Most students that I meet only end up doing two, three hundred practice questions including inside practice tests. I think I ended up doing about 2,000 before the test, did about 12 different practice tests from Power Prep, Manhattan and Kaplan. I did all the questions in the official guide, the Manhattan 5 pound book. There's so many questions you can find plus ones online as well. The more questions you do simply the better prepared you're going to be. That's not the only thing you need to do but that is the number one sine qua non for getting that amazing score. Number two is to document your mistakes. It's not enough just doing loads of questions. Every time I made a mistake I would document what I did wrong and what I need to improve on. My determination was just simply this, never make the same mistake twice. If I could reassure myself that I'd never make that exact same mistake twice I knew that I would keep on improving because I didn't start off getting 340s. Also I must say that writing stuff down instead of just looking at the answers, actually documenting your mistakes, I think it just physically helps your brain to absorb the information in a way that just looking at the answers will never do. Third thing of course increase your vocabulary by maybe four to five thousand words before the test. So I started with quite a good vocabulary to begin with but I definitely increased it by several thousand words by using every single available word list I could find on the internet. So my actual favorite one and here's one of my secrets is the 1853 most difficult words. It's like an online resource from Scribid or something like that and I went through and made sure to memorize every word I didn't understand. That's a specially useful tip for those aiming for above a 320 because the words are quite hard. No matter where you're starting you've always got the Economist and the Magoosh app and you can increase your vocabulary by 50 to 100 words a day and overall by several thousand words before the test. A bonus tip for getting the really insane scores like those above 330 is to try to enjoy the process. Now I know you guys are going to be thinking this guy is just crazy how can you enjoy a test like the GRE but the more you can find some fun and amusement in learning like a cool maths trick to show to your friends or learning a new vocab word that you can use to put anyone in any conversation the more you're actually going to spend mental energy and time invested into learning stuff for the test. If you don't enjoy it at all you're just going to stop yourself revising you're not going to want to spend your weekend revising and I know it sounds absolutely crazy if you can try to make the process more enjoyable you will spend more time doing it and that's what I did. I did quite enjoy learning so I invested loads of hours. I know not everyone might feel that they can enjoy the test but the more you enjoy it or let's just say the less you hate it the better the result will be. Anyway that's enough from me I'm about to make a video on the best hairstyle for getting a 340 on the GRE so I'll be right back. Oh Phillip so you've had jokes right um it's an inside joke you guys he talked about the hair I didn't hear a video um if you have not seen that video on my channel about different hairstyles for your interview go ahead and check that video out but um he's about to go make a video on hairstyles for a 340 on the GRE. Thank you Phillip so much for making this video um I learned some stuff for my study habits as well so I'm really going to be taking away just repetition in terms of those questions maxing out on those questions because I'm studying for my pants so that is something I'm definitely going to do I've already done over 2000 and I'm using Roche review and Kaplan as well just kind of get those rapid fire questions so I think that's a really good tip that he gave you guys and also just increasing the vocabulary because when I'm taking some of my test questions as well I'm seeing words like equine and if you don't know that that means horse and then somewhere else it says horse toxin for like diphtheria or tetanus you're not going to be able to put the two together so I think that's really a good tip as well so you guys if you have not already done so go take a look at Phillip's channel the testitutor and see what he has to offer thank you again Phillip for really um just giving us all of this great information I know I'm going to take some of these tips away if you have any questions for him leave them in the comment section below if you have any questions for me as well do the same follow me on instagram at a down in the pa and hit that like button for this video if you really like that um this video I really appreciate you guys and I will talk to you guys next time