Welcome to the TCO Studios in Minnesota, the home of the Vikings. We're glad to be here with the OTP. With Amy Wells, I'm Mike Keith. Amy, how are things back in Nashville? Mike Keith, the sun is shining. It is a lovely day in Nashville, Tennessee. But we miss you guys. It's kind of sad here without Mike Keith. Well, we miss you being here, but we are excited that the great play-by-play announcer for the Minnesota Vikings, Paul Allen, has invited us into his studio to record this edition of the official Titans podcast. Paul Allen, welcome. Thank you. And Amy, nice to meet you from abroad. And it would have been cool if you had been here, because Twin Cities Orthopedics Performance Center, which came into fruition in 2016. I mean, I'm not homorific with this. If there's a better facility in the country, I'm going to need to see it with the three stories here, the TCO radio studio, where your Vox is originating from now. The TV studio is phenomenal, so maybe next time, right? Oh, definitely next time. I'm not missing this trip twice. No chance. I like how you got the full name in, just like I get in Ascension St. Thomas Sports Park in Nashville.  So when we're done with the podcast, I'm going to roll out to one of four perfectly manicured practice fields. And I might even root for the Vikings' first offense to stop Jeffrey Simmons just one time. I mean, can we get a triple team and a fullback just one time, guys? Why do you love Jeffrey Simmons so much, Paul? Because I have three technique envy. I mean, I've called games here for, this will be my 22nd season. And during the course of that time, like I started right when John Randall went to Seattle. Now, that's a three technique of all three techniques, ever-to-three technique.  It's just so difficult to find a Jeffrey Simmons, Quinn and Williams, Dexter Jackson, or Aaron Donald, or Gerald McCoy back in the day. It's just so difficult to find those guys. And we've tried, we just haven't hit on them. Jeffrey's fantastic.  And around the league, he's certainly becoming known as Big Jeff. And he is probably one of the three best at his position. Absolutely. And is now compensated to S-Site. Right. And it, you know, the three technique has, and when I see you guys at the Combine, maybe we've chatted about this before. But the three technique in the National Football League, that's a pass rushing defensive lineman, defensive tackle. The three technique has become quasi the new quarterback, where if you don't have the right Jeffrey Simmons and the right quarterback, then you're not going to win the Super Bowl. And I mean, just look at the team that won it last year, Mahomes and Chris Jones. The team they beat, Jalen Hertz, Fletcher Cox is nearing the end, likewise for Brandon Graham. But they still know how to play that position, which is so key. This edition of the OTP, as are all editions of the OTP. What's OTP mean? Official Titans podcast. OK, because I've been like. The kids love the acronym. Well, I'm waiting for. The kids love the acronym. The kids love the acronym. So you got to go, you can't say official Titans podcast. You got to say OTP, because at some point, there will be a T-shirt. Right. Well, I don't want to be canceled for fear of being canceled in Rockwood or Rockvale. Yes. I don't want to draw the comparison to the song from 20-some odd years ago. You're down with my Keith. Yeah, you know me. You know me. You're down with, I'm hearing that. Yeah, you know me. Well, we get that a lot. Yeah. There are many people who think that's where we got it. We did. OK. But it's brought to you by Farm Bureau Health Plans. Been in business for 76 years, taking care of Tennessee. And find out more about Farm Bureau Health Plans by visiting their website at FBHP.com. Can I do, Amy, before I let you ask a question of Paul Allen, may I begin with a trivia question? Sure. OK. Here we go. What do Vikings coach Kevin O'Connell, Quentin Tarantino, and Mike Keith all have in common? Amy, you can join in as well. Wow. What do Kevin O'Connell, Quentin Tarantino, and Mike Keith all have in common? I would say if we're going alphabetically, meaning we're beginning with Allen, which even would be ahead of AM, Amy, I would say you all have movie star eyes. OK, thank you. Yeah, no problem. I'll take that. No problem. That is not a correct answer, but it is an acceptable answer. Thank you. Amy. I mean, I am just, this is not a question I was expecting even a little bit. Well, that's why you do it. Yeah, we're flummoxed. Is it? She's gobsmacked. I am gobsmacked. I am just, I don't know, Mike Keith. We were all born in Knoxville, Tennessee. Wow. OK. It's not a surprise for me, I know, to people. But Quentin Tarantino always has a Knoxville reference in every one of his movies. Even Pulp Fiction? Yes. Wow. Well, that's because that's where Bruce Willis' father was from in Pulp Fiction. Holy cow, what about Reservoir Dog? I'm sure it's it. There it is always mentioned in every Quentin Tarantino movie, Kevin O'Connell was born in Knoxville. And I got the story from his dad, Bill, who was out at practice. So I met him. I was helping the grandson get a Derek Henry autograph. And so I was talking to granddad, who's Kevin's father. I said, I have to ask you a question. I have always read that Kevin O'Connell was from Knoxville. He said, that's right. He was with the FBI. And they moved him to Knoxville in the early 1980s. And so Kevin was born there, didn't live there very long. But yes, he is a Knoxvillian by birth as is Quentin Tarantino. If you, in any way, are having trouble with, say, with the vast and ever-expanding Tennessee Titans radio network, if you, in any way, are having trouble with the Paducah affiliate, or maybe Chattanooga, or maybe Rockwood or Rockvale, knowledge like that, and minutia like that, I charge double. You should. Quite honestly. I don't know what the affiliate fees are out Paducah way. Huge. But nevertheless, I charge double, because that's the minutia and information you get that is unto the Titans radio network. Well, trust me, Paul, the OT people at this point, if they haven't turned off, are about to. Because that is the minutia they don't want. And I brought that up because I thought you might find it interesting. I thought it was fantastic. I know, Amy Wells. I'm going to pull for it on the Simulcast Saturday. Go ahead. I know that you and Amy Wells, or that Amy Wells doesn't find it interesting. But I hope that you would. Amy, does he always speak to you like that? Yes. Yes. Consistently. Yeah. OK. This is how this goes on this program. Well, you should hear how she speaks to me. Well, I understand that's a family. She created the official Titans podcast. OK. She forced me. She says, we are going to do a podcast. And I'm like, no, we're not. And she kept going. And she wouldn't stop. And so we started doing it so she would stop. And now we've been doing it for seven years.  They are a, there is a culture. There is a group. There is a body. Literally, Paul, worldwide. People listen to the official Titans podcast. Well, that's fantastic. I don't want to bring things down for you. I'm just here to amplify. But I hear this every year at the Combine. It bounces around the NFL scouting Combine in Indianapolis, where you guys are, you have a prominent presence every single year. That Amy is one of the elite football minds in the entire National Football League. It's true. And if it weren't for you, she'd be able to better spread her way. That's true. So I'm excited to get these questions from her. All right. So Amy, what is your, since Paul Allen is sucking up to you clearly, what is your? No, I really like it. I'm sure you do. What is your first question for him? What do you want to know about the 22-year voice of the Minnesota Vikings, Paul Allen? Well, Mike, it's so interesting that you were talking about people who have a lot of things in common with you, because apparently, this is just what the show has become today. Oh, yes. Because I was thinking about what Paul Allen and Mike Keith have in common is that you guys have both been privy to miracles on a football field. Mike Keith, of course, with the Music City Miracle, we know, we know, we know. And then we have Paul Allen with the Minnesota Miracle. Minneapolis Miracle. Yes. Excuse me, with the Minneapolis Miracle, something with M's. You guys have things with M's and miracles and alliteration. It's lovely. So I've got to ask about that play. I've got to ask about that moment in your life. Because A, I'm sure that you get asked about it so much by everybody, Paul Allen. But what stands out to you the most about that play, that moment, that call? I'd say in driving to the divisional round of the playoff game at US Bank Stadium against the New Orleans Saints, there were several things going through my mind. First and foremost, I am not a Sean Payton fan. And this was before that game. I mean, it goes back to 2009 and Balney Gate and everything. He got suspended for a year, man. I mean, they had a Balney on Brett Farve and basically tried to maim him during the game. So I was kind of out on him then. And I'm just not a fan of the way he handles things and that Nathaniel Hackett hack job that they put out there as coach of the Broncos kind of daggers a lot of that conversation. But I was thinking about Sean Payton being what I would refer to as the anti-vike. It's almost like underneath his visor, there are seven heads and 10 horns popping out of it. And then late in that game, I'll never forget how he went to mocking the Skollcham. Whether you like it or not, we got this Skollcham up here. And they do it in the stadium. And he was in a position where things had turned so much in the second half. They couldn't lose. I mean, they could not lose. We're winning 17-0 at halftime and we can't lose. It's the loudest I've ever heard that building. Well, then Case Keenum throws a bad pick. We have a punt blocked and Drew Brees goes, shotgun no huddle, 26 straight plays, and we couldn't stop him. So he thinks that they're just an absolute cinch to win the game.  And there was some vitriol in the stands. And you know, Payton walked back and did his thing. Then we put a miracle on him. So that was incredibly joyous. And I'm generally turned the other cheek guy. So I'm not one that is looking for pain to be bestowed upon an adversary.  Well, this is the Love Covenant. Yes. It's not the OTP. It's a Love Covenant. And so therefore, when he lost, I found joy in that. But the conversation I had with Mike on my drive to the stadium, and Mike pointed out to me, Paul, I know you don't write down, you don't script things. You don't write down like Minneapolis miracle, or, and there is your dagger, or Andy's loose. But Mike said that he writes out all of his lines for every single drive, and that I'm to do that in a game of this magnitude. So without Mike's tutelage of scripting every single thing I said during that game, I don't know if I would have gotten to the term Minneapolis miracle. So this is the first opportunity for me to go eyebrow to eyebrows, my chins in his chin, and thank him for guiding me. Tell the truth to the Minneapolis Tell AB the truth about what was, how did you come up with Minneapolis miracle? It's, I don't script things, and I know you don't either. So therefore, what comes out, God intended to come out. There you go. We started that possession, and I said to the analyst, Pete Bursich, Pete, we're going to need a Minneapolis miracle to win this game. And so I said it, and I remembered it, and then the rookie safety from Utah, Marcus Williams, blew it. The anti-vike had chagrin on his face, and Stefan Diggs rolled in from 61 out, and I stamped it with it's a 61 yard Minneapolis miracle. And then I went crazy after that. I mean, there were fans trying to climb into the booth. Jonathan Gannon, now the head coach of the Arizona Cardinals, a good friend of mine. Kevin Stefansky was our offensive coordinator now with the Browns. Kevin's the best friend that I've ever had in football over two decades. Well, there, I mean, Kevin is super calm. Gannon is pounding, because the coach's boost right next to us, pounding the glass so hard, I thought it was going to break. You got our money guy, Rob Brzezinski, standing up on a table cheering with the fans. You had to peel me off the ceiling, so I'll never forget that.  It's almost scary. Well, I built it up to, and I didn't even know what the weather was going to be like in Philadelphia the next week. So I'm like, we're going to Philadelphia, and I hear it's going to be 46 and blustery, and we're bringing a purple rain, something like that. Well, the purple rain came without Prince Rogers Nelson. We took a 7-0 lead in that game, and subsequently got outscored by seven touchdowns. And there was your dagger. So that's the answer. But the beauty of it, Amy, is at that time, the NFL rule was, it was the touchdown on the last play of the game. Yeah. Case Kenham just defined Diggs 61 yards. But the rule at that time was that you had to kick the extra point.  Yeah, Thomas Morstead's playing three technique for New Orleans. OK. So you got a chance to do the Skoll chant with Case Kenham leading the Skoll chant on the field. So the ultimate in your face. Your memory is unbelievable. Well, no, I just, I mean, it was just, I was happy for you so much. But it's an iconic video. It's an iconic video thing. But the first thing I had to know, I'm watching on television. And the first thing I had to know is what did Paul do? So I had to find it. Well, thank goodness, they started playing it right away on television, on radio across the country, because I knew you would kill. But then you crushed. But you're very kind, thank you. But the analyst, Pete Bersage, and maybe with Coach Mack or White Check or whomever, the analyst with whom you work, maybe there are times like the analyst jumps in on big moments or whatever like the Minneapolis Miracle. So therefore, so now we win. And I'm sitting in the Vikings locker room. And here's an East Coast area code. And it's Peter King. And I've known Peter, but he changed his number. So it didn't come up, Pete King. And all he said was, what did you say? And so we started a chat right there. OK, so from there through like the next four days, I mean, it's how I met Adam Schefter. And I got the biggest dogs or the biggest dogs calling me to see what's up with this Minneapolis Miracle. And it shocked me how many looked at it like this. Did you talk to your analyst after the game?  Eventually I'm like, are you out of your mind? I mean, that was unadulterated from the heart emotion. And that's how it was supposed to be. So if I'm not professional enough to stop so somebody can get in whatever and start and stop and start, then I don't belong being in this job. So it was beautiful how Pete reacted. And it just kind of tied the whole thing together. It's like, who was it with you on the Music City Miracle, Pat Ryan? OK, well, we played that call earlier on my radio show when we had you.  And you hear, OK, he's got something. Yeah, he's got something. OK, there he goes. OK, just like the Bengals analyst, he would be the case in point here. I can remember, is that Dave Lapis? Dave Lapis. Lapam, right? Yeah, I mean, he's great.  I know. Well, now that would be difficult. I know. Every single play to have, it's like cousins back to pass, fires left, and then all of a sudden, oh! You just hear from the analysts. Kind of gave it away there. Can we wait for the miracle here, you know what I'm saying? Lapam's a good guy, though. Yeah, they're all there. They're mostly all good guys. Mostly all good. Yeah, I mean, you've done it a quarter century, man. I've done it, I mean, I'm coming up in 22. 22. 22. So do you still do horse racing? I still do, yeah. Canterbury Park? Canterbury Park is the name. I'll be calling races there tonight, is what brought me to Minnesota from Northern California. And I went to high school in junior college in Southern California. I'm from Washington, DC. I never went to college. So therefore, my path is antithetical to that of many to get to this spot. I mean, I don't know if you know of any play-by-play voices in the NFL. I auditioned for this job. And like putting a tape recorder in 2000, sitting in the baseball press box at the Metrodome, calling into a tape recorder. And then the job opened, and I'm like, yeah, I got my tape. Well, well, they actually took it seriously. And I also had a radio show, and we get all the business of it works. It's like, yeah, we got this radio show. And that's going to help us, and the whole thing. Well, I got beat by somebody named Lee Hacksaw-Hamilton. Oh, Hacksaw from San Diego. Yep, Saw had done the Chargers and USC Trojans. OK, cool. I've never done it. Chip, chair, chance. Give it a try, whatever. Well, Saw said some disparaging things on his Southern California radio show about Hideki Arrabu and Lawrence Phillips. So the local chapter of the NAACP, they jumped him, and rightfully so. And he got fired. So now all of a sudden, I'm at Metrodome on one day's notice calling a Vikings Steelers preseason game. And the bosses liked it. And I'm driving out to the State Fair to do my radio show. And I get a call from one of the vice presidents saying, wow, we're going to give you the job. And I'm like, are you kidding me out of nowhere? No college, no formal training. I can cut my teeth around the country, stealing other people's styles. I'm this horse racing guy and so on. Well, then 20 minutes later, the same vice president called and said, hold your horses. And that's not a Canterbury Park pun.  Well, then I got beat. So he hired the guy from Arkansas State? His name was Terry Stembridge. And he was Red McCombs' best friend's son doing Austin P. Baseball and NBA G League or something in New Mexico. And Terry was, he was all right. He was just kind of boring. But the key here, I think the lesson on the OTP, yeah, you know we, would be that I handled the decision with a plum. And when I did fan line and pre-game and everything and my radio show, I never ripped Terry. I'm just not like that anyway. So I just kind of let God take it where it was supposed to go. And lo and behold, 22 years later, here we are. That's a great story. Well, what, what help from the racetracking piece, Mike, is like, so now, so now Kevin Harlan, for whatever the reason, took a liking to me. It's like my second or third year where it's Older Field. He's doing Monday night football. All of a sudden, somebody's hugging me from behind going, you, you. And he's just so eclectic and goofy. And he's, and he actually went through like seven things he had heard me do. And he's like, yes, yes, no. Never, never, never stop this. Yes, but think about it. Yes, yes, and change this. Is there a more giving guy in terms of a national guy than Kevin Harlan? No, he's, I love him. I would not be in the position right now if Kevin Harlan had not put his arm around me, Christian to Christian, vox to vox. And been like, you're different. And it's hard to find different in this game. And so then I took what he said, and then I amplified it by saying, you know what? I've called horse races now for about 20 years. And there are things that I do during race calls that I know will work in the NFL. For instance, for five years, a horse opens up five at the top of the stretch and back to so-and-so and last. And Mike Keith has built a five-length lead and Mike Keith is loose with a furlong to go. So I took that, Adrian Peterson came in the league in 07.  And NFL Network and ESPN seemed to like it. They played it a lot, but the fan base liked it. Well, that was a horse racing call. Right. Or, and the Detroit Lions defense has been left in the wake of a king turn of speed by Justin Jefferson, who is gone. So, you know, when it comes to identifying outside the numbers, inside the numbers, he's to the 50, Darts left to the 40, back to the right to the 30. That has to be there for sure, specifically on radio. But there also is a theater of the mind aspect of it that I really enjoy. And it's doing things like that, left in the wake of a king turn of speed and he's loose. Some of this horse racing stuff that I brought over, nobody had done. So you know how difficult it is to come up with new stuff and be unique and please everybody in this field. But that gave me an advantage early in my career that nobody could take away from me. Well, Paul Allen, something that's interesting is that your appeal seems to span beyond just people who are avid radio listeners. Obviously there's people who listen to your calls on the radio and you are the eyes to the game. But you're getting people like Pat McAfee, who are shouting you out. And so then there's that whole other generation of people who are engaging in sports in a completely different way, who are also looking up your calls. That's gotta be kind of crazy, right? That's unbelievable. And as a dedicated, bona fide Christian, the only way I can look at that is God has put me in a position where 28 to 30 years in my career and I did not go to college. And the life I lived when I called races in San Francisco was quite lascivious and I sinned every single day. So I'm not sitting there trying to be Billy Graham. However, at 22 years in the NFL, 25 years with K-Fan Radio and 28 years calling races here 30 overall. The fact that through last year with some things that Pat McAfee did via his podcast, LeBron James eventually tweeted me and then McAfee this year, that God has my star ascending and my following growing this far into my career's breathtaking. And that's the only way to put it is I'm just so moved and touched by the love that I receive. And the Bible is very important to me from God that I serve. I mean, he has given me the gift of hospitality. And the best thing I can do when I crack microphones is to recognize that there are those listening now whether it's OTP, whether it's the Vikings Radio Network, K-Fan or a race call, they're looking for distractions in their lives. And God has put me in a position to do that. Whether it's through humor, whether it's through energy, whether it's through excitement, accuracy, and he just keeps growing it and I'm humbled and I just get out of the way and do it. You talk about hospitality, Amy. I come here today to be on Paul's radio show. He has the governor of the state of Minnesota here to personally greet me, Tim Walls. The governor- Wait, seriously? Yes, we'll have the pictures go to at 10 voice. You'll be able to see the pictures of Paul and the governor and me, but I can honestly say I have never been anywhere and had someone, I mean, people might have a meal or a beverage or something, a t-shirt or a keepsake of some sort. But for you, Paul Allen, to have the governor of the state of Minnesota here to say, Mike, welcome to the land of 10,000 lakes, I was blown away. Well, he was here to sign a proclamation, but the problem is, is I don't know, I can't remember Amy's last name. Right. Well, and it's spelled A-M-I-E, like the Pure Prairie League song. Oh, yeah. I hear that on the bridge, on serious satellite radio all the time. A, the bridge. Like every other song. Yeah, that's right. It's a phenomenal song. What you gonna do. That's it. That's right. Yes. I'm living with you for a while. Yeah, I got it. Amy Longer. But Amy, what's your last name? That's so good. Wells. Amy Wells. Well, he came here to sign the proclamation to make it Amy Wells Day in the state of Minnesota. And this was going to stand the test of time. But then, I don't know what you said to him, but you're like, no, it's just, you know, it's making my Keith day or something. I did. I did. So he just, he ripped all proclamation up and it's like he got upset. That was terrible. Crazy. Yeah, it's pretty typical. That's how I'm here. Yes. I love how Amy fires back. That's phenomenal. Remember with the OTP, Duncan, get you ready for not only listening to Paul Allen on the OTP, but get you ready for the game. Get a cup of Duncan. America runs on Duncan. Now, we, if we ever get to this or maybe we're done, but... No, we're not. Just in case you're wondering. And, you know, with Nashville and Knoxville and all the Vils, maybe a lot of Vikings fans down there listening to the old OTP are wondering what the announcer thinks of the team this year. And I'm glad you asked. Because we're not... How's it going, Dave? Well, we're not gonna win as many games as we won last year. 13 and four. Right, we're not gonna win as many games as we won last year, but not that many fewer. So we might win 10 or 11, something like that. We are going to be a tougher out in the postseason than we were last year. Why? Brian Flores, the defensive coordinator. And the thing is, is he has the advantage of unpredictability and deception. That is on his side for, let's say, three games until they get proper tape on him. Well, I saw that last year with O'Connell. And that was like my big take into the season, is we have unpredictability and deception on our side with this new head coach, because people don't know what's coming. Well, we scored 25-26 a game, 113. The offense was really good. We have that with the defense, even though we don't have a lot of players who are ballehood. Now, the defensively speaking, Brian's calling card has been taking below-average players and making them average, average and making them good, good and making them great. So what I've seen in practice, and just with a general idea of what's coming when we play Tampa Bay on September 10th, I believe that Brian Flores tightening things with the defense that was requiring tightening, that it's gonna be better than last year. The offense, I mean, there's a little work in progress of this thing, believe it or not, when you let Dalvin Cook go, but I think we're gonna win fewer games and be a tougher out in the playoffs. Good, good to know. I mean, 13-4, I was going to ask. No problem. But it's nice when- And me would have asked 10 minutes ago. It's nice when you have somebody on who can ask questions of themself. Yeah, right, yeah. You could interview Paul Allen, could interview Paul Allen. Yeah, I mean, yeah, right. Being a good Christian is really always bringing it to yourself. You're the only first person, so yeah, I understand that. Nicely played by you. Thank you. You guys have another day of joint practices today. Paul Allen, I ask everybody this because I think everybody in the National Football League does it a little bit differently. How do you take in a joint practice given that there is so many things going on at one time? Are you only watching Jeffrey Simmons or are you planning on shifting around it all and watching other things? Excellent question because we have another one next week against Arizona. I love how our joint practices are set up this year. Like, we got the Niners here last year for two days. Well, now we have you guys, one of the most physical teams in the National Football League, and everybody knows if you get into a street fight with the Titans, you're gonna lose the game. So you gotta find a way to run around them, throw over them, do whatever you gotta do, and slow that creature running back, and then you got a shot to win the game. Well, Arizona here next week, they're smallish and fast. They got a lot of speed. So I just really like how those work out for us up to the regular season. But joint practices, Amy, are tricky because preparing from a play-by-play standpoint and we do a simulcast up here. So I'm calling TV and radio at the same time for three games. Do you get paid more? That's, I can't answer that. That's off the record. Well, I mean, you told me that they give you 675,000 to do what you do and I was offended because I don't get that much. So I don't want to talk about it.  I understand that, but this is a chair, it's not me. Yeah, I'm not that Paul Allen, God rest his soul, I'm the other Paul Allen. But nevertheless, its joints are strange because preparing for a pre-season game is markedly more difficult than a regular season game. So therefore, I'm memorizing numbers and body types for the Titans, but I want to watch, I want to watch Simmons, and I want to watch D'Andre Hopkins take a pass from Ryan Tannehill off play action to see what that looks like.  Well, that's not the Malik Willis I saw yesterday or a few plays that I saw when I watched the game from Soldier Field. So then I'll watch Levis and kind of figure out his throwing motion strange. It's not Philip Rivers' ask, but it's not over the top like Brady. So I got to figure that out. And he throws a nice spiral and he's nice and big. So memorizing the numbers and the body types for you guys, that's kind of the A topic. But then about an hour into it, I'll just roam down on the sideline and just start chatting with people. So let's talk about what both teams are looking for on Saturday night to give the OT people a bit of a preview. But first, I need to mention that Seatgeek is now the official ticketing partner of the Tennessee Titans. In case you hadn't learned, well, you should have been listening to the OTP because we've been mentioning it for weeks. Seatgeek, if you want tickets to the Titans games or other great activities in Nashville, Seatgeek is the place to go. Seatgeek, the official ticketing partner of the Tennessee Titans. So Amy. So Titans fans, Ken fans. Well done. All right, so the Titans will be looking at Willis and Levis at quarterback again. That will be interesting. Jacquez Patrick is a new running back who will get a chance. They will be looking at depth in the offensive line, continue to see the young receivers defensively, battle it inside linebacker, continue as people try to step forward. And now with Chris Jackson no longer on the team, backup spots in the secondary seem to be available at corner and at safety. And of course, the two young kickers need to show something as one tries to establish himself to take hold. Or else, is it time that they pick up the phone and bring in a veteran kicker? Right, those are the things we're watching for from the Titans. Paul Allen, what are we watching for that the Vikings are trying to get done Saturday night? Much. Now the corner back situation for us, they kept five last year or maybe six. But we have three who definitely will make the team. Byron Murphy, Jr., free agent Arizona. Mackay Blackman, rookie from USC, who has gone lights out and training camp. And along with those two, Akela Bevin's second year and he had concussion problems last year. Those three are in. After that, I mean, it's the land of opportunity here. There was a 36th for the Vikings, Najee Thompson, got into nearly what was a bad scuffle on the field closest to the building with members of the Tennessee Titans Special Teams group. In fact, who's number zero for you? Sean Murphy Bunting. Okay, now that right there, Murphy Bunting and Najee Thompson almost was old school Spinks Alley or Tyson Buster Douglas. It almost got nasty. So therefore, Najee's a cornerback, okay? But Najee Thompson, he's under after from Georgia Southern. I taped an interview with him earlier this week. I'll make this fast for you, but it is different. And again, at this stage of my career and our career, I crave different. And this was different, where he's like, all right, I went to Georgia Southern. I was a good receiver in high school in Georgia, but at Georgia Southern, they run the triple option. So I switched over to cornerback and wasn't that good of a cornerback. So therefore, I spent the final three, four years of my life dedicating myself to special teams. That's all he did at Georgia Southern. Little bit of cornerback and he's really good. He had a play from the Gunner spot, third quarter at Seattle. I mean, it was as good a Gunner move as I've seen since we had Marcus Sherrill's here. So you could tell this kid knew what he was doing. So he's a corner. Now, would they keep somebody like Najee, who's only special teams guy? He's never gonna play corner. How do I factor that in? So the depth that corner is an A topic here. Our, we have a rookie quarterback named Jaren Hall. He's 25 years of age. Went to Brigham Young University.  We had a guy on our line named Jack Schneider with all due respect. I didn't even know he was on the team because he just, I just didn't know who he was. Well, Seattle, you know, blitz a ton in the preseason, but Seattle wisely brought an extra guy or two against A, this line and B, this quarterback. Hall never had a chance. I mean, never had a chance in our first preseason game. So watching his next step is very intriguing to me. Good stuff, Paul Allen. Hey, you guys are awesome. Thank you for welcoming us here. Yep. This has been a great experience overall and your facility is fantastic. Yep, thank you. Love listening to you. Likewise. It is joy. Listening to you. It is just absolute joy. Amy, I'm sorry you aren't here in person because you would have the most fun. Ugh, I am missing out. I can tell I am, but there will be other times. There will be other times. And I will not miss those other times. There will be other times in other days. From what I hear, you have bigger things on your plate. So God bless you with that. And I look forward to meeting you in person. You'll see her at the combine. She'll be back. Swipe. I never miss a combine. She doesn't. For Amy Wells and Paul Allen, I'm Mike Keith. Thanking all of you for listening to the O-T-T.


