Authorization: Security Deep-Dive With Okta (Part 2)
Subtitles
Show
[Music] hey react fans we have some massive news for you react Universe con 2024 is happening on September 5th and 6th in VAV Poland formerly known as react native EU we're expanding our Horizons to include all things react and react native why should you join us meet your Tech Heroes and oper Souls contributors learn from 20 plus speakers from meta Expo Shopify infinite red col stack and many more be the first to discover exclusive Tech reveals get instantly applicable tips on full stack and crossplatform development and network to fuel your career plus experience the community spirit and attend a fantastic networking party on day one and after party on day two tickets are limited so hurry up and book yours at react universe.
com you can also buy a combo ticket to attend both the conference and expert Le workshops let's dive in into today's episode welcome everyone uh welcome to react native Show podcast uh brought to you by kak a total software engineering consultancy I'm your host wva I'm here today with Peter Fernandez and uh this is the second part of our podcast on security about authentication and authorization uh if you haven't seen the first part or on authentication I highly recommend we'll probably referencing that a lot so um but we're here to talk about authorization so like like the second part uh of this topic um let me go back to the model on the OCTA website uh secure access for everyone but not just anyone so this is like the second part not just anyone we we we don't want to let just anyone in uh and I'm joined here by Peter Fernandez principal develop principal developer Advocate at uh alzero that's right that's right yeah I got it right awesome um okay um so let's let's let's Dive Right In uh we we feel that we know what
com you can also buy a combo ticket to attend both the conference and expert Le workshops let's dive in into today's episode welcome everyone uh welcome to react native Show podcast uh brought to you by kak a total software engineering consultancy I'm your host wva I'm here today with Peter Fernandez and uh this is the second part of our podcast on security about authentication and authorization uh if you haven't seen the first part or on authentication I highly recommend we'll probably referencing that a lot so um but we're here to talk about authorization so like like the second part uh of this topic um let me go back to the model on the OCTA website uh secure access for everyone but not just anyone so this is like the second part not just anyone we we we don't want to let just anyone in uh and I'm joined here by Peter Fernandez principal develop principal developer Advocate at uh alzero that's right that's right yeah I got it right awesome um okay um so let's let's let's Dive Right In uh we we feel that we know what
authenication is uh What uh authorization is and I know you mentioned already and I want to dive into the difference uh between the delegated authorization and access control so let's start with those two because it feels like these are very important terms that may be over the heads of many listeners yeah um it's a good great place to start and thank you very much as well for the introduction so uh in the previous podcast we talked all about authentication and that's important because in any authorization model uh and we talked about two things there two distinct ACC um aspects of authorization but in any authentic um authorization model you need authentication because if I can't tell that the user is who they say are I don't know what authorization mechanisms to apply so in terms of authorization you mentioned a couple of things there you mentioned access control and you me mentioned delegated authorization let's take Access Control first that because it do you know for many years that was all authorization essentially was and I say all it was because that's a big enough field by itself but it that was essentially what authorization meant access control is all about essentially if I want to do something am I actually allowed to do it does policy or H kind of configuration or definitions say that if I want to go and withdraw hundred euros from my bank account can I go and draw1 Euros from my bank account or if you're in the UK Le let's wrap a quick bow around the the difference between authentication authorization here because this like a good example that you want to withdraw 100 bus 100 um quid I love that word in the UK 100 pounds yeah exactly 100 pounds from your bank but first if you want to do that first the bank needs to know who you are so that's
authentication you already got authenticated the bank knows that you are who you say you are and now you want to get your 100 pounds so the bank needs to know if you can take that money out of that account and it might be that I don't have £100 in my account so there's an access control mechanism that comes into play that says yeah you don't actually have a100 p in your account or I might have gone over my limit for the day for example and I can't take any more money out because I previously had taken let's say 500 or however much it is out of my account or there might be some block on my account which stops me from actually taking out that money even though I am who I say I am so that's all about authorization that's all about access control that that that part of it now sticking with the banking application because it it works quite it works really well the application itself has made uh a request on my behalf and that request says that person wants to take out1 from their account now assuming that I am authorized to do that I have access control to do that and access control allows me to go take that money out delegated authorization is where I say I'm actually going to allow you the application to make that request on my behalf and delegated authorization came into play when we effectively had a two come on the scene and O2 is all about securing well it's all about accessing apis in a secured way so application programming interfaces essentially public facing apis which are HTTP end points through which I can make requests to do things and typically an application will make a request to do something or get some information on behalf of the person using that application on behalf of me as a user so delegated authorization actually from an API perspective it completes this
circle the application the back end of the application itself what in O Tut o tutor you try saying that it's like difficult um o or yeah I don't know why I strung those two words together o or two terms is ENT known as a resource server where the resource server the thing that's right running on the back end the API uh essentially will allow me to do something right so and based on my access computed via my uh identity and the authentication piece actually allow the application to do something but the delegated piece actually completes the circle it gives me the ability to allow or give consent for an application to do something on my behalf that's really important that's really important in a modern a security environment where I should have control over my information as much as I'm controlled in what I actually do so these are not uh access control and uh delegated um delegated authorization authorization thank you so these are not like mere terms there are uh libraries and sdks and apis and protocols that govern uh orchestrate this uh scenario us using applications correct go ahead know I was going to say so um in in the industry standard protocol O2 a service that actually um participates in this delegated authorization process uh is known as an authorization server and the authorization server's job actually is to Mint tokens that an application can give to an API where that a oh yeah no it's it's like it it's like the Royal Mint right okay it's like you know the the royman this is the thing in the UK the royan basically issues money well these authorization servers will is issue tokens and they're intended for uh the API and they're intended for the
api's use and the application they pass through the application because the application holds on to them and when it's calling an API gives them gives them to um the the the the API and the API validates the the request uh but they're not intended for the application but they are part all those things are part of of an industry standard protocol and that protocol is called O2 and or zero as well as being an authentication server what's known as an IDP an identity provider or an um an open provider in in open ID connect terms um as well as being uh that from an authentication perspective or zero is a authorization server as well so it kind of marries the two things together to give you a holistic solution effectively to confuse you more as to which part does oh yeah definitely definitely no what actually here's the here's the thing that is the most confusing and in the previous episode I mentioned that terms in um in the industry in the IT industry get overused all the time and one of the terms that gets overused all the time in the industry is is the term JWT Json web token and Json web tokens are these kind of like tokens they're Blobs of data um that can be signed so you know that they haven't been tampered with they have they have a signature associated with and in the specification for O2 it says that an authorization server will mint a token right and the token is given to the application the application passes it to the API now that token in the specification doesn't say what format it should be in and here's where sometimes it gets a little bit uh confusing because or zero handles and mints tokens as an authorization server in JWT format as well and in open ID connect which is the protocol for authentication which ER is
part of well the service that uh ozero supports the specification by default says that the token that is minted is in JWT format so now when I talk about JWT format tokens which one am I talking about right uh and so that's where that's where the confusion can sometimes come in um both an access token and an ID token are both in JWT format but an access token is designed to be consumed by an API where an ID token is designed to be consumed by an application and sometimes that's what gets a bit confusing when you come to um play around with orzero but there is a reason there is a reason why we do ask I was gonna ask you is there like a clear advantage to using JWT absolutely um what it means is is that that token is self-contained uh you can put whatever you like in it typically you want to keep it as small as possible but you can put whatever you like in it and the API does not need to go back to the authorization server for what's called introspection it does not need to actually make another Network call to actually figure out what's in that token and whether or not that token is valid it can do it all by itself in a self-contained fashion that improves performance but it also means that those tokens potentially can be used in in situations where you're not always connected to a network and that is opens up a lot of opportunity for a lot of um advant advantageous scenarios offline first applications and and stuff like that uh yeah as long as they go online at some point but um actually offline resource servers sometimes and there are some scenarios um I I work a lot in theater either on stage or backstage or directing or whatever and sometimes you get um Services resource servers that uh operate in theaters they control lighting and stuff like that uh and
sometimes they're air gapped they only are connected to a network whilst uh the show is not running for example and uh in those scenarios those Lighting systems can actually make calls to a offline resource server and have that resource server validate something that he doesn't need to go and do token infraspection on so it's it's kind of um a really advantageous scenario uh or an advantageous solution in that particular scenario interesting I didn't know there was so much Tech involved in lighting the oh there's it used to be in the old days it used it's another head and walk down Memory Lane right we did this in in the PR but in the old days right you used to everything used to be connected bya XLR cable um and today most of the stuff still is uh but IP networks got introduced and wireless lighting and wireless mics and wireless sound and stuff like that a theater is probably one of the most hostile environments when it comes to RF um so radio frequencies there's radio signals going all over the place it tends to cause havoc and Chaos with anything but as technology is matured yeah you have so many acts with the mics and the yeah light radio mics and light lights generate a huge amount of EMF like the old tungsten lamps create a lot of EMF electromotive Force which essentially essentially sends off disruptive radio signals and uh like in the old days you wouldn't put anything high tech in a theater and expected to work uh but these days folks build in the industry it's a massive industry and folks build some really robust equipment that just runs on IP networks and wirelessly and stuff like that and it's uh you you see it more and more in theaters especially with LED lamps that are used today in theaters and stuff like but anyway I digress this is me kind of going on
are you being you being a software engineer do you when you work in theater do you get called like by your friends and and say he's the at guy he's going to fix everything yes and and I also um when I direct shows I also sometimes get very creative and I uh did a production of Nick Payne's constellations uh which is a great show if if you've never seen it go like look it up somewhere and if it's on go watch it brilliant show um it's all about um the it's all about the choices that you never made and what would happen it's kind of Multiverse type stuff but it's really cool and I built my I built a whole lighting rig especially for this um I I kind of had the notion to do it I got to two months before uh this we actually started rehearsal and I went I don't actually know how to do this so I spent a lot of Googling uh and building and stuff like that and yeah that was I put my soldering skills to good use so there we go that's good that's good always learning new skills that that that's good that's good so let's let's jump back into authorization back from theater theater to authorization and let's s about authorization um I was wondering since authentication we know that for for the end user authentication is the first step and then authorization how about from the developer perspective and when you choose your authentication how does that impact what you can use for authorization is it linked at all or not yeah uh that's a really good question actually and the answer I suppose the simple answer I suppose is no it's not um yes you need an authenticated user context but how you get that authenticated user context is well something of a mood point you could build authentication yourself in the last episode we told you not Nots to build authentication and why
you don't want to do that um but once you've got an authenticated user context then essentially authorization comes into its its own right um and let's just talk about access control um in in in that context to start with so Access Control comes in various different models you'll um kind of hear a lot about something called arbac role based Access Control and then you'll hear maybe something about ABAC which is um attribute based access control so role-based access control is all about what you can do based on your role and let's take a classic example I'm uh like a principal developer advocate so I can do certain things as a principal developer Advocate I'm not a manager so I can't do certain things that a manager would be able to do uh and I'm not the CEO so I can't do things that the CEO would be able to do um so that's my role um in whatever it happens to be whether it's a organization or it happens to be a whatever your software does the the role that you're playing as the user uh is basically coming into play from a role-based Access Control perspective attribute based access control is essentially well based upon kind of like attributes associated with the the access so maybe the time of day or the location you're trying to access something from whether you're coming in remotely or you're coming in from an office location uh and that's attribute based access control and you can use both models together right but they're not exclusive certain um models have certain uh capabilities that are valuable and you can augment those with other models a new kid on the Block uh we use that term quite a lot uh in the previous episode but a new kid on the Block uh is called reback relationship based access control and relation ship based Access
Control uh is all about well relationships that some that that folks have to think so my role as a principal developer Advocate might allow me to do X and Y and Zed but if I'm also working maybe as part of another team uh in at OCTA then or working on behalf of another team OCTA then I've got certain attributes associated with that being part of that team and my relationship with that team maybe enables other features and functions that I am allowed to do based upon those that relationship right and relationship based access control is um something that was really kind of developed by Google um if you ever come across something called Google Zanzibar um Zanzibar is effectively the access control engine and the relationship based Access Control engine the effectively sits behind all of the things in essentially Google workspace so docs and Google office and all those sort of things or whatever they call it these days um so when I do sharing and stuff like that it's relationship based access control that's coming into play and there's a access control is I suppos access control from um that that perspective in authorization is probably where authentication was um maybe I suppose maybe a decade ago um maybe less than that uh in that typically folks have been building that as something within their application they've been building it themselves and today there are lots of vendors including ourselves that provide it as a service so all zero out of the box provide you with rback capability and we have something else as well called Fine Grand authorization which provides folks with well relationship based Access Control in the same way that um effectively we provide authentication
with or zero uh and relationship based access control is quite interesting because you can model quite a lot of the other Access Control mechanisms using relationship based Access Control okay so yes from your point of view authentication is something that's developed that that's evolved more so far like the authorization is like a newer uh newer part of of this flow like maybe less less evolved and maybe there the the um the world is changing a little bit with it I think um it's not that it's less evolved it's that now more vendors are looking at providing authorization as a service so we had quite a Zer and other folks were looking at doing authentication as a service now we have a way as well of offloading a lot of that complexity from developers and providing authorization as a service so that's the bit I think that that's evolved um and is is much more kind of Forefront in the landscape isum there are for sure there are new cases for authorization that they come up um as I mentioned before I have two kids so we have tried family link on their phones and that's something like the kid is authenticated on their phone but they're not authorized to do this or that so that's something that has been developed in the last uh I don't know a couple of years maybe maybe a little more but but that's that's like a new way that um we see um getting authorized to do stuff outside of work yeah and and and you and that's a really good example of how um authorization probably has been the province of well kind of work spaces and Workforce for for many years but is now really kind of coming into its own within consumer um environment so we talked about this in the previous episode but you have like b2c applications which are essentially building an application directly to a
consumer business to Consumer is what b2c stands for and this way folks like you and I will use the application directly um and then you have B2B applications which is essentially where you're building an application for another business to use they typically will deploy it in their it infrastructure and their employees and contractors and everything else will use that application and that kind of level of access control what what what often the word that often gets associated with access control is policy uh there's policy defined which tells the system what access somebody has and that level of policy essentially was for many years just the province of well you know when you did things at work but there's a really good example where you set up a policy now for your kids and whilst they can use the phone they you've set up a policy where they can't do certain things yes yes for sure um as as far as workplace environment is concerned me being a software engineer in re native and react I I started off as a front engineer so authorization wasn't ever really my topic since it's much more on the back end API servers stuff that's what I that's that that's what comes to mind when I think of authorization but um i' would like to get your thoughts on how the front end has evolved we have huge applications like I you can run uh Microsoft teams in your web browser or uh jira stuff like that so now front and the belar should start learning more about authorization right so that's a really interesting uh question and a really interesting area as well and it fits really between security and user experience um it's always the tight rope that you walk right it's this line that you walk between user experience and essentially
security from a security perspective the front end is never secure that's a statement that you can almost use ubiquitously and you kind of can argue I mean I can argue against that statement and say well I've got my Mo my mobile phone like that's got a secure keychain on it and like I can store things in that key pass keys for example get stored in that keychain right and it's secure but the idea of something that is frontend is is essentially that it's typically in the wild like I've got my phone here it's with me and essentially I could spend hours weeks months or years trying to hack that um device doesn't matter how complicated the technology is I have that device and I can hack it a backend server system I never get to physically interact with it I only ever get to interact with it um over a web browser a frontend or via an API but I never essentially get to access that Hardware I can't take it apart I can't essentially put debuggers on it I can't put in circuit emulators on it all of that sort of stuff right so authorization from a security perspective always has to be the province of the back end but and here's the but authorization has a place especially Access Control has a place in the front end because well I don't know about you but I don't really like the user experience where like the front end po pops up some dialogue I type a lot of stuff into it I hit okay and suddenly it says Oh no you're not allowed to do that because he's gone and talked to the back end and the back end is in there and you can't what are you trying to do you can't do that um so the authorization the access control models uh have a valuable place in the front end to be able to inform the ux now irrespective of whether I bypass the ux whether I
hack into the code at the front end because I've got access to the device uh and essentially bypass all of those security controls I'm not using security from an access control perspective at the front end I'm doing that at the back end what I'm doing at the front end is using access to contr access control to inform what the user should typically see and that makes the user experience so much nicer I can gray out dialogues that I'm not allowed to um have access to hide them all together gray out buttons disable functionality that I don't have um as part of either the role I play or the access control that's been defined for me yeah yeah that's H that that's such a great answer um I was I was thinking a little bit more about um uh about those um the the UI that that's we have to consider that that's something that's out there in the while and and just has to be considered as something that's accessible to to everyone um but should um like um when when there's a cooperation between the backend developers and the front end developers how much uh of like of a CO cooperation there should be how how much the front end developer should get into the weeds of what uh what can be accessed of what shouldn't be accessed and the I don't know the protocol should we really try and learn all that stuff to make it work or should we just rely on the fact that it's it's out of our hands and we just we focus on the UI and we let the the backend developer do their work and just tell us show this or should we try and and work our way maybe I'm I'm s of answering my own question but there are full stack developers what do you think about full stack developers oh that puts me squarely in that category and you know as a full stack developer I I I don't
know if there's any other full act devel I'm sure there must be right out there that the at least two or three of you out there there must be right okay so there's like but you do this right um I'll be working uh so I've got I've got several computers set up and you see some of the screens um over here right and connected to the cloud I have like remote desktops to Virtual servers that are running and stuff so I'll switch to one server and I'll write maybe an API uh function um on the back end and then I'll um make a call uh to that API from the front end and I'll literally sit there and go hm now it would be good if I could get this information from the API and I'll literally go H I wonder what that would be what that would look like from a front end perspect and I'll talk to myself right as two different personas right like the backend developer and the front end developer and that's one of the Beauties I think if you're a full stack developer is that you essentially get to Converse in your own head with yourself and language can sometimes be a real barrier uh to things but if you can think it and you can just talk to yourself internally and sometimes externalize that internal monl it becomes so much easier right so I think from a if we look at that from a contract perspective I think that means what I think that boils down to is that it is important for backend developers and front-end developers to talk to each other but it's important to know what the responsibilities are as well backend developers should always be responsible for implementing the access control um and determining the granularity at which they Implement that as well so you'll here the term and in fact we use the term for the for the um kind of relationship based Access Control uh
product that we have fine grained authorization that's the term right we actually use it as a product a um but fine grained authorization means that you're doing Access Control at a level which is as close as possible to the resource that means that you have control over the mintii of the information that you want to to access that's solely the province of the backend developer and it really needs the backend developer to know what that resource is what that resource access might be like um and essentially how the how resources maybe interact with one another right from a front-end perspective what I you don't necessarily need to know all of those details and the mintii and the kind of granularity of Access Control what I need really from a backend um perspective is enough information that tells me what I should be displaying to the user from a front-end perspective and what I should be were hiding from the user really to make the user's life easier uh and so when I'm kind of coding and writing something that is essentially full stag I get to do all that dialogue in my head and I get to really do away with some of the obscurity um of language and the translation problems and things like that and I don't just mean translation from like one language to another I literally mean I could be talking English to somebody and the two of us come from a completely different perspective and we still don't understand each other um and that's why it's important I think um I don't think it's necessary for a front end developer to know all of the minui um but they need to know enough to be able to communicate to the backend developer that it's important for from a user perspective to either show something in the UI hide it um and then let the
backend developer uh essentially do the access control make those Access Control checks and either reject something or allow it because guess what it doesn't matter whether you have a front end if you have got a distributed application where you have an API you can make API calls without the front end so you can bypass the front end completely so that's why Access Control needs to be implemented down at the back end uh and that kind of process of reject something or allow it needs to actually be done at the back end but the front-end developer needs to know enough and be able to get enough information to make the ux really a pleasurable experience so so the key takeaway is that even if the front developer doesn't need to have like the full grasp of how the beon is orchestrated they should at least have like a basic understanding sending to be able to understand each other with a backend developer uh and to to talk about it in the real of react native we're sort of stepping on uh on the toes of full stack developers sometimes because applications can store stuff in local storage well local stores there somewh as well but they can uh on the storage on the phone so that's kind of the responsibility of the react native developer and so we're we're kind of like peing behind the curtain a little bit trying to understand and find our way it in the new Waters there um and here's a like here's a really good example of that right is that sometimes uh there's an absolute requirement for a something that's a secure or security related artifact to be stored on the front end um and to be stored securely in Native storage like at the keychain or on an iPhone for example right so case in point is the access token itself I go to an authorization server it meets me an Access token to call my API I
going to store that access token somewhere because I'm not going to consume it as the application but I need to pass it to the API when I make the API call so there's still an awareness from a security perspective that a front-end developer has to have when it we're talking about storing security artifacts um and and those security artifacts uh things like tokens things like access tokens need to be stored in in a safe tokens sorry JWT tokens those jwt's yeah those J with who who JW who yeah those J WTS uh that basically get stored away yeah they need to be stored somewhere secure so from a storage perspective from the security landscape it's important that the front end develop knows how to securely store something um access tokens are great especially jwt's because they can be limited in their lifetime H so they can only be valid for a certain Lifetime and then they effectively expire um so you can you have some control over essentially how much of a threat there is in the landscape on the front end when you're storing security artifact but yes as a as a front-end developer security artifacts that are used to access apis used to access backend Services the security of those is important um we we met before um once before um doing this podcast and you mentioned something that caught my attention the principle of least privilege and I think that's something that's important and uh let's talk about it what is that uh it it's something that I always have to Google because I forget okay so yeah no well actually actually sometimes I have to Google because okay so the principle of the in fact I forget the ACT I forget the term more than what it actually means is there an Acron because like P No but it's a some some people call it
the um PR principle of privilege uh there's the principle of least privilege there's a leas privilege principle um and so like it they're all the same thing essentially but the principle of lease privilege says this just have enough to do what you need to do and nothing more that's really what it boils down to at the end of the day so I'll give you an example if I'm um going to create an access token for example access tokens a part of the O2 specification have something called scope associated with them the scope of operation is literally what I have consented um for an application to do on my behalf now if I ask as the application for more scope than I need then essentially I am as a user giving more privilege to the application than it needs to do the thing it needs to do now if somebody was to steal that access token if that access token was to get leaked in some way that access token get out in the wild now whoever's got ACC that access token while that access token is still valid while it's lifetime um is still such that it hasn't expired that access token could be used to do something that was never intended that the application needed to do but just because the application asked for more privilege now that access token opens up a threat landscape that's much wider so the principle of leas privilege is pretty simple it is just ask for what you need to do in order to do what you need to do that's it that's it okay so how how scared should the end users be like in layman's terms when you log into an app and it shows you dialog box that it wants to access like all your information on Facebook and I know your messages in your phone how scared should we be super scared be judicious be judicious like there's there's lots of
um examples actually um in Facebook of Facebook apps uh effectively in that in that very way stealing privilege uh and gaining access to things that they really shouldn't have access to so it's like anything security related you could spend your entire life uh like losing sleep over everything um and you could uh just go a fine sense about this then I'll be okay and there are Corner cases to that don't get me wrong uh but I for example do most of my banking on my mobile phone uh simply because I think it's probably the most secure environment um it's certainly more secure than me walking into a branch and maybe people overhearing like Account Details and stuff like that but um I think I've got a temper that with the convenience that my mobile phone banking gives me uh with the level of security I'm confident with and if somebody sends me an email saying you know log in here and effectively enter your credentials I will typically go is that come from a a a place that I know is secure and safe or is that somebody trying to fish me is that somebody trying to get access to my information by making me do something that I'm I really shouldn't be doing so I think in answer to that question it's be judicious um just be aware keep keep keep your wits about you is a Old English phrase from back in day or something like that um which just basically means you know just just just keep aware of your surroundings I you said be aware so that made me think of Jean CLA vanam because he was aware yeah yeah you want makes these connections is cool you mentioned um how sometimes tokens Can Be stolen and so there is there are these threats in the world uh and in in the context of that I was wondering what it's like working for the
for OCTA for alzero for the alteration solution provider because uh it seems to me that when somebody finds a bug in uh alzero or in Octa I I was reading actually an article the other day about a bug in one of octa's products but it was like a very uh serious uh it was seriously written they said there was um disclosure to OCTA and the bug was fixed and only after that they wrote the article so it was all nicely done but my question actually is is it stressful because for me like a metaphor I had in my head is that you were at a party everybody's drunk and they gave you their car keys and you have to like keep it all together and they all try to take the keys I don't know so is it is it like sometimes it feels like you're walking around with a big Target painted on your back and like here yeah um well here's the thing and it's really interesting this um it does not matter what you do right it doesn't matter at the end of the day what you do uh folks over the years have tried to build uh door locks that are unpickable and safes that are uncrackable and car systems that can't be hacked into you'll always find someone who's clever and you'll always find someone who's just got the tenacity to break something now if you are a developer and essentially you are trying to protect against that as well as de V something right you've got a lot of your work cut out for you if you're a security company well they might sometimes have a big Target painted on your back if you're are a security company with a pedigree that is a number of years where you've seen a lot of this stuff and stuff gets harder and harder to hack and crack you and make you you know kind of go a bit wobbly around the edges then you've got a security
provider who's literally whose job it is to invest time money and effort to essentially analyze and protect against the threat landscape and that means that well if I'm building an application where I want essentially the best security I can get I want somebody who's actually been through it and actually experienced a lot of this stuff that otherwise I wouldn't even have a clue where it was going to come from so although we sometimes have a big Target painted on our backs ER it it it is actually it's actually nice sometimes to have a big Target paint on back because it means that we're actually doing something right it means that we're doing our job right it means that people are targeting us uh and the more more the more data you have on something the easier it is to analyze and protect against it and the more people that try and hack our systems the more people that come in and try and force our way through our security the better chance we have of Building Systems that not only are secure for us um at OCTA but are secure for everybody else who integrates with us as well so yeah it's a double-edged sort so that was s for sure so do you have is that threat like that that feeling of having the Target on your back is that like a sort like a constant um harm in your head it's always there or or is it like that you have weeks or days where oh my gosh we just had like an uh like a thread actor that really hit us hard and we're GNA work hard over the weekend I don't know something like that or is it just like a steady flow of attacks it it essentially um for me in my position what it does is makes me aware of the advice and the best practice guidance that I give developers right because sometimes no matter how well you build your system it doesn't matter if you have the best door lock lock on your
house if you forget to lock the door right the security is completely useless so it makes me aware of the fact that I should give the best practice guidance and advice wherever I possibly can it also makes me aware that I need personally I need to be up on what the product does and the capabilities and stuff like that so I can communicate that well to um customers um do I lose sleep over it do I am I in a position within the organization where I go actually I've got to go and deal with the Press now on this one that's why our CEO gets paid a lot of money um and you know he he does that but all cudos to to Todd he does a fantastic job at it and he he he gets a lot of um negative breaths and he gets a lot of uh criticism really but he does a brilliant job uh essentially handling what is an inevitable part of being in an in industry um and I feel safer like integrating with the product in the applications I build because of the things that we actually end up going through awesome that's that's that that's really that's a really great message um it's it's really awesome talking with you but I think we should try and wrap this up a little bit uh today we've been talking about authorization um and for me personally the biggest takeaway is even if it's not 100% the frontend uh developers work to know everything we should learn our Basics know our uh acronyms and um aab and aback and airback let's and reback let's let's reback don't forget reback reback reback is yeah that's the new one let's let's learn about that um and let's um let's educate ourselves and see what's out there are many solutions provided by OCTA many others as well but OCTA has great solutions for authorization right we do yeah there you go you heard it from the another another
great English expression from the horses Mass from the horses there exactly so thank you so much Peter for being here it was a great pleasure to do this inaugural hosting with you you've been a great guest and thank you so much for answering all the questions well thank you very much for having me you have been a fantastic host uh even though it's your inaugurating well second actually because we did your inaugurating in our previous broadcast but uh you wouldn't know it you've done a fantastic job thank you very much for making me feel comfortable at home and giving me the opportunity to talk to or your listeners great and uh thank and thank you our listeners thank you very much there's going to be a survey and in the description of this video so uh let us know what she thought about everything that we talked about here today and maybe let us know if for you app security is an afterthought or maybe top priority um we want to know and thank you for tuning in thank you everyone take care bye-bye before we sign off an exciting update the react native show is relaunching as react Universe on air shortly we're not farting ways with react native in instead we are expanding to cover every angle of crossplatform and full stack development from react native to react the content quality remains Stellar with conversations with leading Tech creators and thought leaders prepare to explore the react Universe with us see you next time [Music]
Timestamps
Show
Guests
Peter Fernandez
Software Engineer
@
Auth0
[Music] hey react fans we have some massive news for you react Universe con 2024 is happening on September 5th and 6th in VAV Poland formerly known as react native EU we're expanding our Horizons to include all things react and react native why should you join us meet your Tech Heroes and oper Souls contributors learn from 20 plus speakers from meta Expo Shopify infinite red col stack and many more be the first to discover exclusive Tech reveals get instantly applicable tips on full stack and crossplatform development and network to fuel your career plus experience the community spirit and attend a fantastic networking party on day one and after party on day two tickets are limited so hurry up and book yours at react universe.
com you can also buy a combo ticket to attend both the conference and expert Le workshops let's dive in into today's episode welcome everyone uh welcome to react native Show podcast uh brought to you by kak a total software engineering consultancy I'm your host wva I'm here today with Peter Fernandez and uh this is the second part of our podcast on security about authentication and authorization uh if you haven't seen the first part or on authentication I highly recommend we'll probably referencing that a lot so um but we're here to talk about authorization so like like the second part uh of this topic um let me go back to the model on the OCTA website uh secure access for everyone but not just anyone so this is like the second part not just anyone we we we don't want to let just anyone in uh and I'm joined here by Peter Fernandez principal develop principal developer Advocate at uh alzero that's right that's right yeah I got it right awesome um okay um so let's let's let's Dive Right In uh we we feel that we know what
com you can also buy a combo ticket to attend both the conference and expert Le workshops let's dive in into today's episode welcome everyone uh welcome to react native Show podcast uh brought to you by kak a total software engineering consultancy I'm your host wva I'm here today with Peter Fernandez and uh this is the second part of our podcast on security about authentication and authorization uh if you haven't seen the first part or on authentication I highly recommend we'll probably referencing that a lot so um but we're here to talk about authorization so like like the second part uh of this topic um let me go back to the model on the OCTA website uh secure access for everyone but not just anyone so this is like the second part not just anyone we we we don't want to let just anyone in uh and I'm joined here by Peter Fernandez principal develop principal developer Advocate at uh alzero that's right that's right yeah I got it right awesome um okay um so let's let's let's Dive Right In uh we we feel that we know what
authenication is uh What uh authorization is and I know you mentioned already and I want to dive into the difference uh between the delegated authorization and access control so let's start with those two because it feels like these are very important terms that may be over the heads of many listeners yeah um it's a good great place to start and thank you very much as well for the introduction so uh in the previous podcast we talked all about authentication and that's important because in any authorization model uh and we talked about two things there two distinct ACC um aspects of authorization but in any authentic um authorization model you need authentication because if I can't tell that the user is who they say are I don't know what authorization mechanisms to apply so in terms of authorization you mentioned a couple of things there you mentioned access control and you me mentioned delegated authorization let's take Access Control first that because it do you know for many years that was all authorization essentially was and I say all it was because that's a big enough field by itself but it that was essentially what authorization meant access control is all about essentially if I want to do something am I actually allowed to do it does policy or H kind of configuration or definitions say that if I want to go and withdraw hundred euros from my bank account can I go and draw1 Euros from my bank account or if you're in the UK Le let's wrap a quick bow around the the difference between authentication authorization here because this like a good example that you want to withdraw 100 bus 100 um quid I love that word in the UK 100 pounds yeah exactly 100 pounds from your bank but first if you want to do that first the bank needs to know who you are so that's
authentication you already got authenticated the bank knows that you are who you say you are and now you want to get your 100 pounds so the bank needs to know if you can take that money out of that account and it might be that I don't have £100 in my account so there's an access control mechanism that comes into play that says yeah you don't actually have a100 p in your account or I might have gone over my limit for the day for example and I can't take any more money out because I previously had taken let's say 500 or however much it is out of my account or there might be some block on my account which stops me from actually taking out that money even though I am who I say I am so that's all about authorization that's all about access control that that that part of it now sticking with the banking application because it it works quite it works really well the application itself has made uh a request on my behalf and that request says that person wants to take out1 from their account now assuming that I am authorized to do that I have access control to do that and access control allows me to go take that money out delegated authorization is where I say I'm actually going to allow you the application to make that request on my behalf and delegated authorization came into play when we effectively had a two come on the scene and O2 is all about securing well it's all about accessing apis in a secured way so application programming interfaces essentially public facing apis which are HTTP end points through which I can make requests to do things and typically an application will make a request to do something or get some information on behalf of the person using that application on behalf of me as a user so delegated authorization actually from an API perspective it completes this
circle the application the back end of the application itself what in O Tut o tutor you try saying that it's like difficult um o or yeah I don't know why I strung those two words together o or two terms is ENT known as a resource server where the resource server the thing that's right running on the back end the API uh essentially will allow me to do something right so and based on my access computed via my uh identity and the authentication piece actually allow the application to do something but the delegated piece actually completes the circle it gives me the ability to allow or give consent for an application to do something on my behalf that's really important that's really important in a modern a security environment where I should have control over my information as much as I'm controlled in what I actually do so these are not uh access control and uh delegated um delegated authorization authorization thank you so these are not like mere terms there are uh libraries and sdks and apis and protocols that govern uh orchestrate this uh scenario us using applications correct go ahead know I was going to say so um in in the industry standard protocol O2 a service that actually um participates in this delegated authorization process uh is known as an authorization server and the authorization server's job actually is to Mint tokens that an application can give to an API where that a oh yeah no it's it's like it it's like the Royal Mint right okay it's like you know the the royman this is the thing in the UK the royan basically issues money well these authorization servers will is issue tokens and they're intended for uh the API and they're intended for the
api's use and the application they pass through the application because the application holds on to them and when it's calling an API gives them gives them to um the the the the API and the API validates the the request uh but they're not intended for the application but they are part all those things are part of of an industry standard protocol and that protocol is called O2 and or zero as well as being an authentication server what's known as an IDP an identity provider or an um an open provider in in open ID connect terms um as well as being uh that from an authentication perspective or zero is a authorization server as well so it kind of marries the two things together to give you a holistic solution effectively to confuse you more as to which part does oh yeah definitely definitely no what actually here's the here's the thing that is the most confusing and in the previous episode I mentioned that terms in um in the industry in the IT industry get overused all the time and one of the terms that gets overused all the time in the industry is is the term JWT Json web token and Json web tokens are these kind of like tokens they're Blobs of data um that can be signed so you know that they haven't been tampered with they have they have a signature associated with and in the specification for O2 it says that an authorization server will mint a token right and the token is given to the application the application passes it to the API now that token in the specification doesn't say what format it should be in and here's where sometimes it gets a little bit uh confusing because or zero handles and mints tokens as an authorization server in JWT format as well and in open ID connect which is the protocol for authentication which ER is
part of well the service that uh ozero supports the specification by default says that the token that is minted is in JWT format so now when I talk about JWT format tokens which one am I talking about right uh and so that's where that's where the confusion can sometimes come in um both an access token and an ID token are both in JWT format but an access token is designed to be consumed by an API where an ID token is designed to be consumed by an application and sometimes that's what gets a bit confusing when you come to um play around with orzero but there is a reason there is a reason why we do ask I was gonna ask you is there like a clear advantage to using JWT absolutely um what it means is is that that token is self-contained uh you can put whatever you like in it typically you want to keep it as small as possible but you can put whatever you like in it and the API does not need to go back to the authorization server for what's called introspection it does not need to actually make another Network call to actually figure out what's in that token and whether or not that token is valid it can do it all by itself in a self-contained fashion that improves performance but it also means that those tokens potentially can be used in in situations where you're not always connected to a network and that is opens up a lot of opportunity for a lot of um advant advantageous scenarios offline first applications and and stuff like that uh yeah as long as they go online at some point but um actually offline resource servers sometimes and there are some scenarios um I I work a lot in theater either on stage or backstage or directing or whatever and sometimes you get um Services resource servers that uh operate in theaters they control lighting and stuff like that uh and
sometimes they're air gapped they only are connected to a network whilst uh the show is not running for example and uh in those scenarios those Lighting systems can actually make calls to a offline resource server and have that resource server validate something that he doesn't need to go and do token infraspection on so it's it's kind of um a really advantageous scenario uh or an advantageous solution in that particular scenario interesting I didn't know there was so much Tech involved in lighting the oh there's it used to be in the old days it used it's another head and walk down Memory Lane right we did this in in the PR but in the old days right you used to everything used to be connected bya XLR cable um and today most of the stuff still is uh but IP networks got introduced and wireless lighting and wireless mics and wireless sound and stuff like that a theater is probably one of the most hostile environments when it comes to RF um so radio frequencies there's radio signals going all over the place it tends to cause havoc and Chaos with anything but as technology is matured yeah you have so many acts with the mics and the yeah light radio mics and light lights generate a huge amount of EMF like the old tungsten lamps create a lot of EMF electromotive Force which essentially essentially sends off disruptive radio signals and uh like in the old days you wouldn't put anything high tech in a theater and expected to work uh but these days folks build in the industry it's a massive industry and folks build some really robust equipment that just runs on IP networks and wirelessly and stuff like that and it's uh you you see it more and more in theaters especially with LED lamps that are used today in theaters and stuff like but anyway I digress this is me kind of going on
are you being you being a software engineer do you when you work in theater do you get called like by your friends and and say he's the at guy he's going to fix everything yes and and I also um when I direct shows I also sometimes get very creative and I uh did a production of Nick Payne's constellations uh which is a great show if if you've never seen it go like look it up somewhere and if it's on go watch it brilliant show um it's all about um the it's all about the choices that you never made and what would happen it's kind of Multiverse type stuff but it's really cool and I built my I built a whole lighting rig especially for this um I I kind of had the notion to do it I got to two months before uh this we actually started rehearsal and I went I don't actually know how to do this so I spent a lot of Googling uh and building and stuff like that and yeah that was I put my soldering skills to good use so there we go that's good that's good always learning new skills that that that's good that's good so let's let's jump back into authorization back from theater theater to authorization and let's s about authorization um I was wondering since authentication we know that for for the end user authentication is the first step and then authorization how about from the developer perspective and when you choose your authentication how does that impact what you can use for authorization is it linked at all or not yeah uh that's a really good question actually and the answer I suppose the simple answer I suppose is no it's not um yes you need an authenticated user context but how you get that authenticated user context is well something of a mood point you could build authentication yourself in the last episode we told you not Nots to build authentication and why
you don't want to do that um but once you've got an authenticated user context then essentially authorization comes into its its own right um and let's just talk about access control um in in in that context to start with so Access Control comes in various different models you'll um kind of hear a lot about something called arbac role based Access Control and then you'll hear maybe something about ABAC which is um attribute based access control so role-based access control is all about what you can do based on your role and let's take a classic example I'm uh like a principal developer advocate so I can do certain things as a principal developer Advocate I'm not a manager so I can't do certain things that a manager would be able to do uh and I'm not the CEO so I can't do things that the CEO would be able to do um so that's my role um in whatever it happens to be whether it's a organization or it happens to be a whatever your software does the the role that you're playing as the user uh is basically coming into play from a role-based Access Control perspective attribute based access control is essentially well based upon kind of like attributes associated with the the access so maybe the time of day or the location you're trying to access something from whether you're coming in remotely or you're coming in from an office location uh and that's attribute based access control and you can use both models together right but they're not exclusive certain um models have certain uh capabilities that are valuable and you can augment those with other models a new kid on the Block uh we use that term quite a lot uh in the previous episode but a new kid on the Block uh is called reback relationship based access control and relation ship based Access
Control uh is all about well relationships that some that that folks have to think so my role as a principal developer Advocate might allow me to do X and Y and Zed but if I'm also working maybe as part of another team uh in at OCTA then or working on behalf of another team OCTA then I've got certain attributes associated with that being part of that team and my relationship with that team maybe enables other features and functions that I am allowed to do based upon those that relationship right and relationship based access control is um something that was really kind of developed by Google um if you ever come across something called Google Zanzibar um Zanzibar is effectively the access control engine and the relationship based Access Control engine the effectively sits behind all of the things in essentially Google workspace so docs and Google office and all those sort of things or whatever they call it these days um so when I do sharing and stuff like that it's relationship based access control that's coming into play and there's a access control is I suppos access control from um that that perspective in authorization is probably where authentication was um maybe I suppose maybe a decade ago um maybe less than that uh in that typically folks have been building that as something within their application they've been building it themselves and today there are lots of vendors including ourselves that provide it as a service so all zero out of the box provide you with rback capability and we have something else as well called Fine Grand authorization which provides folks with well relationship based Access Control in the same way that um effectively we provide authentication
with or zero uh and relationship based access control is quite interesting because you can model quite a lot of the other Access Control mechanisms using relationship based Access Control okay so yes from your point of view authentication is something that's developed that that's evolved more so far like the authorization is like a newer uh newer part of of this flow like maybe less less evolved and maybe there the the um the world is changing a little bit with it I think um it's not that it's less evolved it's that now more vendors are looking at providing authorization as a service so we had quite a Zer and other folks were looking at doing authentication as a service now we have a way as well of offloading a lot of that complexity from developers and providing authorization as a service so that's the bit I think that that's evolved um and is is much more kind of Forefront in the landscape isum there are for sure there are new cases for authorization that they come up um as I mentioned before I have two kids so we have tried family link on their phones and that's something like the kid is authenticated on their phone but they're not authorized to do this or that so that's something that has been developed in the last uh I don't know a couple of years maybe maybe a little more but but that's that's like a new way that um we see um getting authorized to do stuff outside of work yeah and and and you and that's a really good example of how um authorization probably has been the province of well kind of work spaces and Workforce for for many years but is now really kind of coming into its own within consumer um environment so we talked about this in the previous episode but you have like b2c applications which are essentially building an application directly to a
consumer business to Consumer is what b2c stands for and this way folks like you and I will use the application directly um and then you have B2B applications which is essentially where you're building an application for another business to use they typically will deploy it in their it infrastructure and their employees and contractors and everything else will use that application and that kind of level of access control what what what often the word that often gets associated with access control is policy uh there's policy defined which tells the system what access somebody has and that level of policy essentially was for many years just the province of well you know when you did things at work but there's a really good example where you set up a policy now for your kids and whilst they can use the phone they you've set up a policy where they can't do certain things yes yes for sure um as as far as workplace environment is concerned me being a software engineer in re native and react I I started off as a front engineer so authorization wasn't ever really my topic since it's much more on the back end API servers stuff that's what I that's that that's what comes to mind when I think of authorization but um i' would like to get your thoughts on how the front end has evolved we have huge applications like I you can run uh Microsoft teams in your web browser or uh jira stuff like that so now front and the belar should start learning more about authorization right so that's a really interesting uh question and a really interesting area as well and it fits really between security and user experience um it's always the tight rope that you walk right it's this line that you walk between user experience and essentially
security from a security perspective the front end is never secure that's a statement that you can almost use ubiquitously and you kind of can argue I mean I can argue against that statement and say well I've got my Mo my mobile phone like that's got a secure keychain on it and like I can store things in that key pass keys for example get stored in that keychain right and it's secure but the idea of something that is frontend is is essentially that it's typically in the wild like I've got my phone here it's with me and essentially I could spend hours weeks months or years trying to hack that um device doesn't matter how complicated the technology is I have that device and I can hack it a backend server system I never get to physically interact with it I only ever get to interact with it um over a web browser a frontend or via an API but I never essentially get to access that Hardware I can't take it apart I can't essentially put debuggers on it I can't put in circuit emulators on it all of that sort of stuff right so authorization from a security perspective always has to be the province of the back end but and here's the but authorization has a place especially Access Control has a place in the front end because well I don't know about you but I don't really like the user experience where like the front end po pops up some dialogue I type a lot of stuff into it I hit okay and suddenly it says Oh no you're not allowed to do that because he's gone and talked to the back end and the back end is in there and you can't what are you trying to do you can't do that um so the authorization the access control models uh have a valuable place in the front end to be able to inform the ux now irrespective of whether I bypass the ux whether I
hack into the code at the front end because I've got access to the device uh and essentially bypass all of those security controls I'm not using security from an access control perspective at the front end I'm doing that at the back end what I'm doing at the front end is using access to contr access control to inform what the user should typically see and that makes the user experience so much nicer I can gray out dialogues that I'm not allowed to um have access to hide them all together gray out buttons disable functionality that I don't have um as part of either the role I play or the access control that's been defined for me yeah yeah that's H that that's such a great answer um I was I was thinking a little bit more about um uh about those um the the UI that that's we have to consider that that's something that's out there in the while and and just has to be considered as something that's accessible to to everyone um but should um like um when when there's a cooperation between the backend developers and the front end developers how much uh of like of a CO cooperation there should be how how much the front end developer should get into the weeds of what uh what can be accessed of what shouldn't be accessed and the I don't know the protocol should we really try and learn all that stuff to make it work or should we just rely on the fact that it's it's out of our hands and we just we focus on the UI and we let the the backend developer do their work and just tell us show this or should we try and and work our way maybe I'm I'm s of answering my own question but there are full stack developers what do you think about full stack developers oh that puts me squarely in that category and you know as a full stack developer I I I don't
know if there's any other full act devel I'm sure there must be right out there that the at least two or three of you out there there must be right okay so there's like but you do this right um I'll be working uh so I've got I've got several computers set up and you see some of the screens um over here right and connected to the cloud I have like remote desktops to Virtual servers that are running and stuff so I'll switch to one server and I'll write maybe an API uh function um on the back end and then I'll um make a call uh to that API from the front end and I'll literally sit there and go hm now it would be good if I could get this information from the API and I'll literally go H I wonder what that would be what that would look like from a front end perspect and I'll talk to myself right as two different personas right like the backend developer and the front end developer and that's one of the Beauties I think if you're a full stack developer is that you essentially get to Converse in your own head with yourself and language can sometimes be a real barrier uh to things but if you can think it and you can just talk to yourself internally and sometimes externalize that internal monl it becomes so much easier right so I think from a if we look at that from a contract perspective I think that means what I think that boils down to is that it is important for backend developers and front-end developers to talk to each other but it's important to know what the responsibilities are as well backend developers should always be responsible for implementing the access control um and determining the granularity at which they Implement that as well so you'll here the term and in fact we use the term for the for the um kind of relationship based Access Control uh
product that we have fine grained authorization that's the term right we actually use it as a product a um but fine grained authorization means that you're doing Access Control at a level which is as close as possible to the resource that means that you have control over the mintii of the information that you want to to access that's solely the province of the backend developer and it really needs the backend developer to know what that resource is what that resource access might be like um and essentially how the how resources maybe interact with one another right from a front-end perspective what I you don't necessarily need to know all of those details and the mintii and the kind of granularity of Access Control what I need really from a backend um perspective is enough information that tells me what I should be displaying to the user from a front-end perspective and what I should be were hiding from the user really to make the user's life easier uh and so when I'm kind of coding and writing something that is essentially full stag I get to do all that dialogue in my head and I get to really do away with some of the obscurity um of language and the translation problems and things like that and I don't just mean translation from like one language to another I literally mean I could be talking English to somebody and the two of us come from a completely different perspective and we still don't understand each other um and that's why it's important I think um I don't think it's necessary for a front end developer to know all of the minui um but they need to know enough to be able to communicate to the backend developer that it's important for from a user perspective to either show something in the UI hide it um and then let the
backend developer uh essentially do the access control make those Access Control checks and either reject something or allow it because guess what it doesn't matter whether you have a front end if you have got a distributed application where you have an API you can make API calls without the front end so you can bypass the front end completely so that's why Access Control needs to be implemented down at the back end uh and that kind of process of reject something or allow it needs to actually be done at the back end but the front-end developer needs to know enough and be able to get enough information to make the ux really a pleasurable experience so so the key takeaway is that even if the front developer doesn't need to have like the full grasp of how the beon is orchestrated they should at least have like a basic understanding sending to be able to understand each other with a backend developer uh and to to talk about it in the real of react native we're sort of stepping on uh on the toes of full stack developers sometimes because applications can store stuff in local storage well local stores there somewh as well but they can uh on the storage on the phone so that's kind of the responsibility of the react native developer and so we're we're kind of like peing behind the curtain a little bit trying to understand and find our way it in the new Waters there um and here's a like here's a really good example of that right is that sometimes uh there's an absolute requirement for a something that's a secure or security related artifact to be stored on the front end um and to be stored securely in Native storage like at the keychain or on an iPhone for example right so case in point is the access token itself I go to an authorization server it meets me an Access token to call my API I
going to store that access token somewhere because I'm not going to consume it as the application but I need to pass it to the API when I make the API call so there's still an awareness from a security perspective that a front-end developer has to have when it we're talking about storing security artifacts um and and those security artifacts uh things like tokens things like access tokens need to be stored in in a safe tokens sorry JWT tokens those jwt's yeah those J with who who JW who yeah those J WTS uh that basically get stored away yeah they need to be stored somewhere secure so from a storage perspective from the security landscape it's important that the front end develop knows how to securely store something um access tokens are great especially jwt's because they can be limited in their lifetime H so they can only be valid for a certain Lifetime and then they effectively expire um so you can you have some control over essentially how much of a threat there is in the landscape on the front end when you're storing security artifact but yes as a as a front-end developer security artifacts that are used to access apis used to access backend Services the security of those is important um we we met before um once before um doing this podcast and you mentioned something that caught my attention the principle of least privilege and I think that's something that's important and uh let's talk about it what is that uh it it's something that I always have to Google because I forget okay so yeah no well actually actually sometimes I have to Google because okay so the principle of the in fact I forget the ACT I forget the term more than what it actually means is there an Acron because like P No but it's a some some people call it
the um PR principle of privilege uh there's the principle of least privilege there's a leas privilege principle um and so like it they're all the same thing essentially but the principle of lease privilege says this just have enough to do what you need to do and nothing more that's really what it boils down to at the end of the day so I'll give you an example if I'm um going to create an access token for example access tokens a part of the O2 specification have something called scope associated with them the scope of operation is literally what I have consented um for an application to do on my behalf now if I ask as the application for more scope than I need then essentially I am as a user giving more privilege to the application than it needs to do the thing it needs to do now if somebody was to steal that access token if that access token was to get leaked in some way that access token get out in the wild now whoever's got ACC that access token while that access token is still valid while it's lifetime um is still such that it hasn't expired that access token could be used to do something that was never intended that the application needed to do but just because the application asked for more privilege now that access token opens up a threat landscape that's much wider so the principle of leas privilege is pretty simple it is just ask for what you need to do in order to do what you need to do that's it that's it okay so how how scared should the end users be like in layman's terms when you log into an app and it shows you dialog box that it wants to access like all your information on Facebook and I know your messages in your phone how scared should we be super scared be judicious be judicious like there's there's lots of
um examples actually um in Facebook of Facebook apps uh effectively in that in that very way stealing privilege uh and gaining access to things that they really shouldn't have access to so it's like anything security related you could spend your entire life uh like losing sleep over everything um and you could uh just go a fine sense about this then I'll be okay and there are Corner cases to that don't get me wrong uh but I for example do most of my banking on my mobile phone uh simply because I think it's probably the most secure environment um it's certainly more secure than me walking into a branch and maybe people overhearing like Account Details and stuff like that but um I think I've got a temper that with the convenience that my mobile phone banking gives me uh with the level of security I'm confident with and if somebody sends me an email saying you know log in here and effectively enter your credentials I will typically go is that come from a a a place that I know is secure and safe or is that somebody trying to fish me is that somebody trying to get access to my information by making me do something that I'm I really shouldn't be doing so I think in answer to that question it's be judicious um just be aware keep keep keep your wits about you is a Old English phrase from back in day or something like that um which just basically means you know just just just keep aware of your surroundings I you said be aware so that made me think of Jean CLA vanam because he was aware yeah yeah you want makes these connections is cool you mentioned um how sometimes tokens Can Be stolen and so there is there are these threats in the world uh and in in the context of that I was wondering what it's like working for the
for OCTA for alzero for the alteration solution provider because uh it seems to me that when somebody finds a bug in uh alzero or in Octa I I was reading actually an article the other day about a bug in one of octa's products but it was like a very uh serious uh it was seriously written they said there was um disclosure to OCTA and the bug was fixed and only after that they wrote the article so it was all nicely done but my question actually is is it stressful because for me like a metaphor I had in my head is that you were at a party everybody's drunk and they gave you their car keys and you have to like keep it all together and they all try to take the keys I don't know so is it is it like sometimes it feels like you're walking around with a big Target painted on your back and like here yeah um well here's the thing and it's really interesting this um it does not matter what you do right it doesn't matter at the end of the day what you do uh folks over the years have tried to build uh door locks that are unpickable and safes that are uncrackable and car systems that can't be hacked into you'll always find someone who's clever and you'll always find someone who's just got the tenacity to break something now if you are a developer and essentially you are trying to protect against that as well as de V something right you've got a lot of your work cut out for you if you're a security company well they might sometimes have a big Target painted on your back if you're are a security company with a pedigree that is a number of years where you've seen a lot of this stuff and stuff gets harder and harder to hack and crack you and make you you know kind of go a bit wobbly around the edges then you've got a security
provider who's literally whose job it is to invest time money and effort to essentially analyze and protect against the threat landscape and that means that well if I'm building an application where I want essentially the best security I can get I want somebody who's actually been through it and actually experienced a lot of this stuff that otherwise I wouldn't even have a clue where it was going to come from so although we sometimes have a big Target painted on our backs ER it it it is actually it's actually nice sometimes to have a big Target paint on back because it means that we're actually doing something right it means that we're doing our job right it means that people are targeting us uh and the more more the more data you have on something the easier it is to analyze and protect against it and the more people that try and hack our systems the more people that come in and try and force our way through our security the better chance we have of Building Systems that not only are secure for us um at OCTA but are secure for everybody else who integrates with us as well so yeah it's a double-edged sort so that was s for sure so do you have is that threat like that that feeling of having the Target on your back is that like a sort like a constant um harm in your head it's always there or or is it like that you have weeks or days where oh my gosh we just had like an uh like a thread actor that really hit us hard and we're GNA work hard over the weekend I don't know something like that or is it just like a steady flow of attacks it it essentially um for me in my position what it does is makes me aware of the advice and the best practice guidance that I give developers right because sometimes no matter how well you build your system it doesn't matter if you have the best door lock lock on your
house if you forget to lock the door right the security is completely useless so it makes me aware of the fact that I should give the best practice guidance and advice wherever I possibly can it also makes me aware that I need personally I need to be up on what the product does and the capabilities and stuff like that so I can communicate that well to um customers um do I lose sleep over it do I am I in a position within the organization where I go actually I've got to go and deal with the Press now on this one that's why our CEO gets paid a lot of money um and you know he he does that but all cudos to to Todd he does a fantastic job at it and he he he gets a lot of um negative breaths and he gets a lot of uh criticism really but he does a brilliant job uh essentially handling what is an inevitable part of being in an in industry um and I feel safer like integrating with the product in the applications I build because of the things that we actually end up going through awesome that's that's that that's really that's a really great message um it's it's really awesome talking with you but I think we should try and wrap this up a little bit uh today we've been talking about authorization um and for me personally the biggest takeaway is even if it's not 100% the frontend uh developers work to know everything we should learn our Basics know our uh acronyms and um aab and aback and airback let's and reback let's let's reback don't forget reback reback reback is yeah that's the new one let's let's learn about that um and let's um let's educate ourselves and see what's out there are many solutions provided by OCTA many others as well but OCTA has great solutions for authorization right we do yeah there you go you heard it from the another another
great English expression from the horses Mass from the horses there exactly so thank you so much Peter for being here it was a great pleasure to do this inaugural hosting with you you've been a great guest and thank you so much for answering all the questions well thank you very much for having me you have been a fantastic host uh even though it's your inaugurating well second actually because we did your inaugurating in our previous broadcast but uh you wouldn't know it you've done a fantastic job thank you very much for making me feel comfortable at home and giving me the opportunity to talk to or your listeners great and uh thank and thank you our listeners thank you very much there's going to be a survey and in the description of this video so uh let us know what she thought about everything that we talked about here today and maybe let us know if for you app security is an afterthought or maybe top priority um we want to know and thank you for tuning in thank you everyone take care bye-bye before we sign off an exciting update the react native show is relaunching as react Universe on air shortly we're not farting ways with react native in instead we are expanding to cover every angle of crossplatform and full stack development from react native to react the content quality remains Stellar with conversations with leading Tech creators and thought leaders prepare to explore the react Universe with us see you next time [Music]
Show Transcript
In the second episode about security with Peter Fernandez from Auth0 by Okta, we focus on authorization. Tune in to discover key concepts like access control, delegated authorization, and the principle of least privilege. Learn how modern frameworks handle security and get practical advice for building apps that users will love, and malicious forces will hate.
Here's what you'll learn about authorization
- Delegated authorization
- Access control
- JSON Web Token
- Authorization from the developer’s perspective
- Balancing user experience and security on frontend
- Principle of least privilege
Need to harden your app’s security?
We assist teams in applying security best practices to protect their apps.
Let’s chat
//
Insights
Learn more about
Security
Here's everything we published recently on this topic.
//
Security
We can help you move
it forward!
At Callstack, we work with companies big and small, pushing React Native everyday.
Monitoring & Observability
Enable production-grade monitoring and observability for React Native apps with real-time insights and alerts.
Release Process Optimization
Ship faster with optimized CI/CD pipelines, automated deployments, and scalable release workflows for React Native apps.
