Add Authentication to Your Mobile App - XamExpertDay 2021

cheers gerald hello and welcome everyone um so in the next couple of minutes we'll be talking about authentication in your mobile app the logins the handling credentials improving some user experience and and also the logouts which i figured out was more important than i initially thought but yes authentication i mean how hard can this actually be i mean isn't it just like entering your username and password hitting a login and and then you're on with your merry way that's that's at least how i a very very long time thought this is authentication and i have learned over the time that it can be a bit different and you also have to take in a bit of a different perspective than maybe just the pure mobile developer view i think i always like to start with the question like why do we even need this because maybe we don't need it then we can just remove it turns out you probably need authentication though so let's just think you've got a business service in the backend that has got some valuable information some valuable services to you and in most cases you don't want that everybody can have access to that so you want to have people identities that you can trust and usually you use that an identity service and once you have that you then connect your business service to that and they say hey people that have been verified by this identity service i'll trust them i'll provide them services and so if we have now a mobile app coming into the game and we'll be doing this later on so what we do is we authenticate uh we get back some signed thingy which we then can present and make an authenticated request and then the server will give us the response now when looking at this it's it's quite important that you have like the right mindset going on because when you think about authentication you're usually not thinking about the clients you're thinking about the back end so the back end is is the safe place okay the servers you you control them let's just assume no one can break into them i mean sure that could also happen but usually it's a more trusted environment than just someone's mobile phone which they might lose i mean go help they might even hand it over to a friend unlocked and they could do whatever okay so back end safe har replace front ends well we have to worry a bit about them they're not really trustworthy at least when we talk about authentication sorry your beloved app actually falls kind of in that category when you put on a tin foil hat now what should we take for choosing this authentication standard and one that is very widely used these days is actually oauth oauth uh allows you to have a central instance for identity service which users then can log into they get credentials back we call them tokens and then we can go to a service that trusts our identity service using oauth and we can then access them so the images that we just saw before we can do that and you can also auth also enables these scenarios where you log in to google and then google actually does the whole authentication part and then you can just use your web service which then actually accepts authentication from google or microsoft or facebook or twitter or github i mean probably before these services where we don't create a new account which is to use an existing one this is also a scenario that oauth actually provides now one off has got one tiny flaw while it does the entire authentication and we get back a token verifying that we have authenticated properly um we have no idea who we are i mean that's uh that was a bit of a problem so great we can now access it but uh who are you and uh should you be able to access this resources you are trying to impersonate someone that's kind of not handled in the whole standard and then people started cobbling stuff around and putting stuff into these tokens and whatnot but there was no real standard and then a a new standard came along and that's open id connect so when you look around or off you will often also see open id connect and i initially thought so new standard so oauth is not good but it actually turns out they work together so this is not a new a new authentication mechanism it's just an addition to all so that we actually know who we are and we'll see we'll have a look at that later on but that's like the big picture so we use oauth to authenticate we use open id connect which is attached to it and that's the usually back-end stuff so i'll be assuming someone already did the entire work for the server and we now create a client that actually has to interact with it i will be using of course a mobile client now when you are looking at authenticating someone or presents you with something called flows and the multiple flows and that can be a bit confusing at first now there are four major flows in off and we'll be picking the authorization code ground flow i'll get back to the other flows a bit later on and what this actually does is this is like the secure way of the recommended way how you authenticate a user using a mobile application this flow was so to speak specifically designed for mobile scenarios though you can also use it in different kinds like desktop applications and stuff like that how does this flow look like well it's actually quite easy um everything is a bit confusing when it comes to authentication so what we do is uh we create a authentication request in a browser uh on the ident on the server so we don't do this in a client so we don't have a a view that we programmed with saml and xamarin forms which we then use to authenticate a user we make up we open up a browser which is hosted actually on the identity service sys server and that service then returns uh an authorization code come for deep link we'll go into that again and then with that code we can then request the tokens and then we get the tokens and then we can finally make our requests to the back end i can not only make one request as it's shown on this diagram uh i can make multiple requests just as long as the token is valid so starting out in our code actually there are two nuget packages which i would recommend or which i'm using here and it's the identity model and the identity model oidc client open identity connect client and there's a a third package involved but we get it kind of per default so we sometimes forget about it xamarin essentials so with these three packages uh up to date and ready to go uh on the latest xamarin form standard all shown there we can now start to implement our oauth and oauth has got some configuration options which we have to do the oidc client provides us with a lot of helpers around these things and what we see here is how we can configure say clients to then make all these requests and responses that we just saw before so what we have here is we have the authority uh which is the url to the backend so where the identity services running right now we have a client id now in a identity service you can have multiple clients we could have a mobile client we could have a web client an iot client something somewhat client maybe we even have multiple mobile clients so this is just a name that we define on the server and then we have scopes i'll get to those in a bit we have a redirect url so because we're calling out to the server we have to also tell the server how to get back to us once we've authenticated properly which is there there's also the option of a client secret now client secrets can be used in a different flow i'll get back to that at the end of the presentation um it's it's basically it could be a good it could be a certificate which we then attached to a request now uh maybe you have already seen the talk by kerry lothrop who explains in quite detail why anything that you put into a mobile app is not really safe so it's optional you can put it in there it might add a little layer x additional layer of security but it's not really uh required for our flow that we're using so you can you can put something in there you could write hi xamarin expert day which is put in some good or just leave it not and then uh becomes the browser uh we'll get to that in a bit that's where we then make our actual web request out to the to the server with that we can create our own icd client and make requests with that now an important thing even though it looks so sweet small and harmless is the configurations that you just saw on the screen before have to match with the configurations on the server otherwise this can get really frustrating really quickly i said before we'd be making a browser request and that's a bit of code that we still have to implement so that's not out of the box ready to go so let's look at how we can implement set browser this is actually the entire code you will need to do this and what we do is we implement a class i call it web authenticator browser you can call it whatever you want and we inherit from my browser which is an interface provided by the odc client uh nuget package we have to implement one method it's the invoke async method and in there we get passed in the browser options and also cancellation token which i'm not using properly in the code below because i wanted to keep the code readable so what we do is when we do the web authentication uh we have to give with a star trail and a callback url they're both provided in the browser options they are passed in from the configurations that we did before so we can now uh when we call this uh method we'll pass in hey there's my identity service and it will handle the web requests we're just doing basic http requests over a secure channel uh so but it's all taken there's some ceremony behind it to make it a bit more safe and uh to to make sure that man-in-the-middle attacks cannot be taken or not be made so this is the basic setup so now when we invoke this when we now say web authenticator authenticate async what we now actually do is uh what we look at the big picture is we make now this web request so we go we open up a browser on our mobile device and then we enter in the credentials and then we get back this code and this code will be a deep link back into our app now what we have to do is we have to now inform the operating system hey uh when you get a request back from a device or a deep link back call from that uh please open me up we have to do that and so how do we handle this callback we have to do it for android and iris and thankfully we began to get some help from the serene essentials package so let's look at ios first so in here we open up the info plist file and it sometimes is easier to look at this in the xml when you type it in the first time it's also easy to copy and paste the stuff up uh i'll provide some samples for this and in here we can define the url types and the schemes that we're using to making this authentication uh you can see down here this is the callback string that i'm adding and this exact callback string is also defined again on the server so these things that always have to match they're case sensitive i know usually urls aren't in authentication spaces they are and with this um we have uh registered ourselves by ios now the last thing that we still have to do is in the app delegate we just have to write in two methods the open url and the continue user activity all these things are actually really nicely documented on the microsoft docs page it's just knowing how to put all the bits together which can be which can add up over time the next thing that we have to do is android now in android we have the android manifest xml file and in here we have to add this uh intent to this action and with that we will then be able to get the callback after this you still have to implement a additional uh uh activity sorry uh yeah we have to add an additional activity most of this stuff is actually also in the dots one thing i would like to point out is this data scheme now in here you put in the callback url the one that we previously defined in the info plist for ios and if you're working on different environments this can be a bit tricky because you actually have to provide the entire url to put in there and when the callback when you have different callbacks for different environments because you've got multiple apps installed for all your death staging and prod environments um you usually don't want that the authentication app from production starts opening up your dev and fun stuff like that so what i usually end up doing is i put it as a static cons variable in my app sample.cs and then with the if def precompile flags you can then switch between uh what callback you want but since this isn't an attribute you can't just have like some json configuration flow lying around and loading it up at runtime that will not work here so yeah that might still be a bit of a brain scratch of that so what we now have done with all this configuration is we have now implemented the code to start up the web browser then the user will enter his credentials on the website of the identity service and then we handle the callback into the code so before we were in the eye browser implementation we skipped out of there to have a look at that so let's get back into there so we have now made our request we now assume that the auth result was positive and what we now have to do is to make the next call we have to sort of format this call going out and that's called going out we do here so what we get is like a code and with that we have to make an additional request to get the token mainly a security thing that we don't pass in the token because the token would then stand in the url that would be passing into the device and that is not really secure because you can't really encrypt url otherwise no one knows what you're trying to call so this is what i'm doing here i'm making a url i'm just stitching together these key value pairs and then i will create a browser result again this is something from the odc client and i'll pass that back and this is a piece of code that will be executed in between uh ogc standard code so what we are doing here is we are creating a new web browser because the library does not provide a default implementation for xamarin forms at the time and this is how it will then look when we create it so first we create our oigc client that's where we have all our options then we invoke the odyssey login async with a new login request and in that request our browser will then be invoked so the browser will open and then automatically the token request will be made and we'll get some tokens so let's have a look how this actually looks when we are doing this in code so i have here uh my run of the mail xamarin forms application and what i now want to do is i i want to make a login so i have here my main view model and i put here a break point and i'll just start this up so this is a button that is called login and with that button i will then start this authentication flow which i've just shown you before so i now push this button you can see now i'm now in this code and i can now look at the odc service which will be called back here and here i would then call the authenticate method so i'll just step further we have now created our clients in here with all the attributes that you have seen before in the code so we have here our authority url and we have some additional we have the redirect url which will then be called once everything is completed and we see down here the scope so all this stuff is already pre-arranged and now i can do this once more now this takes probably a bit of time because i was in the previous session and i didn't start this demo so the azure web service had to start up uh i don't have to always click away this uh nice dialogue i haven't found yet a way to get rid of that and what we're now doing is we are now in the eye browser interface so this is now the web browser that's been started up and you can see i have here my options that have been passed in as before i have the end url the callback start url there's some stuff going on here this is the added security that we would have to do our own but there's no good package doing that for us so what i now can do is um i can now step further and i should now already be logged in because i forgot to log out oh that's fun um so let's just guess i have to enter my credentials i'll get back to this phenomenon in a second where this actually happened but you can see i'm now logged in i had to open up a web browser session the credentials weren't posted back in i then got a token and now i've got some valid credentials as you you can see here so recrap a recap the authority set up it can be a bit confusing uh the first time you do go through it but there are actually a lot of steps for taking care of so if you use summer essentials and your idc clients they are some small steps with stuff to do some some configuration steps i mean yeah there are some code involved with the eye browser but the rest is mainly configuring uh the the web requests like knowing which url you're using and still some uh configurations can concerns uh of oauth now the nice thing about when you do it in this way the app actually never knows the user creatures the app never sees the username and password and this is nicer for security perspective because this means uh no app ever gets to know them i mean we could say hey i'm a fair player i will never store the username and password but with this flow it's not up to the client if he wants to forget about the credentials it's like bait into the baked into the flow and from a security perspective that's a good thing and just to mention it once more the right configuration is essential this is a picture of me doing the first time streaming at my computer why this is not correct and i put all in the right uh configurations and and i said before case sensitivity can play a role so this might have led up to this picture but yeah it if you get one little thing wrong in that configuration you'll just get no nah not interested in that today and then we'll move on so we have now gotten tokens um so what now well now the fun time actually begins usually what you will do is a lot of web requests with using the http client so you can add the default request says authorization you can add the authentication header value to it and then just use bearer and then have the access token uh put in there if you set it to null this will not be sent when making an http request so if you are not logged in you could just have that to know and the attribute will not show up in a request so that's something really nice another thing that you often want to do is store the token because you might need it later on or the user closes the app and you wanted to make another request and you can do that now i would recommend you use storage with some xamarin essentials because that will really easily allow you to store these tokens securely so that they also will be stored in an encrypted fashion so if the phone gets stolen and unlocked and stuff like that you will make it a lot harder to retrieve those uh credential bits that you then have now another thing that we can actually do is uh open id connect so i said before uh the authentication document does not really provide any information about the user and you can actually pack in quite a bit of stuff now um let's let me show you what i mean by that now i have here my my application and when we get the when the web request returns we get actually more than um one token back so what we get is we get a an id token we get an access token and in a bit we'll look at a third token that we will get and the id token that we have here i'll cop it into my buffer is actually the result we can say from the request that we just made now you can either go to jwt.ms and paste it into here and now what you can see is this is actually part of the token so we have um we have a header part up here this is actually the interesting part that we have here so in here i have quite a little bit of information i see uh what my client is i can see who provided this i also got when it expires uh stuff like that uh but if you you can add additional information to here so if you're using a service like microsoft graph you can put additional user information into here so that means whenever you make a web request the server can also read it and since everything is signed by the identity instance if something is getting altered the server will know that this is not anymore a valid token so i can put my user id in here make web requests and then on the server use that user id and no this is not being tempered with this is not someone trying to give himself out as gerald and then uploading uh dance videos of gerald on youtube that we might want to do that at some point maybe not today some other thing uh another really cool source that i sometimes use is jbt.io and the reason why is it's a lot easier you've got like here's some nice helpers so if i zoom into here i hope you can still see it you can actually see when this token expires so this token expires at 10 40 uh gmt plus two so essentially will be in summertime uh helps even out with those pesky time zones so you can see this this total is actually not valid for a very long time is it um it's only manic for about one or two hours and that's the default that we get um when when using these tokens uh another thing i'll just do this once i can actually even copy the access token because it looks quite familiar and i could also paste it into here and you will see there's a lot of it looks quite similar doesn't it um but you shouldn't do this so the it's a it's not that you can't do it you could actually pass this in code because this was the jwt but there's no guarantee that the access token in or will actually be a jwt token so even though it looks very similar uh usually you would not use the access token to retrieve information because it's not really guaranteed by the server that this might not change at some levels of time okay so that is what you can do with the tokens and i think maybe what you will be doing is getting some information out of it and using it to uh get access to some http api so the id taking contains information about the old token and the id token contains also information about the user i haven't put a lot of information about the user in this token it's mainly the default token that you get by the identity server which i'm using in the back end but i could do it i could add additional information which can be really useful when using it later on and again just use the id token not the auth token to retrieve information because it's a bit frowned upon to do that or better set the standard does not guarantee that your app might not break at some point because the server doesn't really have to follow along the rules to keep the jwt so i we saw it before the token is done for one hour and then you go like well it gets renewed right i mean i have to log in every couple of hours i hope and um well it turns out well yes you would have to you would have to actually authenticate every time that token expires and then it's quite a short timeframe now we could of course bump up the token access but that you might have guessed it is a bit of a security concern so there is a different way how we can do that using our that's refreshing your tokens now when we look at the uh odyssey client options which we use at the beginning um the scope so in the scope we say i would like to have access to certain properties uh you could add additional properties in here you can use scopes for uh scoping in your api usage that you want also for uh requesting access as i said before like from a graphql uh graph api um type of service that would then give you these things these scopes they have to match with the back end but what i could do is i can add the offline access an offline access means i can request a new token without the user having to request a new token every time and just to mention it once more because i can't tell you how many hours of my life velocity this thing um it's really important that the server is also configured to enable this offline access uh thing so what we now can do is uh i'll hop over quick to the code and i have in here in my identity service i have down here i have my refresh token going on and i'll just set a breakpoint right here and i have here this button which will eventually invoke this method and when we come in here we create a new idc client same method as before and then i will just quickly step further to the next one and we can now see i have now gotten a response from the refresh token so what i've got i've got a fresh access token i've got an again an identity token i can see here i got a new refresh token now refresh tokens they expire about every month it's again a setting on the server and we can't read this you can see this does not look like some jwt token up there so you would just have to know how long it is valid uh but with this you can request a new absence access token and if i now just remove these break points here and continue letting them run if we look up here at the time if i do this once more we can see the time is always uh jumping forward so i'm always getting a a new um token based on the time zone or based on how long that it will be valid and this is um a really nice way because usually going to have a button in your ui and then say hey please refresh please refresh but you can do that in the background so every time your app starts you could uh get information from the id token hey when will my access token expire and then you could refresh it or you could make a request with the access token and then you will get a response that's this is an explain token and then you can make the refresh so there are two ways how you can do it you can be a bit quicker uh with just enforcing the refresh on your own a bit smart if you want or you can just let the server handle that for you now this is how you can uh refresh these things and that's how you can actually let your user be locked in so from a ux perspective this is really nice because before i i would have had to enter the login each and every time the app has been a couple of hours running and i don't think you know of many apps that have got a great rating in the app store that provide this model of security so refresh tokens allow you to automatically lock in the user again once he has provided initially his credentials uh usually one says this refresh token is something you don't want to let be stolen because even though it expires usually at the first time you make the request it's uh it's valid for for quite a long time so it can be one month it can be three months it's usually a bit of a business decision how often the app gets used and when you want to cut it and this can be very um yeah what should i say i was using this approach once with the customer where the users of the app it was an enterprise app they didn't always have the best internet connection when they were doing this and this just ended up in them having to authenticate a lot of times and there is a setting they can say hey a refresh token can be used for multiple refreshes but that again is from a security perspective it can be yeah difficult because suddenly people could use your refresh token over and over if they ever get a hold of it and they always get a fresh refresh token when the request was uh what's good what you can do with the refresh token is you can actually block it on the identity service so you can say hey my phone got stolen something like that or forget my device you might have seen that when you use uh like your your apple microsoft accounts you can say forget this device it just means the refresh token that is associated to that device will then be forgotten on the identity service and then it will no longer be valid to get new tokens now one topic i never thought would be that important when doing anything was actually logging out now i always thought the only concern that people have is staying logged in but it turns out there are some use case scenarios when people share a device so you want them actually to log out and then log in again and i thought hey mark this smart this is actually quite easy you just forget about your tokens set them to null and uh yeah reset the default request setter authorization and all is good right so i did that so i was logged in i pressed lockdown and then this happens and you saw this just happening before when i initially tried to log in and that was a bit strange so i then had to dig a bit deep and then i thought well why was this happening and it turns out since we are now using actually a web browser in the back end it's not only the app that knows that we are logged in so what we have to do is we have to somehow tell that web browser or the backend service that we actually want to log out so please let the web session expire on our client and to do this uh we can add a post logout redirect url so again we will be calling the backend server for this we'll be opening up a another browser session for this um it's just one more option you don't have to make a new client for this this is again an addition that we can make and in on on apple what we have to do is we will also have to enter the serial scheme uh in here so that it can then again call back on android we don't have to do this because we only give him the first part of the uri it's not interested in what comes after the slash that which is passed through but we are interested in uh on is we have to actually register this specifically so it turns out it's a bit more complex so we have to do a bit more logic so again this might be something for the identity service so again we go in there we delete the tokens and we reset the authentication header um and then we make a new oidc client and we then create a logout request and this will then terminate the session now it is quite one thing that i want to point out to is you want to add the id token hint so this is the identity token the id token you will pass that with to the logout request this is made that you will not spoof another app because uh when you do this you will just log out the web session and this could be used for spoofing so that somebody might no longer be able to to access the web application and when we do this um you can now see i don't have to add the i have to now log in again so this is how we then have to uh yeah this now works actually properly but there are some additional steps that i first didn't think about so this is log out and what we've seen is that because we're using the code flow it creates a web session and that web session is not in our app it's actually on the operating system so that's why we have to again open up quickly the browser you saw it there maybe before quickly running through it popped up and just went straight away again away so that the web session is closed then don't forget to delete the tokens in the app a authentication token is actually valid for one or two hours and it will always be valid for those two hours so if i go to the identity service and i delete the user and i still have a valid token i can still make requests to the data apis because they trust that the token that was granted by that service is actually still valid so if i have a token which is valid for five years and then i quit my job i still have my token to access multiple backend services for five years because it's a balance piece it's yeah it's like the kobit certificate if you want to say so it's it's valid as long as it's valid and it can't be rewrote because it's it's kind of there's no check going on between the back and logic and the authentication service now that's why you also want to delete it out of your header if you get one of those you will be locked out but your app will still be able to make those requests and then you will probably get some funky experiences going on and testing sessions or if you didn't test for them in real life so we went from username and password entry to to this right it's pretty much more or less and some of you might know go like is is it really worth doing all this i mean we had to we had to set up an rdc client we had to set up callback algorithms and then we had to handle tokens and we had the refresh token thing going on and oh my god i mean not even log out works super simple you actually have to do some additional steps there and yes it is quite a few steps that uh we have to undertake to to implement oauth in a mobile app i i will not get you there and it's also a bit complex to do it and the thought might come up well why do we do this and i think the main reason is it's just identity services are not just there from for mobile i mean you could do a base http basic authentication where you send your username password with every request to the server but that means that every client that contacts that api can do that so a potential hacker could actually try brute forcing his way into your backend api and having to use a token just is a lot more complex and makes this approach no longer feasible so that's why this token based approach came along and then also seeing the client as an attack vector has become more and more reality i mean we've all be i've just received a an email this week from my supposed ceo that he's got an urgent task that he would like to discuss with me uh two problems one it was full of typos and two he usually doesn't talk in english with me so but but that could happen and i mean it's harder to uh create a a fake mobile app i give you that but it still could be possible and that's the scenario why these authentication mechanisms are so yeah maybe a bit blown up but we have many attack vectors these days and this is what we're trying to to like prevent when using this plus once it's running you can go again back to the fundus creating nice uis and providing some cool user value now before we leave olaf actually provides more than just mobile stuff i said it before and they're also more than one flow that we can go through now i just want to give you a quick overview once you've gone through the trouble of making an identity service uh what you could actually do with it so the client credential grant um is the client secret that i took before with the options and what you can now do this is a scenario let's say for iot devices so you trust the device because your manufacturer it's not like someone goes into a shop buys it downloads your app from the store and they somehow can also get to the contents of the app because it's you put it like on the chip right you burn it right in manufacture it you can put a certificate in there which you then use to communicate with the back end so that could be one way how you could um how to provide that service and we could also use this in a mobile app so we could do this there's nothing preventing us from doing this it's just the secret is quite easy to get to once since you're in your mobile app but maybe you have a scenario you say but ma i just have a tablet somewhere installed in a wall no one can access it and it's just there for i don't know an information kiosk you could also do this you could you could set up a client which has got read-only access it's got a certificate and it makes the request and you could totally do these kind of scenarios uh the next one which is not only quite a mouthful the code resource on a password credential grant flow um what you would expect no it doesn't what you do here is you enter a username and password and you actually get back a token from the service which some of you might think i thought we would do that from the start thing is this thing is there for legacy applications so the reason why you don't want to do this i said it before is you don't actually want the client app to ever see the username password so that's why we use a saved application the browser which is provided from the operating system which is yeah sign and whatnot uh so there's little temperature so we can be kind of sure that there's no tampering going on there i mean nothing is 100 secure but yeah it makes it a lot more difficult uh with this we can actually circumvent that we could actually make a user dialogue we could have stephen create the nicest one or maybe even kim like some nice animations going on and all that and i think it would look i think it would be looking really awesome and we could do that but again it's not really so secure and then we have the authorization code grant which is the one that i just showed you before the implicit code grant is when you use a a spa a single page web application you would use the implicit code grant so those are there's also that now i just want to stress this point the code resource owner password credential grant might look really nice to the developer it might not just be the developer it must also be the business manager but security best practices say like maybe not the best idea plus um in a upcoming version which will be of 2.1 they're actually looking at even removing that flow from the standard now that's many years out so i'm not saying if you do it today you would have to warn your customers that hey next year this will not work anymore um plus if you own the server you could also control that but it's just this flow is so insecure it's being considered to be removed from the standard just just to let you know now another thing that you might want to know is like who who actually even uses this or thingy and uh well this is like these three now that's actually a lot lot more um companies that are using it you might have seen like when you log into microsoft office or outlook in visual studio it always screws you with the same login dialogue and that is mainly because they always use the same identity service in the background to authenticating as the same is true for google and facebook also uses it and a lot more companies also use it i think i could have just filled this slide with company icons um which are actually using all so it's quite it's really widespread and it has proven that it's secure in some fashion unless you get a crowbar and force users to tell the password but that's nothing now since we are here in a you know soon to be maui world and what about maui how will the changes be and i hope i could show you that um there are very few touching points that probably will change when it comes to maori i mean xamarin essentials has been migrated over to maori uh the odc client is already.net standard 2.0 so these things they will work on and i have some blog posts all about these things and i'm looking forward to just copy and pasting them replacing xamarin forms with maui and then more or less of a working new block but might have to do some more work but yeah you get the point i think it will be quite easy to do so some takeaways i'm running out of time here and i know that the next session will be really cool i'm looking forward to that one too so off to and open id connect are an industry by standard so i think they are really cool to be trusted if you don't know the password you can't lose it so i think that's a a good thing and yeah with sound essentials odyssey client you get packages you basically are set to go and and that's about it for me sorry i i'll check later the chat if there have been any questions uh my name is mark alive though ws said i don't really have to say that uh you can find me on twitter i have a blog post i have a blog on malibun.com i also do a podcast with my good friend stephen gerald and i will be later uploading all the code samples and the slides stuff also under this if you now click on that url or you type it in uh it will be empty but yeah it will be there soon and yeah that's it thank you very much for attending my talk awesome mark thank you so much for giving your talk um i think there were definitely some questions in some maybe let's just take one there were some questions in the chat i think there was a couple of people who were interested in does this also all work for uwp um yes uh it does i haven't done it because i'm mainly working on mac but if you look at the samples that are on the xamarin essentials which is also so a lot of the touch points are actually done with summary summary essentials when you have to go back into the app and summon essentials provides those so yeah you should be you should be good to like you said it's it's kind of like technology even technology agnostic right so you can use it in all the things as long as you follow the flow and you as long as you can implement http calls basically you're good to go yeah you can also do it all on your own so this yeah all right perfect perfect um again thanks so much mark we're already going a little bit over time because well you were spot on but um i'm thanking you for your time you can find all the things on the repository it was just mentioned

Channel: Gerald Versluis

Views: 751

Keywords: OpenID Connect, OAuth, Authentication, Xamarin, Xamarin.Forms, Xamarin Forms, xamarin forms oauth, oauth xamarin tutorial, openid connect explained, xamarin authentication, xamarin google authentication, xamarin forms authentication, xamexpertday, openid connect tutorial, openid connect sso, openid connect flow, openid connect vs oauth2, authentication and authorization, authentication app, oauth2 explained, oauth 2.0 tutorial c#, oauth 2.0 tutorial, oauth 2.0 explained

Id: Pf7hnH0JbFc

Length: 43min 38sec (2618 seconds)

Published: Sat Oct 02 2021