Authentication
Authentication vs Authorization
Authentication is the act of verifying an identity—making sure a user is who they say they are.
Often times when people talk about app security, they confuse the concepts of Authentication and Authorization, or use them interchangeably. But they are actually independent and orthogonal ideas, and understanding the difference between them is critical.
- Authentication
Verifying an identity. Making sure the user is who they say they are by referencing their credentials (papers please). - Authorization
Controls the access the user has to view, edit, delete or create content after authentication.
Authentication | Authorization | |
---|---|---|
Meaning | Are you allowed to access an app. | Are you allowed to modify something with the app. |
Methods | Password, 2FA, MFA, X509 Certificates, Biometrics, WebAuthN | Uses an Access Control List or other internal system to control what users access. |
Methods
Single Factor
Also known as primary authentication, this is the simplest and most common form of authentication. Single Factor Authentication requires, of course, only one authentication method such as a password, security pin, PIV card, etc. to grant access to a system or service.
While these methods score high on usability and familiarity, by themselves, they are typically associated with poor security and can be easily guessed or stolen via data breaches, phishing or using keyloggers.
2nd Factor
2nd Factor Authentication (2FA) adds a layer of complexity by requiring a second factor to verify a user’s identity. Common examples include tokens generated by a registered device, One Time Passwords, or PIN numbers. The mere presence of two authentication methods improves your security posture significantly—in fact, according to research from Symantec, 80% of data breaches can be prevented by 2FA.
While the security benefits of 2FA are well documented, adoption has been a widespread problem. When Google first introduced the option to have two authentication methods applied to their accounts, less than 10% of users adopted 2FA over the course of over 7 years. According to Google one of the reasons why they did not require 2FA was due to the inconvenience it caused users, noting that >10% of users who tried 2FA, failed to enter the SMS code correctly.
Multi-Factor
Multi-Factor Authentication (MFA) is the most sophisticated authentication method that leverages 2 or more independent factors to grant user access to a system. In typical scenarios, MFA methods leverage at least 2 or 3 of the following categories:
- Something you know – a password or a pin
- Something you have – mobile phone or a security token
- Something you are – fingerprint or FaceID
- Something you do – typing speed, locational information etc.
Web Authentication
Cookie-Based
Cookie based authentication has been the default method for handling user authentication for a long time. The client posts the login credential to the server, the server verifies the credential and creates a session id which is stored in the server (state-full) and returned to the client via the set-cookie header. On subsequent request the session id from the cookie is verified in the server and the request gets processed. At logout the session id is cleared from both the clients cookie and the server.
Token-Based
Token based authentication is useful for single page applications (SPA) and/or apps which make heavy use of stateless APIs. There are different ways to implement token based authentication, the most common being the JSON Web Token(JWT). On receiving the credentials from the client, the server validates the credentials and generates a signed JWT which contains the user information. Note, the token will never get stored in the server (stateless). On subsequent request the token will be passed to the server where it is verified (decoded). The token can be maintained at the client side in local storage, session storage or even in cookies.
Third-Party
Third party access, if we have a need to expose our API’s outside of our system like third party app or even to access it from mobile apps we end up in two common ways to share the user information.Via API-token which is same as JWT token, where the token will be send via Authorization header which will get handled at API gateway to authenticate the user. And the other option is via Open Authentication(OAuth),OAuth is a protocol that allows an application to authenticate against server as a user. The recommendation is to implement OAuth 1.0a or OAuth 2.0. OAuth 2.0 relies on HTTPS for security and it currently implemented by Google, Facebook, Twitter etc., OAuth 2 provides secured delegate access to a resource based on user. OAuth 2 does this by allowing a token to be issued by Identity provider to these third party applications, with the approval of user. The client then uses the token to access the resource on behalf of that user.
OpenId
OpenId is HTTP based protocol that uses identity provider to validate a user. The user password is secured with one identity provider, this allows other service providers a way to achieve Single SignOn(SSO) without requiring password from user. There are many OpenId enabled account on the internet and organizations such as Google, Facebook, WordPress, Yahoo, PayPal etc., uses OpenId to authenticate users. The latest version of OpenId is OpenId Connect, which provides OpenId(authentication) on top of OAuth 2.0(authorization) for complete security solution.
SAML
SAML, Security assertion markup language makes use of the same Identity provider which we saw in OpenId, but it is XML based and more flexible. The recommended version for SAML is 2.0. SAML also provides a way to achieve Single SignOn(SSO), user can make use of the Identity provider URL to login into the system which redirects with XML data back to your application page which can then be decoded to get the user information. We have SAML providers like G Suite, Office 365, OneLogin, Okta etc.,
Which authentication method to pick when?
For Single SignOn OpenId has taken most of the consumer market, SAML is often the choice for many enterprise application.
If you have to support only web application go for Cookie or Token based authentication.
If you have to support both web as well mobile client go with API-token with that of Cookie based authentication.
On top of above authentication methods if needed we can also implement One Time Password(OTP), Two Factor Authentication(2FA), Email verification etc.,
More Resources
- https://medium.com/@vivekmadurai/different-ways-to-authenticate-a-web-application-e8f3875c254a
- https://www.okta.com/blog/2019/02/the-ultimate-authentication-playbook/
- https://crypto.stackexchange.com/questions/32304/how-exactly-does-certificate-based-authentication-work
- https://en.wikipedia.org/wiki/WebAuthn