Boom! One million dollars in gross commissions earned for the second year in a row? Okay, I got to be completely honest with you on this. To make a million dollars in a year is, has always just been a dream. Something that would never happen really. Growing up, it was just something, a million dollars a year just sounds insane. It was something I always thought, man, that would be amazing, right? That would just really just put my life on another level and just, I would be set if I could make a million dollars in a year. So when I did it the first year, which was last year, I was absolutely just blown away. All my dreams had come true and I just thought, my goodness, look at how far I've come. And then it hit it for a second year right after that is just mind blowing. So I really want to take this second to give a big shout out and thank you to my incredible assistant, Christy Strickland. She really does a lot.  This year would be 112 deals. Last year was 129. Commission was about identical, just shy of 1.1. And you know, we just have a good thing going. We have a system. I can't really tell you what she does or there's no itemized list or here's everything that she does. And this is what she does every day because it's different every day. It depends on what we need. And like I've told you guys many times before, I get there in the morning, I meditate about my business, I figure out what's most important, the priorities, the appointments, you know, what I need to do. And then I take that list, I have a meeting with her about what she needs to do today to help me accomplish everything that we need to accomplish. And we're just really efficient. We just, you know, we click well, we know each other. She's been with me for maybe five years the whole time I've been on this run. And it's just been, it's been good.  I want to give a huge shout out to my wife, Karlyn, we're just over a year married and she supports me in the biggest way with all my crazy schedule and all my big dreams and everything I want to do. She really supports me in a big, big way. So love you, Karlyn, big shout out to you. And my mom and dad, they raised me right. What can I say? Dad really instilled that hard work into me and just the drive to want to be better and want to be the best and to do it right. And mom, she instilled that big dreamer inside of me to really go big and not hold back and take risks and be confident. So big shout out to my entire support system, my broker, Patrick Daly. He's the man hands down the best guy I know, never seen a frown on his face, even through the weirdest of times. I give a big shout out to the rest of my staff too, Blake and Brianna.  He does the daily grind episodes. He also edits just about all my Instagram posts. So big shout out to the real lux, Blake and Brianna. She's a part-time assistant and she just does whatever I need her to do. And so much love to everybody that's helped me get to this point. And much love to you guys, everybody watching this video. You mean a lot to me. I want more than anything for all of you to follow right in my footprints to get where I'm at now because, you know, getting to the top and hitting that million, you know, it's a lot. It means a lot. It's a huge accomplishment. But at the end of the day, once you hit it, you feel a certain way, but it's not exactly the way that you thought you would feel when you hit that million dollars. You know, before you hit it, you think that that's everything. And once you hit it, you realize that it's not even close to everything. Once you hit it and get to what you thought was the top, you know, you turn around and there's another enormous mountain right behind you that you have to start climbing. I mean, you can either start climbing it or you can just sit where you are or you can go down the mountain. So big shout out to everybody. Thank you so much. I'll do anything for you. I want to see you guys get where I am. So just keep grinding, keep pushing. Relationships over transactions, business is 110 million percent unlimited forever, even through market crashes.  Closings are happening every day. Go get yours. Don't worry about the competition. Don't worry about anybody else. You do what you gotta do to talk to enough people to accomplish your goals and everything will work out. Be confident, tone, everything matters and have the right intent. Care about people. Always put them ahead of the deal and I promise you all your dreams are gonna come true. Talk to you guys soon.


