Welcome to the Mobile Security session. In this session the topics we'd like to
cover are some information about authentication and how we log in and what
the login and request sequences look like, so that we can always validate and
make sure that the right users are logged in at the right time so we want
to make sure you are who you say you are in authentication and that you get then
authorized to view what you are supposed to be able to do, and that is based on roles
so we have role-based authorization and that includes both from the server-side
and the client-side, so on the client-side there is role-based authorization and we
want to make sure that people can be authorized to get to some of the global
endpoints that are providing the data as well. So this would make more sense as we
go into a little more detail, so let's start with the authentication side. When
we go to login from a device-specific perspective we either can do persistent
logins or session logins. A persistent login will be the typical way to
authenticate and basically that means that the user is logged in, until they
decide to log out.
by default the persistent login time is going to be 365 days, so they'll be
logged in for a year, and then they'll get logged out but if they don't log out
and they keep the app open then they would be logged in for that whole time
now there isn't any conversation if the app is closed.
There are no communications to the server so it's not as if this is going
to be a problem, but it's there.
There's also something that we can set up called session login, which is what we
would be more used to from a web application perspective and this would
be used when we have more secure use cases so for doing banking or we have some
sort of sensitive information then we want to log in and we'll be logging in
for a session and the authentication is lost whenever the application is closed,
so here the logins will be much shorter and any kind of change to the
application as far as it being closed potentially going offline
you may get logged out because of those types of interactions, so if we look at
the login sequence in some detail. From the client perspective if we go to log
in, the login information will be sent to the server, the server checks the database
and creates the login information and basically says okay we know who you are
and we're going to go ahead and cache that information on our side create some
cookies and respond back with those cookies, so that from this point on we
know who you are as far as a client to the server so we know their information
we create the cookies that we need and that helps make sure that we know
they're authenticated and makes this the following interactions a little bit
quicker. Now there is an HTTPOnly cookie and it has the login information time
until it needs to be updated as well as the expiration date and a hash method
authentication code that sort of keeps track of our session and what's
going on from that perspective so this is a cookie that the server cares
about and we'll be sending it to the server each time we need it
there's also a client accessible cookie and this will have information for both
the client-side and server-side so it has the cross-site request forgery token
inside of it and it will keep track of the UserId and the Username of the
person whose device or client is actually the one that is available, so
once we've gone through the login procedure then we're going to make a
request, and when we make a request the server is going to check our signature
and the signature is actually the information between some of the
information out of both of those cookies that we just discussed
and it will check the signature. If anything was in the cache and isn't there
it may need to go retrieve the information again the security cache may
have lost some of the information due to either timeouts or size but once we get
the information checked and we have all the information that's correct then we
can go back and say yes we can give you the response so we will continually be
checking to make sure you are who you say you are when we go back and respond
with the types of information that we're looking for. Now when we say that we're
going to be checking the signature what's really happening is we check
the HMAC field that was generated by the server and that will make sure that we
know who you are and that key and what gets generated is on a per environment
basis so that would be different if you had to connect to different servers. It's
also going to check all of that signature data that we mentioned and that
uses information out of both cookies so it's going to look at information like
the LoginId, TimeUntilUpdate as well as the ExpirationDate, the UserId, the
Username and the cross-site stuff, so checking all of this makes sure that our
mobile applications are secure and that you are really the person who should be
interacting with the server. Now we have both of these cookies, when the cookie
information comes over it will get checked for authenticity and
for validity. If for some reason it looks as if the cookie has been manipulated or
tampered with, the user will automatically be anonymous or anonymized
in this case so if the cookie expires or it looks like the cookie has been
tampered with
then we'll go ahead and anonymize the user and force them to go ahead and
login again so the devices will delete the cookies after their expiration date
so there may come a time where the request is sent and the cookie isn't
there
and if the cookie isn't there then obviously we'll have to log in and get
the authentication information again so the cookie can be regenerated. Now there
are configuration or configurable expiration parameters and you can see
that in this particular case we mentioned that there's the persistent
login, so the persistent login cookie expiration is set to that one year time
frame.
There's also a persistent max idle time and what that means is should we go
ahead and basically expire the cookie if you don't communicate to the server
within a certain amount of time so even though the cookie won't expire for a
year if you don't come in and use at least once a month then we may go ahead and
expire it anyway so if the max idle time is one month and we could go ahead and
check that. There is the session cookie and that max. idle time in minutes we'll
go ahead and do the same thing but on the minute level not in the day's level and
then for the mobile login we mentioned that it will go ahead and look
up our information each time we go to be authenticated so when we log in it checks
that, caches that, information how long it will cache that information is set on
the server side so the cache will hold onto our our informations for a certain
amount of time before it has to go back and check again
so all of these are configurable to make sure that we can kind of get the type of
security and the performance out of a security system that we're looking for.
After authentication there is authorization so when we think about
okay we know who you are what are you allowed to get to screen roles enforce
the access control for screens and for server endpoints so when we are calling
for new data and we call the server and we're trying to get the information from
the restful endpoints the type of endpoints that get generated, any of our
aggregates will be generating endpoints all of our server actions that get used
by client actions will have endpoints, server actions that get used indirectly
by the screen and, any kind of data or logic that might be contained in blocks
that are used by the screen, so it doesn't have to be directly attached to
the screen it can be a block that is in the screen but all of these server
endpoints will have access control and the access control for those endpoints
is enforced by the server, so when we communicate to the server and we're
looking for this type of action it will decide whether or not we have the
capability and the authorization to get that information back.
So what happens if I'm offline and I want to control what screens i can see
or other types of things well the user's roles are stored in local storage at
login and at logout so this will allow us even if you're offline to go ahead and
decide which types of screens a particular user could see or not see. You
don't want to have to use this too much because it could be tampered with
unless we try to encrypt local storage or do something else,
people could change that, so the check should only be there for UI purposes
and this isn't something that we want to use too often. Now role validation will
be checked upon navigation in between different types of screens so we can put
access control on the UI and enforcing that without having to go to the server
even when we're connected to the server we don't have to check with it we can
actually do that check locally, and again as I mentioned that will mean that it's
available offline. If for some reason we can't get to that particular screen it
will raise a security exception exceptions on the client-side can be
handled in multiple ways we can either redirect to a different screen and say
sorry you don't have access to that screen or we can remain in the original
screen and sort of do nothing and just not tell someone that
hey there is something else there but you don't have access to it so a couple
different ways that can be handled. Now when we think about endpoints that are
exposed to the rest of the world as APIs
we mentioned that all of those things like the aggregates to get data the
different types of server actions are all going to generate endpoints There
isn't any one single place to see all of these and that makes it a little bit
difficult to kind of see what the overall set of endpoints and what the
total set of APIs that we're making available are so from a security
standpoint we can't really see how many things we're having to secure and this is
especially true of what we might call the flowless actions so if we put an
aggregate on the screen or if we're using entity actions directly or some type of
integrations that are in a client flow there is no easy way to see where those
things are, and the thing that's important there is we also can't say exactly how
those flowless actions how is the aggregate being secured. Well for all of
those global endpoints, the endpoints will be secured by the block or the
screen that it is going to go ahead and be part of now sometimes those global
endpoints will be used in multiple places so if we have a block and the
block is used on four screens the authorization for how that block is used
could be different on each screen and the server will know how to enforce the
authorization for all of that but when we go to a global endpoint directly when
we first try to get to it, that global endpoint will end up having the minimum
security level and then be checking after that for who that person is
so this means that if we're making some sort of endpoint
available for use in one of the screens and that screen or block has no security
then it's basically open to be called whenever it needs to, so it is always the
least restrictive screen that is going to be dictating how it is exposed and we
really want to be careful when we're doing that because that sort of creates
a potential security flaw if that screen does have access to some more sensitive
information so understanding the APIs and what is being authorized and exposed
is very important so in this session we talked about authentication, the login
sequence and how you can look at the different types of information and
control and configure how often you'll need to validate and expire those types
of authentications. From an authorization standpoint, we did mention that
role-based authorization exists as well as just on the client-side and that we
do have authorization set for global endpoints but for shared global endpoints
the security might be a little bit less than what the most restrictive needs
because it will always be the least restrictive that is there. So this is
only a quick overview
there's a lot of information about this and you should probably do some more
research on this and get the details so that you feel comfortable but at this
point you have a good introduction to begin doing a deeper dive into the
subject.