Most Real World Internet Systems have Authentication and Authorization and currently the world is mind-blown by State focused Frameworks and Development Approaches. So I decided to describe what could be the mix of both areas.
From an Authentication & Authorization point of view – the modern way to implement a backend is the Application Layer to not store any state. If there is some data required by the server – it is stored as one time application settings. Otherwise information is and queried on each request from external systems. The User’s Data is kept in a SQL Storage, in Memory for fast access or in NoSQL Database. The state that is stored on the client in some way is:
- Non-Secure Client Storage – Data on the client may be kept in a non-secure Local Storage in the Browsers, Shared Preferences on Android or NS User Defaults preferences on iOS.
- Secure Client Storage – iOS has the Keychain – Secure Container, Android has the biometrically protected Key Stores and the external to the app Account Manager. The browsers have http-only cookies that are not accessible to JavaScript code and are only resent to the servers in the request passively and also Web Crypto API: https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API | https://browsersecrets.restograde.com/.
Has the User Logged In?
The values stored in the client could be true or false. This flag could be present in a standalone variable or it could be calculated by an expression from other fields/parameters. It could be the presence of one or more tokens, numbers, key-value maps valid until time X. A presence of expiration time in the active variable is important for security reasons.
Source of Authentication
Currently you could find endless possibilities of source of authentication.
- Internal Authentications – they are preferred by Application Engineers, because they are independent from external services and give the most control.
- The most powerful, important, and used option is a Private Database. This means in most cases email + B-Crypt Encrypted passwords.
- In some small cases the Email is a Username and alternatively – GSM Mobile Number.
- External Services – delegating the pain of authentication and focus more on the Service part.
- LDAP & ERP – probably mostly used in corporate, institutional and legacy systems.
- OAuth & OpenID – mostly applied in systems for the broad public.
Social Media Authentication for Apps
Most Social Network use OAuth & OpenID. They have Web Interface for Developers where you could set the required settings so your external service or app is authorized against their servers.
Authorization State of a User
The Software Community as a whole have invested a lot of time, effort and energy in improving most important layer of the Internet. People found meaningful to separate the Authentication from the Authorization for a security, modularity and scalability reasons.
- Cookie – old systems use cookies
Cookies are key-value files that are sent to the client by a HTTP Application Server. The value is usually a big number or GUID. They require from the Application Server to store the association of the key-value in the cookie to your log-in session. This approach is considered old and unscalable. But, you’ve got to first understand what is your purpose with the software. If some Web Site does not have many active in the same time – registered users, this approach is totally fine.
- JWT – the modern way are the JSON Web Tokens.
JWTs are cryptographically protected. They could be verified by any Application Server that has a copy of the Private Key that have created them. The Minds of the Internet World have embraced them. The smart people are thinking new ways every year – how these tokens could be extended to accommodate the endless new use cases. Having Community for Standards – educational and non-profit organizations – All participants test and try to keep up with the new Encryption and Security Solutions.