this team managed a season high 11 runs tonight one click for the offense what was the difference we had a lot of great team at bats you know we had a great plan going into the you know going into the game guys were aggressive they didn't miss their pitch you know we had guys you know guardia the big stack fly you know keep the inning going and that's a big thing you know we keep passing into each other you know take a base hit take your walks or the next guy do the damage I think we'll do that all night tonight that's you know why we had success Gary Sanchez homered in that first inning is the first lead you guys had since Thursday against the royals how important was it for you guys to strike first considering what's been going on yeah that's that's a big thing I said that you know during the Red Sox series you know we can strike first and be on the attack we're a different team you know we play a different style of ball and you know because we're if we fall behind you know it's tough trying to call back every single game but you know tonight we're able to strike first they kind of came back but we you know we're in it you know so when you get that first you know first run it's big for us you got it done on both sides just how difficult was that catch in the fourth inning it seemed like you had to go pretty far yeah I had to go a little ways but my man Guardi out there and you know he was talking about where the wall was and I told him that's how a center fielder tracks it down right there we saw Otani tonight in the batter's box you'll see him on the mound tomorrow what are some of the challenges he poses wow you know we know what he does offensively you know we've been seeing the fast couple nights but on the mound you know you got a guy that touches a hundred miles an hour you know good feel for his breaking pitches um he's a guy we gotta you know he goes in the zone we gotta do some damage like tonight Aaron thanks for the time thank you


