Web application authentication

A high level overview of available technologies

Transcript

1. Web Authentication A comparative review of available options with specific reference to web applications.
2. Structure of this presentation 1. What is authentication? 2. Options for authentication 3. How do we choose between these options? 4. Brief overview of vendor offerings I'm omitting technical descriptions, please just ask!
3. What is authentication? Briefly understanding what we're trying to accomplish
4. Components of authentication Component Aim Identity The identity of the user is how we distinguish between user entities Authentication Verifying a claim made by the user Authorization Defining policies that describe what users may or may not do Accounting / Auditing Being able to accurately describe who did what
5. In general, Our application needs to be able to: 1. Identify a user 2. Authenticate the user 3. Authorize requests made by the user 4. Log and audit the actions that the user takes
6. Do we have to do it all ourselves? No. For example, our application on the left doesn't need to have a login system The user logs in on Facebook and we get their identity from Facebook. We don't need to authenticate the user because Facebook does that for us.
7. Authentication options Big picture thinking, no specific details here!
8. The bad old days The client authenticates directly to the server using a password the user gives to it The server stores the application state, including their login state (more currently it is convention to only store authentication in the session) Disadvantages: The client gets the user password (and so does your server app) Not interoperable – everybody has their own login and auth process Less convenient to scale horizontally You have to manage more security yourself Doesn't "play nicely" with rich clients that need frequent state updates Users have a login for every website – and so naturally reuse passwords!
9. More current practices OAuth2 + OpenID Connect SAML 2.0 Microsoft Active directory LDAP AWS Cognito / Google Sign-in / Other service providers Other frameworks These options each let you delegate part of your authentication responsibilities
10. Informing authentication decisions How do we choose what's best in our situation?
11. Choosing an authentication approach You are very seldom in green fields with the option to choose so often this question is moot Migration can be painful and expensive so you should abstract authentication as much as possible Sometimes you just have to mitigate the effect of a previous bad choice There is never "one size fits all" in architecture, but you also don’t want snowflakes
12. General factors to consider If you are lucky enough to be standing in fresh green pastures then consider: Commercial concerns – time to market, capital vs operating expense Snowflakes – they cost money to maintain so do you want something new and unique? Scaling – will your approach handle 100k users? How about 1M users? Security – Are you rolling your own (don't) or using a battletested framework? Sharing your platform – third party access
13. Do it all yourself Store the user information in your own database Authenticate the user yourself Build RBAC or similar authorization logic Why do this? Capital expense (development cost) vs Operating expense (SaaS) Increased control of user information NIH Problems: 1. You might not get it right 2. Increased cost associated with a breach 3. Another thing to scale 4. Might be less convenient to open your platform to third party developers 5. Will it contribute to signup attrition if users have an arduous registration process?
14. Why use a third party to authenticate? 1. They've already spent the money writing a secure authentication system 2. Users might already have an account with them, reducing signup friction 3. Reduced risk around breaches because you don't store personal information
15. OAuth2 and OpenID connect OAuth2 is an authorization framework It is agnostic about authentication and is aimed at allowing the user to delegate permission to a client to act on their behalf. OpenID Connect is built on top of OAuth2 and is an authentication layer Problems: 1. Actually fairly complicated to get right on the server side 2. Phishing vulnerability 3. Usually use JWT to encode the token, which leads to a large HTTP header
16. SAML Open authentication and authorisation standard Defines XML message formats and SOAP protocols to exchange them Works great with Microsoft Active Directory (on Azure or in your DC) Problems: 1. SAML server can be tricky to set up
17. LDAP / Active Directory LDAP is just a directory that link users and passwords Instead of storing it in your own database and writing code to login you use LDAP Microsoft Active Directory is an enhanced directory service that supports LDAP
18. Vendor overview A very quick discussion about vendor options
19. Common features that we want We are looking for solutions that offer: Managed services Let's us focus on our core business instead of trying to make money doing stuff where we don't add value Compliance to industry standard security frameworks Never, ever, roll your own security Interoperability and platform neutrality A broad ecosystem of developers The ability to federate identity providers (Google/Microsoft/Facebook/etc.) Improves user experience Delegates a large part of the system security to a big provider who can throw money at it Auditing and logging Requirements for Industry frameworks (PCI) Regulatory requirements – e.g.: forensic investigation for GDPR reporting in event of a breach
20. Which particular token provider to use? This is a strategic decision more than technical, but here are some differentiating points: Microsoft Azure Active Directory Familiar management tools for system administrators Generous free tier usage Can integrate the directory with other AD products outside your public cloud AWS Cognito Can link user identity to privileges on S3 and other AWS resources Auth0 Provides standard compliant implementation –no vendor lock-in Gluu Standards compliant implementation – no vendor lock-in There is a free self-managed option
21. Questions? Summary: There are lots of alternatives and you should choose the one that best fits your situation and your plans for the future.