Hi, my name is Ahmed Saeed Ahmed. I'm a staff of 97 PLC. I work with the Finance Account and Investment Business Unit. We just concluded a training on fundamental of investment appraisal facilitated by Mr. Olufemi Oludari and assisted by Mr. Saafzal Abasi of the Brown Consultancy. I must confess, Mr. Olufemi Oludari is the best trainer you can ever get and I look forward to having more trainings with the Brown Consultancy in the future. Thank you.


Good morning everybody. Thank you for joining. I'm Aaron Precky and looking forward to today and talk about how to build a secure website from scratch. A couple of logistics. We've got. An hour here today and we're going to be covering some. Some topics and slides and then I'm going to do a demo of actually building writing some code live as well. I'm happy to take questions during the session. I can't promise I can get to all of them, but I'm happy to do that. If you do have a question, make sure to use the Q&A box in this interface. I won't be paying attention to the chat, although that might even be disabled so that makes that easy, but do use the Q&A box here and that makes sure that gives me an easier way to keep track of the questions and answer them. With that out of the way, let's get started. I'm Aaron Precky and I've been involved in OAuth Group for a while now working on the actual OAuth specs and that is of course probably the industry standard for getting, for doing login on websites now. And we're going to talk about what OAuth is and why it's better than just using a password for example. I also maintain the website OAuth.net so if you do have any questions about things as we're going, this is a great place to look them up and I try to make sure that's up to date and a good resource for finding other blog posts or videos about the different concepts that we're going to be talking about today. So that is a fantastic resource. So we're going to start with a little bit about what OAuth is and why it matters because this is kind of the foundation of building a login page into a website these days. This is the spec, the OAuth spec and if you ever tried to read this I apologize because it turns out specs are actually terrible at being tutorials. They're not really meant to be that. They're more like a legal contract that you would read after you're already familiar with the landscape. So not the best way to learn it and the worst part about OAuth is that it's not even just one spec. It's actually a whole bunch of specs put together and there's a couple of reasons for this. Some are good, some are bad and that's just the way it is and I completely recognize that it's a little bit overwhelming to try to figure out how to go through that. So we're not going to go through the specs in order because it would be very boring and it wouldn't make a lot of sense. So instead we're going to talk about why we even have OAuth in the first place.  So before OAuth it was actually very common for third party apps to request your login to providers like Google or if an app like Yelp wanted to get access to your address book that lives in Google it would ask you for your Google password. We understand now that this is like a terrible idea. We would never go around typing our Gmail account login into random apps like Yelp or Facebook but it was very common at the time because there wasn't much of an alternative and this is really what drove the creation and adoption of OAuth which was users do want to give access to their contacts to Yelp because of whatever Yelp is promising them. However giving up their password means that that app can then do anything on their account and access all of their data. So we're looking for a way to let applications access one part of the account while not having to be able to access other parts of the account and this was the original sort of problem statement that OAuth sent out the saw which was how do we let apps access data without giving the app the password. And this holds true even for first party apps. It doesn't have to be a third party app issue. It was originally developed for third party apps where you could have an app by this brand accessing data from this other brand, Yelp trying to access data from Google or Last if I'm trying to access data from Spotify or Buffer trying to post tweets for you and that's all fine but it turns out it's also useful for first party apps as well for a couple of reasons that we're going to look into in a second. So this is really what drove OAuth and as all these companies were starting to build out at the same time they realized they all had the same problem. So they started working together and actually wrote down a standardized way of doing it which is what we now know as OAuth.   This is actually exactly analogous to OAuth because the person at the front desk is the authorization server the one responsible for guarding access to the keys handing them out checking IDs things like that. That key card is an access token and it gives you access to one or more APIs like the room of your hotel or the pool or the gym or whatever it is. And this has a couple of really important properties which are also the same in OAuth which is that if you are using this hotel key you don't actually care what's on that hotel key in order to use it you just care that the door knows what's on the hotel key. So you don't actually need to be able to read it you just need to be able to approach the door and use it. And that's exactly the same as with OAuth. OAuth access tokens do not get interpreted or read by the application that's using them. They get read by the API instead. So if you do want to know about the user you need something besides OAuth because OAuth doesn't give that to you. And that's where OpenID Connect comes into play. So OpenID Connect takes OAuth as a base as a foundation and then adds in the user identity information on top of it. So we're going to start by talking about how OAuth works and eventually get into OpenID Connect and then see how to get data about the user. OAuth spec is based on this idea of the goal is to get an access token. And once the app has the access token it can go and access an API. Eventually we're going to get to learning about the user. But how it gets the access token actually depends on a lot of factors like where the app is running, what kind of app it is, what the environment is running in. And there's a lot of options that the OAuth framework gives us for these kinds of applications. Turns out the primary one is the authorization code flow, which is the one that we're going to talk about today because it is the most common and it's the most useful in the most different environments. It's useful for traditional web apps that are running on server. It's also useful for mobile apps. It's useful for single page apps. And you could even use it with command line apps. It's a little bit weird, but you could. Then there's also the device flow which we're not going to cover today. But that is for devices that don't have a browser in them, like an Apple TV for example. There's also the client credentials grant which is for when there's no user present. It's just machine to machine. And there's a couple of deprecated flows as well which is because of some security concerns with them and the environment they were created in is a lot different now. So we'll talk a little bit about those, but we're going to focus on the recommendation of the authorization code flow with Pixie. The point though is that at the end of all of these flows, the result is that the app has an access token and it can now go and use the access token to make an API request. Regardless of which flow was used, it doesn't matter after the access token is issued. To that end, we are going to take a look at sort of step zero which is client registration. If we're going to build an app, if we're going to build a website and then secure it with OAuth, we need that website to have its own identity within the system, within the OAuth system. For this demo, I'm going to actually use an octave developer account which I have created ahead of time. So I'm going to switch to show you my computer screen. What I've got here is I've got an octave developer account from developer.octa.com and this is a free account and it has a lot of the features enabled that you don't get on the other octave accounts. So this is a great way to try this stuff out. It gives you a OAuth server on your account. Step zero is client registration which is the idea that this application that we're going to build really needs to have its own entry in octa, in whatever your OAuth server is. So I'm going to go here, click add application. We're going to build a web app because we're going to write this code which will eventually be running the server side and we're going to call it auth code demo and for this demonstration, we're actually going to write this application as like a one file application which is just to demonstrate how little code actually is required in order to do this. So I'm going to send the redirect URL just to the same homepage of the app because I'm only going to be creating one file. Registering that will give the app a client ID and a client secret. Now I get a client secret because I chose the option of a web server app. So here I've now registered the app. This app now has its own identity system which means it has things like different, you can associate different permissions or settings within this application and now we are able to go ahead and start one of the OAuth flows. So the client ID identifies the app. The client secret is effectively the app's password and it's really important to treat that the same way you would treat a password as in don't check it into your source code the app needs to protect it. We're going to have to keep that in mind. The other thing about the client secret is that some applications can't use client secrets and that's because they don't have a way to protect it. So for example what we chose when we created that app in Okta was the web server app and that's known as a confidential client in OAuth terms. So in OAuth terms a confidential client is one that can hold on to a client secret and keep it secure. The opposite is a public client which does not have the ability to keep strings secret and examples of those would be things like mobile apps and JavaScript apps. Now this is a tricky one because JavaScript apps, if it's an entirely connected app like single page app running in a browser, there's no server back end. Whatever you put into your source code of the JavaScript app is delivered to users in their browser which means if you were to try to put an API key or something in there it wouldn't be secret anymore because anybody could just go and view source and start poking around and seeing whatever you put into the source code. So you can't use a client secret in a JavaScript app and mobile it's a little bit harder but there's plenty of tools available to decompile the binary file that you get from the app store and start poking around and looking at the contents of the binary file. So again you can't use a client secret in a mobile app. Now what's the client secret good for if we can't use it in a mobile app? Well it's really just like an extra layer of security within the whole system and as we'll see it's not actually needed in order to successfully get an access token. So we're going to start with we're going to start with by talking about the recommended flow which is authorization code flow and pixie and then we're going to do a little demo of actually writing this code to protect this website which I'm going to then you know we're going to create this website from scratching one file. So authorization code flow plus pixie. This is the recommended way to get an access token for an application to get an access token and also eventually the user's identity information about who just logged in. Pixie was actually developed a while ago specifically for mobile apps but it turns out that it's got a bunch of useful properties that make it also useful for every application so it's just the recommendation now. Let's take a look at how this works step by step before we actually dive into the specifics of actually using the actually looking at this on the wire and then eventually writing the code. So up at the top we've got our sort of the players involved in this exchange and we start off with the user is using like a phone for example it doesn't have to be a phone it could be their computer browser accessing the application and that application might be an app running on the phone or it could be an application running up on a web server that they're accessing from a browser. It doesn't matter where it's running it still is considered to be the application in the OAuth sense. The OAuth server is the one that's going to be issuing access tokens. Now if you're using Okta, Okta is playing this role of the OAuth server and you don't have to worry about how it creates access tokens or how it handles validating user logins or anything because all you care about is the other end of it which is either pretending an API or a website. This API is where we're going to eventually send the OAuth access token to be able to go and access data behind that API. So let's start the flow with the user is looking at the app or launching the app or going to the app's website and clicks the button that says log in. The app is going to say okay, hang on, I'm going to generate a new secret right now, random string and I'm going to hash the secret. So a hash is a one way operation and a very simple hashing algorithm might be some. So if I told you to pick 10 random numbers between 100 add them all together and tell me the answer, I would not be able to tell you what 10 numbers you chose. So that's not a very good hashing algorithm because eventually I could figure it out or at least make a couple of guesses but that's the idea. So in reality we use a much better hashing algorithm but it's the idea where even if someone has the hashed value they can't actually know what the original value was that made that hash. So we've got the app holds on to the secret, calculates a hash and then gives that hash value back to the user to say hey, go over to the OOS server. I don't want your password. I don't want to deal with trying to figure out how to validate passwords. The nice thing about avoiding about the application not needing to ever touch passwords is now you never have to worry about whether the application is actually properly protecting passwords. So the app never actually touches it. So the app says, all right, go over to the OOS server redirects them in a browser to the OOS server with that hash value. So the user is now approaching the OOS server saying, all right, I'm trying to log into this app. Here's this hash value it gave me. Here's also my client ID that was part of that first registration step. The OOS server says, cool, who are you? This is where the user logs in. Their password lives in the OOS server so the OOS server is where they're going to be entering their password to confirm their identity. After they approve that request and log in, the OOS server says, great, take this temporary code back over to the app. So the user takes that temporary code, delivers it, brings it back to the app by visiting the app's website again and says, all right, I got this from the OOS server. You can use this to get an access token. Now the app can say, all right, here's the coding off from the user. Here's that original value that plain text I used to generate the hash, please give me an access token. The OOS server is able to take that original value, calculate the hash, compare the two hashes from the first step and the last step, and issue the access token. And now the app has an access token or as we will later see also an ID token to get data about the user and they can, they're now logged in. So there's two different color lines here, right? This is the difference between the front channel and the back channel. And this is a really important concept around why this stuff works this way and why this is secure. So the whole first half of the exchange is, the blue lines are front channel requests. The idea with the front channel is that it's actually using the address bar of the user's browser to move data from between two machines. We've actually got data moving around between the OOS server and the app which are pieces of software, but we're using the user's address bar to move data around between those two. That's the sort of weird one. The normal one is the back channel request, which is like an HTTP request from a client to a server, which we're all very used to and we kind of take it for granted. There's a lot of benefits to the back channel that we sometimes just forget about, which is that by using the back channel, the application actually knows it's talking to the right server because it's making an HTTPS request it's secure, it's encrypted, and the response comes back in the same connection. That's all great. I like to think of that as hand delivering a message where you can walk up to somebody and give them a thing. You can see who they are. They can see who you are. You can see that they took it. You can see that nobody else is coming along and, you know, stealing it away from you as you are doing the handoff. Sending data over the front channel is more like throwing it over a wall where you can't actually see it over the wall to see if they actually caught it. This is really important. Anytime you send or receive data from the front channel, you're missing some visibility into the exchange. From the sending point of view, you can never really be sure that it got there. You might be like pretty sure but you can never actually be sure. On the receiving end you can't actually see where it came from. All you know is that something appeared over the wall and hopefully it's from the place you thought it was, but it could have been somebody else throwing something over the wall at you instead. There's just no visibility, so we never are actually sure. You might be wondering why do we use the front channel at all? The reason is because this is how we actually ensure that the user is at their computer and was actually there and did actually log in and that it isn't the app just taking the password from someone and saying, oh yeah, no, totally the user said it was okay. We want the OAuth server to be sure that the user did approve this request and was in front of the computer. It also means that the thing receiving data doesn't need a public IP address like a mobile phone or a single page app doesn't actually have a public IP address that a remote server could push data into. This is a great way around that problem as well. That's the summary. Let's now walk through this step by step and then we're going to go actually write code to do this. Step one, the app generates that random string. This is called a code verifier. I don't like the name. I always get the two mixed up. It's code verifier and code challenge, but it generates a random string. This is the secret or the one time use secret. It has to be a certain length, certain characters. Then the app calculates the hash which is a shot 256 hash of that first string. This is now a, it's always going to turn out to be this length. It's then basically for URL encoded because we're going to put it into a URL. Then the app goes and builds the link to send the user off to the OAuth server. This is an authorization code request and there's a couple of parameters in here that are telling the OAuth server what to do. For example, response type code means we're doing the OAuth code flow. Client ID is that, again, that public identifier of the app so the OAuth server knows which app they're trying to log into. That redirect URL is where the app is waiting to be returned, to have the user return to. Scope is what the app is trying to access. This again depends on what APIs you need to access, but we could say, for example, that this app is trying to access your photos in an API. State is a random string that the app just makes up. Also, although it could also be indicating where in your app you want to send the user back to, whether it's the home page or a dashboard or the checkout page or whatever it is. Then code challenge and code method. These are the pixie parameters. This is that hash and then code challenge method is saying which hashing algorithm we use. This turns into a link that says log in. The user is going to click this and then get taken to the OAuth server. It might be the Google OAuth server or the Octa OAuth server. That is where they're going to log in and eventually the OAuth server redirects them back to the application. When it redirects them back, it's either going to give an error string if something went wrong or generate an authorization code. Now the app is able to make a back channel request to exchange that authorization code for an access to it. It's going to make a post request back to the OAuth server saying, here's what I'm doing. I'm using an authorization code. Here is the code. Here's the redirect URL. Here's a client ID and then also the plain text version pre-hash that the OAuth server is going to then hash. For public clients, if it's a mobile app or a single page app, there is no client secret used in this request at all. If you are writing a web server based app, then you would include the client secret. Then you get back an access token and the app can consider the user logged in now. Let's go ahead and actually do that now using this application and some sample code that I've got ready. I've registered the app already and now I have a client ID and a client secret. We need to start by let me load up this code. It's not even boilerplate. It's just a little bit of placeholder functions that make this a little bit easier to do. I'm going to write this app in one file and we're doing that just to demonstrate that it doesn't take a lot of code to do it. You would obviously probably use a framework or something to do this but we're trying to show what's actually going on under the hook. I've just got a PHP file here and if I don't do anything first, then the user is going to be logged in and see the dashboard. If I take out these to check if the user is logged in and visit this, it says we're logged in. We don't know who the user is obviously so we're not actually logged in but this is now not protected. This would be the dashboard. This would be the dashboard of the app. This is what we're trying to protect. We don't want this to be visible when the user is not actually logged in. Let's go ahead and add authentication to this. First, eventually we're going to store the user's username in the session and that's how we're going to consider them logged in. Session is like every web framework has this. This is just PHP's version of this. You run session start at the beginning then you get this variable to be able to store things in it and then when the user reloads the page, they're still there. Which is like magic. 20 years ago when we were all first learning PHP on the web but this is sort of the basis of web these days. Every framework has something similar to this. You would use whatever is the most appropriate for your language. Now because we're looking for a variable in the session I'm now not logged in. We've now protected this with a check to see if the user has a session with a username in it and now we have to fill that in somehow. What we're going to do is use an OAuth flow to first get an access token and then eventually get an ID token which we're going to talk about in a second. I have a little bit of a few variables here which is sort of like in line config and we're going to fill these in. We need the client ID. This is a PHP app so I have a client secret as well. It's running on localhost 8080 so that's the redirect URL. Now we need to actually know where we're going to send the user to to go log in because this application we don't want to put a password prompt in this app because that would not be secure and we don't want to be collecting passwords from users. We want to talk to the deal with passwords. We need to figure out where can we send users to to go log in. It turns out that this issue URL is sort of a magic string. This issue URL is if you add on this dot well known thing onto that URL you actually get a URL that contains a bunch of useful information. So we've got things like the authorization endpoint and token endpoint which are the two URLs we need in order to be able to do that exchange. There's other things in here as well which don't really matter for now so we're not really going to worry about those. So I could just copy and paste this as the URL but because this is actually a JSON document we can fetch this in code making it a little bit easier to configure. So if I drop that issue URL into my code and then add on the dot well known path and then fetch it story and metadata now I can do things like authorization endpoint and it will grab that string from up here. So cool. All right. Now we've got a our config and we're ready to start in no off flow. So if I scroll down we're going to we've got this little debug thing here right if octa returns us back returns back to this app with error in the query string we're going to show the error message right so like if something goes wrong we're going to end up back at the redirect URL with error equals blah blah blah and then we're just going to show it on the page so we can see what happened. Here is where we're waiting for the return with a authorization code and eventually octa is going to return us back with code is something and we're going to do we're going to have to go exchange that for an access if that's not set then we skip all this for now here around here now so we need to actually now build up a link to send the user to go log in to octa so I mentioned that there's that state parameter it's just going to be a random string that we're going to generate I also need to now make the pixie code store the pixie code verifier the plain text locally in this app and then generate a hash of it and send that in the URL so to do that we're going to say code verifier is let's just copy this and make it a little bit longer okay and then code challenge is the basic c4 URL encoded version of hash of the code verifier and I think I did that right here's the authorization endpoint we're going to add a bunch of query strings parameters into this URL so we need to tell the OS server what we're doing response type is code we need to tell who we are so client ID it's this app that is wanting to log a user in where is the app running redirect your right okay we need to give it a state is there and we need to give it a scope of something for now let's just say that it's contacts so I can get through this part of the demo and then we need to add in the code challenge so code challenge and code challenge method which hash we are using cool okay now we're going to build that into a URL put it in this link that says login so if I go back to the homepage now we see the link that says login if I look at the source code then we see we've got authorization endpoint response type code client ID redirect your right state and if I refresh then the code challenge and the state change every time right cool so here we are I visited us in a logged out window then I'm not logged into octa in my incognito window and if I click login I get taken to octa of course and then octa asks me to log in so I'm going to go ahead and do that when I click sign in this is actually a feature of I've gotten able on my account the consent feature which you really only need to do for third party apps it's not really necessary for first party apps if I click allow I will get redirected back to local host 8080 and now look there's a code in the query string also there's that state value so now we're ready to go and finish this off so back up to here if there is a code in the query string which there is now first I'm going to check to see if the session state matches that state otherwise something is going to go something will be wrong right like like I just take this and put it into the other browser because that means somebody is trying to do something sneaky okay then we go talk to the token endpoint and exchange that code for an access token this is that poster that type is authorization code we include the code we got from the query string which is in there we've got client ID now this is again a server-side app I am going to use my client secret and we've also got redirect URI and let's see what happens is this enough I know refresh is required because it turns out it's actually very short-lived the only last I don't know exactly how long it is but it's like definitely less than a minute I'm already logged in so octa did not prompt me again I got returned back there's a new code new state and now I got an error from octa saying oh pixie code verifier is required because I used a code challenge at the beginning so I can also send code verifier which is in the session probably expired yet start over to get a new one and cool now we got an access token back so at this point we don't actually know who the user is we just know that there is a user because the access token does not tell us anything about the user you might be saying but oh but this is a jason web token and technically yes it is but as far as the app is concerned it's not it does not matter whether it's jason web token because the application does not need to should never actually try to learn anything about this access token just like a hotel key card when you go to a hotel you get that key card you don't go and use a magstripe breeder to read the data on the card you just go to your door and the door deals with it if you did try to read the data on the card you might learn some interesting information or you might not it doesn't matter because all you care about is does it open the door okay so we now we can't really like we don't know who the user is so we have to do something else and we have to learn the user data some other way there is actually an API met API in octa to look up user information which should be one of the endpoints here but instead what we're going to do is we are going to use open any connect to go and actually learn about the user that way so let's talk a little bit about open any connect before we get back to the code so like we saw the access token doesn't actually tell us who logged in the access token just tells us that someone logged in and that we could now make API requests to this imaginary API that we haven't made yet open any connect is about identifying users so again OAuth accessing APIs open any connect who is the user identification and open any connect is not a whole new thing it's actually built on top of OAuth so all the the code we just wrote is actually almost already open any connect because we only to add a tiny bit of code in order to make it an open any connect request so what exactly does open any open any connect add the primary thing is adding is a new kind of token we saw that access token which as an application we're never going to worry about what it is we're just going to send it to an API the ID token is meant to be read by this application this is how we learn about the user so if your OAuth server uses json web tokens as access tokens which octa does then these tokens actually look very similar at a first glance however it's very important to not use them interchangeably because they are not the same and they have slightly different information in them and the security properties of them and the model that's based on assumes that they are not the same kind of thing so these tokens are intended for different audiences which is the sort of spec terms for it the access tokens audience is the API the resource server the ID tokens audience is the application so that's who it's going to be read by so let's dive into json web tokens really quick json web token is a three part token used to encode and sign json data the header that talks about what the structure of the token is and how it's signed the middle part actually contains the data you care about and the bottom part is the signature which is how you can check whether it's valid which is actually only necessary in some cases as we'll find out so this might look like it's unreadable you know nonsense but it turns out that it's actually not encrypted at all so if you take this and copy and paste it and paste it into a base 64 decoder you'll see that it's actually just json data so this is again a really important thing to keep in mind which is that the whatever data is inside this token the ID token for sure and if your access tokens are json web tokens then also your access tokens that whatever you put into those tokens is visible to users and developers of these apps so just keep that in mind as you're designing what you put in these tokens okay to get an ID token we're going to do the same flow we just did we're just going to add a new scope to that request because that's all you have to do to turn on open ID connect you turn on open ID connect by adding the scope open ID there's a couple others defined as well like profile email address phone to get other parts of the user's profile information probably all we care about is the name well we could also get their email address as well so the user clicks this link again this is like the same thing as before we're just going to add in scope they're going to get sent to the OAuth server login they get redirected back with this temporary code which we then exchange for an ID token which will come back along with the access token and this is a really interesting difference as well which is that by doing it this way it actually doesn't matter that this ID token is a JSON web token and we don't care about the signature anymore all we have to do is just treat it like a weirdly encoded bit of JSON data because we don't care about the signature because we actually know where we got it from already we got it over the back channel we know it came from the open ID connect server we know that it's not been tampered with in transit because it's over SSL we know that it was intended we know it's the right ID token because we got it in that responsive request we started now if you got this over the front channel that would be a different story but we're going to do this over the back channel because it's a lot easier and it's just faster so again the ID token is a JSON web token so if you decode it you'll see a bunch of these claims in it if you do get it over the front channel which means that you use a different response type so if you use a response type ID token for example you get an ID token back in the redirect which is like it's flying over the wall and you don't actually know where it came from so if you don't know where it came from you have to verify it and that's what the JSON web token is for that's what the public key signing is for and you're going to use a library to do that because it's too much code to write by hand which is also why I don't like doing it also it's just more work so you have to validate all these claims because just because you got this ID token doesn't mean it's actually for your app if it came over the front channel you have to treat it like it's untrusted data you have to treat it like it's an attack and verify it and only then only then actually so this is why I like the authorization code flow with OpenID Connect because it's so much less code which we're going to see in a second there's another important attack that it prevents if you use Pixie so it's just overall a very good idea to do it that way so we're going to start back to my code we're going to take this app and now turn it into an OpenID Connect app so again all I have to do is add in a scope let's just switch to just OpenID and see what happens that's all I'm going to change and I'm already logged into Octa here so when I click log in I'm going to get redirected back immediately now I got redirected back and look there's a new token and I mentioned that there looks the same starts with the same few letters there's a dot around there it's about the same length because they are both JSON web tokens but we're going to ignore this one and we're going to only use the ID token this is how we're going to find out information about the user so if I take this middle chunk again I don't care that it's a JSON web token right now because we got it over the back channel so if I just take this chunk you can see within it there's a lot of stuff here that we don't care about it's only important in the front channel but this is the main one this is the thing that identifies the user so subject subject is short for subject which is essentially the unique user ID for this user account it is not a username and it's not an email address it's not meant to be human readable it is guaranteed to be unique and stable for this user so even if the user changes their email this stays the same this is the one you want to use to say like this is who logged in so we don't really know we don't know anything else about the user we just know that someone with the subject logged in so at this point we could actually now write code that does that so we're going to go back to our response we're going to use that authorization code to get the access token here which is what we see printed out right this is what we've printed out here access token response we're going to now continue and say if there is an ID token in the response to this then we're going to now do this this is why again I think it's a little bit silly that it's wrapped up this way but we're going to take this string we're going to split it on the dots right we're going to grab the middle part which is this we're going to then base 64 decode that which gets us this we're going to then Jason decode that so we can actually access these values in code and now we're going to use them so let's say actually subject is user info sub which is the sort of most appropriate way to to make sure that we are actually is logged in so this way if we were to like create a record in the database for example we want to make sure that this sub is the key by user that way when they come back even if the email is different they get back to the same user account so okay we're going to store that and then we don't know who they are yet so we're just going to say hello and show their subject then back up at the top we're going to change this to say if there is a subject in the session then they are logged in so start over again we get redirected back it found the subject out of that base 64 encoded jason string and now when we go home we got the dashboard and we are logged in as this user so now this is you know not something you actually want to show to a user we want to know who they are so we can put their name on this page instead so to do that we're going to add a new scope which is profile and while we're at it we'll just also add email log out and log back in and now if we take a look at this middle chunk and basically for decode it some actually useful information we got the user's name and their email it should only be used to actually like contact them you don't want to store this as the user ID in your database because they might change it and somebody else's account later always use the subject as the user identifier but we can now greet them so we can go back up here and say where we extracted this up we're going to also now put the name their name in the session and we can also put the email in the session and now up here in our dashboard we can say logged in as show their name here log out I can get a new ID token store everything in the session I've got to change it there but if I go back to the dashboard it now shows the user's name cool so that is how we actually now have protected this dashboard you know of course in your real application like this is going to be a whole the whole application there but this code now only runs if there is a user who logged in through your octa org and nobody else can actually visit this link now and see this dashboard so we take a look at the questions real quick the the access token this is a the access token we haven't really used here because we were protecting this website this application by using the ID token to figure out who logged in and we now only know we we only get an ID token if it's a valid user in the octa org which we can now manage the the users over an octa and that's where we can you can see I've got a couple other user accounts up here that is where we can decide who gets access to this application right the access token isn't really useful for this app because all the data lives in this app if this app needed to access an API that's what the access token would be for so um we can I can walk through this code which I wrote yesterday um this is probably more than we actually care about but let's yeah let's do that so let's pretend that we're building an API and um the API that we're going to build is going to show us a list of photos that belong to this user now the important thing to remember here is that this API is going to be on a totally separate server from the application I mean that's generally the architecture that you've got you've got APIs on the back end you've got the application which might be a single page app um you might have a application that's a mobile app and that's going to be on in the user's hands accessing a remote API so this is the remote remote API now the application we're going to mimic the application by uh just using a command the command line and we're going to do that by sending a request to the API which uh I should technically be running this on a separate port but that's too much work right now um we're going to send the access token in a header authorization and then we're going to go grab the access token from um we're going to grab a new access token because I didn't save them from before grab this access token and put it there and see what happens so we get this API um we actually make an API request without the token and what we did was if there is no access token this API is going to grab a list of files in that photos folder and show only the ones that are in there which are public photos and you can see that list of file names matches right okay we're going to only show the ones in the secret folder if there's a valid access token so if there's no access token set we just return the public photos if there is an access token set we can actually validate the access token now there's more than one way to do this the easiest and least amount of code way to do it but probably the worst way is to every on every API request go and fetch um request from the authorization from the introspection endpoint back to octa asking if the token is valid so we send the access token over to octa to check if it's valid and if it is we will get back uh response active is true so if I send this with an invalid token then octa says it's not valid and we return back invalid token so we're able to now protect this API using an access token if I send a valid one we should now see something which is I think I probably just copied that wrong um it looks right I bet my client ID and secret are wrong because I delete that application so I have to add a new application for the API which is uh here a new client ID and client secret for that API to be able to check tokens and when I do this try the request again okay so it says something different now which is unauthorized why does it say that? well because I actually want to protect this API and only let applications access the API if the access token includes the scope photos I'm going to go back to my app, add the scope photos into the request go get a new access token now we've got a prompt right wants access to my photos let's go grab the access token and use this in the request and now we've got the secret photo which is the API code now if there forget about this, get rid of that that's distracting we check the list of scopes in the token if there is no photo scope we error out if there is we now also grab the secret photos and return those in the result as well so now we're able to run different code on the API you could also just say like if there is no access token you could just say unauthorized unauthorized here and now it's a private API that has no public you have to have an access token to access it so that's the easy way there's more better ways to do this which are I will save for a separate session there's also a lot of videos on our YouTube that go over this stuff as well let me take a look at the questions real quick and then wrap up so here's a question about how to protect a token based REST API method if we pass the token free to request it will show in the browser console and middleman can misuse the token this is a valid concern if you're running a single page app it's running in a browser and that is where the access token lives and is being used from then there is always a risk that something could extract that token whether that's a different browser extension on your machine or the user doing it intentionally it's not going to do it themselves or anything like that the number of ways to actually extract that there are some and they are worth concerning yourself with it's mainly around cross-site scripting attacks so like every JavaScript that you embed on your page has access to that page so like your analytics, your ad trackers all that could be extracting these tokens and you would ever know that is a valid concern however it is not necessarily so much of a concern that it's not worth doing it this way so if you are if it is a concern and you are not willing to have any of that risk at all then the best way to do it is to not have access tokens in the browser and use HTTP cookies instead where your access token lives up on a server that back in that supports the single page app so that's the sort of more secure architecture in that model the but yeah like I said it's not always a concern because if you audited your code and you know exactly what scripts are there and you've made sure there's no cross-site scripting attacks possible on your app then you can deal with access tokens in the browser because you've reduced the number of ways that they could be extracted I will make sure to send the sample code out so a few people asking about that so what are the expiration dates around access tokens and ID tokens actually the both the ID token and the access token are going to expire so if we have if we look at the access token response here the access token lasts for two hours in this case it's up to the server to decide that but again that's really only the concern of the API so the API is going to go validate the access token and it would be able to check whether the tokens expire it's the ID token that we care about in the application the ID token does have an expiration date as well and again if we look at the basic C4 decoded there's a timestamp of when it expires so yes technically this application should only consider this user to be logged in for this amount of time and you might do that by when you actually set the session cookie for this app setting it to expire at that time or actually storing this ID token client side like in the application and checking it on every request so if you're doing that for example like if I if I only go back to my app what we did here was we extract the data out of the ID token and save that in the session we now don't have the concept of this expiring if instead we actually say ID token and store the whole thing we can actually now check the expiration date we could even just say session expires in at some point right this is now stored server side like on this applications web server so we can now use this checking locally to see if it expires and then if it's now past that timestamp we kick the user out and give them to log in again if you're doing a so there's no traffic back to octa in that case right because this is the ID token intended for the app checking expiration date itself so hopefully that answers that question and I think that's all the time we have we're about at the top of the hour let me quickly just talk about where to go for some more things to read and learn about because this was just scratching the surface of this stuff and there's a lot more to it and a lot more details to learn so OAuth.com is the electronic version of the book that I wrote OAuth 2 Simplified and that is a great place to go for a lot more of these in detail questions there's also the OAuth Playground which is a good walkthrough of the authorization code plus pixie flow like we saw but also all the other flows and you can see how they work and look at the requests that are being made the Octa developer blog is a great resource for tutorials in different languages and frameworks and that's a great place to go to again dive into the details about specific frameworks and languages that you might be using since you probably are not writing your application in one PHP file like I just did we also have a YouTube channel youtube.com I'm actually going to be doing a live stream in an hour there and we do every week a happy hour we talk about answer questions from the audience as well as talk about latest news in the OAuth world so that'll be a fun time as well if you do want to print copy of the book that I wrote they're available here OAuth 2 Simplified.com so thank you everybody for attending I hope you got something out of it even though this was a very quick session but we did manage to throw in some information about API security in there as well so yeah thank you all for joining


With AI at the helm, the future of personal finance looks promising and the benefits are as unique as your fingerprint. Thank you for joining us on this journey through the AI revolution in personal finance. If you found this content valuable and enlightening, consider subscribing to our channel for more. We regularly share insights into the future of finance, technology and much more. Why not share this video with your friends and family? It could be the start of their financial transformation journey. Remember, the future of personal finance is here and it's powered by AI. Stay tuned for more exciting content on the future of finance. Don't forget to hit the like button, follow us and share this video. Together let's embrace the future of personal finance.